on Jun 14, 2016Article Content
| Article Number | 000032468 |
| Applies To | RSA Product Set: RSA Via Lifecycle and Governance RSA Version/Condition: 7.0 |
| Issue | When running the Authentication Test under Admin > System > Authentication for the Authentication Source associated with the AD Identity Collector configured with UseSSL set to Yes, the test authentication fails with the following failure message: Connection could not be established with the directory server with username Smith, John. The following is logged in the aveksaServer.log file at the DEBUG (or INFO) log level 02/01/2016 11:54:34.170 INFO (default task-19) [com.aveksa.server.authentication.AuthenticationProviderServiceImpl] |
| Cause | This error will occur if there is any configuration error that prevents a connection to the LDAP server. This error may occur if the trusted SSL session could not be established with the Microsoft AD LDAP server configured for the authentication source. The SSL trust for the authentication is set up separately from any configuration defined for the Identity Collector on which the authentication source is based. The authentication source can use SSL even if the Identity Collector is using clear, for example. If the authentication is set with UseSSL set to Yes, then ensure that the root CA and all of the intermediate signers for the certificate that is used by the AD LDAP sever are trusted in the internal trust store for the JRE used by the RSA Via L&G server. If the LDAP server certificate is signed by a public CA that is trusted already in the JRE cacerts store this may not be necessary, but for all certificates signed by other root CA you must trust the root CA and the entire certificate chain specifically. |
| Resolution | Use the Java keytool command to add the AD root CA to the cacerts trust store for the JRE used by RSA Via L&G Wildfly server. The cacerts file typically is stored in /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre/lib/security or /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.x86_64/jre/lib/security. Here is an example of the process for using keytool to trust a certificate copied to the /tmp directory. If the LDAP certificate is signed by one or more intermediate certificate authorities, you must trust each of the intermediate CAs as well as the root CA. (The order that you trust is not always significant, but it is best to trust the root CA first and then each of the subordinate CA certificates.) Note that a server restart is required for any changes to the authentication configuration. acm-700:~ # cp /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre/lib/security/cacerts /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre/lib/security/cacerts.bak |
| Notes | For additional SSL debugging options, see article 00030977 Enabling SSL debug when using the WebSphere application server with RSA Via Lifecycle & Governance. Note that the AD ADC (Account Data Collector) Authentication configuration screen has separate configuration information from the AD ADC collector. You must specific all settings including the BindDN, BindPassword separately from those defined for the associated collector. This information does not have to be identical to those used by the collector.
Note that if the connection information defined for the Authentication source is different than that defined for the collector, it is possible for a connection failure to be limited to only the authentication component. The failure message "Connection could not be established with the directory server" pertains specifically to the initial bind connection attempted using the bind information provided on the Edit Authentication Source configuration screen and if this connection fails no attempt is actually made to bind with the test user. The BindDN accepts any format for the username that is accepted over LDAP. Note that if the name contains spaces the name should be quoted, and if it contains special characters they should be escaped. For example: username@domain.com |
