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
Originally Published: 2016-02-01
Article Number
Applies To
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
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 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
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
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.
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'
