LDAP authenticator based on Active Directory Identity Collector fails with the error 'Connection could not be established with the directory server' in RSA Identity Governance & Lifecycle

[#1]

Article Number

000032468

Applies To

RSA Product Set: RSA Identity Governance & Lifecycle 
RSA Version/Condition:  7.x
 

Issue

When running the Authentication Test under Admin > System > Authentication for the Authentication Source associated with the 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

 

Image description
 

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

Please refer to RSA Knowledge Base Article 000030327 --- Artifacts to gather in RSA Identity Governance & Lifecycle to find the location of the aveksaServer.log ffor your specific deployment if you are on a WildFly cluster or a non-WildFly platform.
 

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 source is defined with UseSSL set to Yes, then ensure that the root CA and all of the intermediate signers for the certificate that are used by the AD LDAP sever are trusted in the internal trust store for the JRE used by the RSA Identity Governance & Lifecycle 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 any 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 the RSA Identity Governance & Lifecycle WildFly server.

The location of the cacerts file may vary according to the Linux distribution. 

SUSE Linux

For SUSE Linux the cacerts file is typically located in

• /var/lib/ca-certificates/java-cacerts (symbolic link)
• /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre/lib/security/cacerts (file)

Red Hat Linux

For Red Hat Linux the cacerts file is typically located in /etc/pki/java/cacerts (symbolic link)
 

Example

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.)

When prompted with the question Trust this certificate? [no], enter yes and press Enter.

Note that a server restart is required for any changes to the authentication configuration.

Login as the root user.

# 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
# keytool -import -trustcacerts -alias AD -file /tmp/ad.cer -storepass changeit -keystore /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre/lib/security/cacerts
Owner: CN=2k8r2-vcloud-2K8R2-DC1-CA, DC=2k8r2-vcloud, DC=local
Issuer: CN=2k8r2-vcloud-2K8R2-DC1-CA, DC=2k8r2-vcloud, DC=local
Serial number: 3fd7f1cb1573b59348706aef0576de6f
Valid from: Thu Jun 13 15:07:36 EDT 2013 until: Wed Jun 13 15:17:35 EDT 2018
Certificate fingerprints:
         MD5:  BE:78:02:3E:87:99:55:13:81:5A:4F:14:C4:6A:CB:E2
         SHA1: 1C:6E:2F:BA:47:C6:25:82:4B:F3:16:42:1F:0C:1D:72:19:42:04:05
         SHA256: 8A:03:A5:77:BA:18:9F:56:45:ED:5F:10:CD:42:5C:48:7E:13:20:32:38:14:F2:B1:DE:77:F3:41:C7:56:2E:49
         Signature algorithm name: SHA1withRSA
         Version: 3
 
Extensions:
 
#1: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false
0000: 02 01 00                                           ...
 
 
#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
 
#3: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]
 
#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: DF 43 D2 E9 D3 60 1C 41   8C AE 64 86 0F A8 8C 7F  .C...`.A..d.....
0010: 7E 4B 2D A8                                        .K-.
]
]
 
Trust this certificate? [no]:  yes
Certificate was added to keystore
acm-700:~ # acm restart

 

Notes

For additional SSL debugging option and advanced troubleshooting for SSL certificates and truststore see RSA Knowledge Base Article 000033388 -- How to enable SSL debug when using a WildFly/JBoss application server with RSA Identity Governance & Lifecycle.

Note that the AD Account Collector Authentication configuration screen has separate configuration information from the AD Account collector.  You must specify all settings including the BindDN and BindPassword separately from those defined for the associated collector.  This information does not have to be identical to those used by the collector.  

Image description

Note that if the connection information defined for the authentication source is different from 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 with username:{BindDN}

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
domain\user
CN=user,DC=domain,DC=com
'CN=user name, DC=domain, DC=com'
'CN=user\, name,DC=domain,DC=com'