Hexagon Geospatial


Wondering how others have configured their ERDAS APOLLO server or what data they are crawling? The ERDAS APOLLO Discussion board is a place to find information, share ideas and more. Join the community, connect, contribute and share.
Showing results for 
Search instead for 
Do you mean 
Posts: 74
Registered: ‎11-02-2015

Some help and hits for APOLLO 2018 LDAP-Configuration

Hi there,

since I have spent quite some hours to connect the APOLLO 2018 user management to an AD using LDAP I think it does make sense to share my findings with the community. I hope this is might come handy to someone…


The changes in <apollo_home>\webapps\erdas-apollo\WEB-INF\spring-jaas-auth.conf done via the configwizard still need some adjustments.

  1. Check if the basedn is correct – the default values will most likely not fit to your LDAP tree structure
  2. For a connection to a Windows AD the user filter needs to be modified to use sAMAccountName which contains the user login string.
  3. The part of LdapRoleAuthorizationModule does miss the bindDn as well as the bindCredential line
  4. The Role attribute most likely needs to be changed to also use the sAMAccountNam

In APOLLO 2018 the ldaptive module does not produce any output to the tomcat.log even if you set debug to true. To get any hints if things are not work as they should (which was the case at my installation) you have to edit the file <Apollo_home>/webapps/erdas-apollo/web-inf/classes/log4j.properties and there

  1. Comment the line log4j.appender.file.Threshold=INFO (near line 16)
  2. Add the following to the category config which starts around line 31: log4j.logger.org.ldaptive=DEBUG
  3. Restart Tomcat
    (Thnaks for this information Paul!)

Now I got some ideas why the connection to the server -even after the correct modifications- has not been successful:

[org.ldaptive.LdapException@58594655::resultCode=STRONG_AUTH_REQUIRED, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, message=javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090257, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580 ], providerException=javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090257, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580 ]]


This is caused by a more rigid AD setting where the client needs either to be trusted on the server side or needs to use an encrypted connection. So I did enable the option startSSL.


Unfortunately, this did not really solve my connection problem but due to logging I found at least some errors that helped to solve the issue. This was one of the error messages coming from ldaptive:
2018-05-16 08:54:04,239 DEBUG (ajp-nio-8009-exec-3)[org.ldaptive.jaas.LdapLoginModule] Error occurred attempting authentication
[org.ldaptive.OperationException@2102574598::resultCode=PROTOCOL_ERROR, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, message=javax.naming.CommunicationException [Root exception is java.net.SocketException: Connection reset], providerException=javax.naming.CommunicationException [Root exception is java.net.SocketException: Connection reset]]
Caused by: javax.naming.CommunicationException [Root exception is java.net.SocketException: Connection reset]


The reason for this error: the DC is using an self-signed corticate that of course is not part in the java keystore and thus the connection is not trusted on the Java side. Now the client (APOLLO Tomcat) closes connection. In order to solve this you have to add the ca-root.cert as well as the intermediate.cert to the Java keystore. This can be archived using the following command:
"C:\Program Files\Java\jdk1.8.0_172\bin\keytool.exe" -importcert -alias zkiroot -keystore "C:\Program Files\Java\jdk1.8.0_172\jre\lib\security\cacerts" -storepass changeit -file "D:\Vorbereitung Schulung\Zertifikate\zpkir.cer"


Still no success and still the same error message. I found out that the keystore of the standalone JRE (C:\Program Files\Java\jre1.8.0_172) which will be installed together with the JDK is used. So either uninstall the JRE or add two certs also to the keystore of the standalone JRE:
"C:\Program Files\Java\jre1.8.0_172\bin\keytool.exe" -importcert -alias zkiroot -keystore "C:\Program Files\Java\jre1.8.0_172\lib\security\cacerts" -storepass changeit -file "D:\Vorbereitung Schulung\Zertifikate\zpkir.cer"


Now finally after a restart (and some hours later including a bunch of new grey hairs) the connection to the DC had been successful. Great!


Here is the used spring-jaas-auth.conf that also allows to use a mixed user management (in AD and Apollo-DB).


apollo-jaas {

  com.erdas.apollo.jaas.security.DBJaasLoginModule required debug=false;



apollo {

  com.erdas.apollo.jaas.security.DBJaasLoginModule sufficient debug=false;

  org.ldaptive.jaas.LdapLoginModule required








  org.ldaptive.jaas.LdapRoleAuthorizationModule required











apollo-windows {

  waffle.jaas.WindowsLoginModule required debug=false;





Geography is what geographers do...
Technical Evangelist
Posts: 839
Registered: ‎07-30-2015

Re: Some help and hits for APOLLO 2018 LDAP-Configuration

Hi Fritz,


Thanks so much for this very informational article.




Do you need immediate support?
If you encounter a critical issue and need immediate assistance please submit a Service Request through our Support Portal.