• Product: RSA Identity Governance & Lifecycle
• Version: 7.x
• Component: LDAP Authenticator, Active Directory (AD) Account Collector
• Environment: WildFly Application Server, Java Runtime Environment (JRE)

When running the Authentication Test under Admin > System > Authentication, the test fails for an Authentication Source associated with an AD Account 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:{BindDN}

SUCCESS: Authentication Module:MyADAccountAuthenticator. JAAS Configuration found. 
JAAS configuration Information: 
    Login Module Name: com.aveksa.server.authentication.AveksaJndiLoginModule 
    Options: {BindPassword=********, AccountBaseDN=OU=US,OU=vcloud Users,DC=2k8r2-vcloud,DC=local, 
SearchFilterForAccounts=, jboss.security.security_domain=MyADAccountAuthenticator, AuthAccountAttribute=, 
ConnectionUrl=ldaps://2k8r2-dc1.2k8r2-vcloud.local:636, UseSSL=Yes, AccountSearchScope=2, 
BindDn=administrator@2k8r2-vcloud.local, AccountSearchAttribute=sAMAccountName} 
    Control Flag: LoginModuleControlFlag: required 

Unable to Login User: cblossom
ERROR: Connection could not be established with the directory server with username: administrator@2k8r2-vcloud.local

 

The following is logged in the aveksaServer.log file ($AVEKSA_HOME/wildfly/standalone/log/aveksaServer.log)  at the DEBUG (or INFO) log level:

02/14/2020 16:57:14.800 INFO  (default task-20) [com.aveksa.server.authentication.AuthenticationProviderServiceImpl] 
javax.security.auth.login.LoginException: Connection could not be established with the directory server with username: 
administrator@2k8r2-vcloud.local

The AD LDAP server's root CA certificate is not trusted in the JRE cacerts trust store used by the RSA Identity Governance & Lifecycle WildFly server.

When UseSSL is set to Yes on the Authentication Source, the server attempts to establish an SSL/TLS session with the AD LDAP server. If the certificate chain presented by the AD LDAP server is not trusted in the JRE's cacerts store, the SSL handshake fails and the connection cannot be established.

NOTE: This commonly happens because the SSL trust for the Authentication Source is configured independently from the Identity Collector it is based on. The Identity Collector may connect successfully using clear (non-SSL) while the Authentication Source fails — this is expected behavior, not an additional error.

Use the Java keytool command to import the AD root CA certificate into the JRE cacerts trust store used by the RSA Identity Governance & Lifecycle WildFly server.

NOTE: If the AD LDAP server certificate is signed by one or more intermediate certificate authorities, you must import each intermediate CA as well as the root CA. Import the root CA first, then each subordinate CA in order.

1. Obtain the AD root CA certificate file from your AD administrator and copy it to the RSA Identity Governance & Lifecycle server (for example, to /tmp/ad.cer).

2. Identify the cacerts file location for your Linux distribution.

   Linux Distribution	cacerts Path
   SUSE Linux	/var/lib/ca-certificates/java-cacerts (symbolic link)
   SUSE Linux	/usr/lib64/jvm/<jre-version>/jre/lib/security/cacerts (file)
   Red Hat Linux	/etc/pki/java/cacerts (symbolic link)

3. Log in as the root user on the RSA Identity Governance & Lifecycle server.

4. Back up the cacerts file before making any changes.

   cp /usr/lib64/jvm/<jre-version>/jre/lib/security/cacerts \
      /usr/lib64/jvm/<jre-version>/jre/lib/security/cacerts.bak

5. Import the AD root CA certificate into the cacerts trust store.

   keytool -import -trustcacerts -alias AD \
     -file /tmp/ad.cer \
     -storepass changeit \
     -keystore /usr/lib64/jvm/<jre-version>/jre/lib/security/cacerts

   The command will display certificate details similar to the following:

   Owner: CN=<your-CA-name>, DC=<domain>, DC=<tld>
   Issuer: CN=<your-CA-name>, DC=<domain>, DC=<tld>
   Serial number: <serial>
   Valid from: <start-date> until: <end-date>
   ...
   Trust this certificate? [no]:

6. When prompted with Trust this certificate? [no]:, type yes and press Enter.

   Expected output:

   Certificate was added to keystore

7. CAUTION: A full server restart is required for certificate trust changes to take effect. Ensure you have a planned maintenance window before proceeding.

   Restart the RSA Identity Governance & Lifecycle server.

   acm restart

8. Verification: Navigate to Admin > System > Authentication, select the affected Authentication Source, and re-run the Authentication Test. Confirm the test returns a SUCCESS result with no connection error.

• SSL Debugging: For advanced SSL certificate and truststore troubleshooting, refer to KB 000033388 — How to Enable SSL Debug When Using a WildFly/JBoss Application Server with RSA Identity Governance & Lifecycle.
• Separate Authentication Configuration: The Authentication Source configuration screen is independent from the AD Account Collector it is based on. The BindDN, BindPassword, and connection settings must be specified separately and do not need to match those defined for the collector. It is possible for the collector to connect successfully while the Authentication Source fails.
• Bind Failure Scope: The error Connection could not be established with the directory server with username: {BindDN} refers specifically to the initial bind attempt using the credentials defined on the Edit Authentication Source screen. If this bind fails, no attempt is made to authenticate the test user.
• BindDN Format: The BindDN field accepts any username format supported over LDAP. If the name contains spaces, enclose it in single quotes. If it contains special characters, escape them. Supported formats include:

  username@domain.com
  domain\user
  CN=user,DC=domain,DC=com
  'CN=user name,DC=domain,DC=com'
  'CN=user\,name,DC=domain,DC=com'