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

Document created by RSA Customer Support Employee on Jun 14, 2016•Last modified by RSA Customer Support on Dec 11, 2018
Version 10Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000032468
Applies ToRSA Product Set:  RSA Via Lifecycle and Governance
RSA Version/Condition:  7.0.0, 7.0.1, 7.0.2, 7.1.0

 
IssueWhen 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] 
javax.security.auth.login.LoginException: Connection could not be established with the directory server with username: 
CN=Smith\, John,OU=US,OU=vcloud Users,DC=2k8r2-vcloud,DC=local

CauseThis 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.
ResolutionUse the Java keytool command to add the AD root CA to the cacerts trust store for the JRE used by 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)

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.




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
acm-700:~ # 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
NotesFor additional SSL debugging options, see the following articles: 

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.  

User-added image



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

Attachments

    Outcomes