How do I make AM 5.x and 6.x communicate with a secured LDAP server?

Making AM communicate with a secured LDAP server

DS 7 introduces a secure by default approach. One aspect of this approach is that all connections to DS 7 instances must be made using secure connection, including LDAPS. See Installation Guide › Preparing a Truststore for further information on making AM communicate with a secured LDAP server in AM 7 and later.

Pre-AM 7

When your LDAP server uses LDAP secured access (LDAPS), you must import the LDAP server certificate into the JVM truststore used by AM. This allows the JVM to trust the LDAP server certificate and enables AM to connect to the secured LDAP server. Additionally, there are some version-specific issues you should be aware of to ensure your setup is successful. See the Known issues section for further information.

Once you have resolved any version-specific issues, you can proceed to import the LDAP server certificate into the JVM truststore used by AM; the following instructions differ depending on whether you are using the default JVM truststore or a non-default one:

• Using the default JVM truststore
• Using a non-default truststore

See How do I import a certificate into the truststore used by AM (All versions) for SSL? for further information.

Known issues

The following known issues affect specific AM / Java® versions:

Lack of TLS 1.2 protocol support

AM 5.x and 6.0.0.x, and certain ssoadm versions (in AM 5.x, 6.0.0.x, 6.5.0 and 6.5.0.1) ​​​​do not correctly support the TLSv1.2 protocol, whereas using more secure ciphers or installing DS in production mode forces the protocol version to TLSv1.2. In Java versions prior to JDK 1.8.0_192, unsupported cipher suites were simply ignored, which is why these connections continued to work despite the mismatch in protocol versions.

Changes were introduced in JDK 1.8.0_192 (JDK-8162362 : Introduce system property to control enabled ciphersuites), which changed how the JDK determined which cipher suites (and resulting protocol) to use. As a consequence of these Java changes, AM and ssoadm cannot communicate with DS using a SSL/TLS secured connection because it uses different cipher suites and protocol to the DS server; both the client and server must support the same cipher suites and protocol agreed upon when attempting to establish a secure connection.

You can resolve this issue as follows:

• If the issue is on the AM side, you can upgrade to AM 6.5 or later; you can download this from BackStage.
• If the issue is on the ssoadm side, you can upgrade to AM 6.5.0.2 or AM 6.5.1, and then upgrade ssoadm to version 5.1.2.3; you can download this from BackStage.

See AM 5, 5.5, 5.5.1 and 6.0.0.x, IDM 6.x and Rest2LDAP cannot connect to DS 5, DS 5.5, DS 5.5.1, DS 5.5.2 or 6 after restricting DS cipher suites or Java upgrade and Cannot install or use ssoadm in AM 5, 5.5, 5.5.1, 6.0.0.x, 6.5.0 and 6.5.0.1 after restricting configuration store (DS) cipher suites or Java upgrade for further information and workarounds.

Stricter hostname validation

Changes introduced in AM 5.1.x; AM 6 or later, and DS 5.5.1 or later have made LDAP SSL hostname validation stricter. AM checks the hostname in the LDAP server certificate correctly matches the hostname used to connect to the secured directory server (for example, DS or Active Directory®) and DS checks that the server it is trying to connect to has a certificate that matches the hostname.

Java 1.7.0_191 and 1.8.0_181 introduced changes to improve LDAP support by enabling endpoint identification algorithms by default for LDAPS connections; this also results in stricter hostname validation.

As a result of these changes, you must ensure the hostname you are connecting to the LDAP server with matches the hostnames specified in the server certificate via the SAN (Subject Alternative Name). See LDAP connection fails with No subject alternative DNS name matching error in AM 5.1.x, 5.5.2, 6.x, 7.x and DS 5.5.1, 5.5.2, 6.x, 7.x for further information.

Using the default JVM truststore

You can do this as follows:

1. If you are using the DS generated self-signed certificate, you must first export this with its alias of 'server-cert' using the following keytool command: $ keytool -export -alias server-cert -file server-cert.crt -keystore /path/to/ds/config/keystore -storetype [storetype] -storepass:file /path/to/ds/config/keystore.pin If you want to export the certificate in PEM format, you should use the following command instead: keytool -exportcert -alias [alias] -keypass [keypassword] -keystore [keystore] -storetype [storetype] -storepass [storepassword] -rfc -file [keyStore.pem]
2. Import the generated self-signed certificate or the issuer certificate of the CA who signed the LDAP server certificate (if it is not already present in the store) into the JVM truststore used by AM using the following keytool command: $ keytool -importcert -alias [alias_of_certificate_entry] -file [path_to_certificate_file] -trustcacerts -keystore /path/to/truststore -storetype [storetype] For example, your command would look similar to this if you were importing the DS generated self-signed certificate into the JVM truststore, where AM is deployed and running on Apache Tomcat™ web container: $ keytool -importcert -alias server-cert -file /path/to/server-cert.crt -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storetype JKS

Finally, AM should be configured to connect to the LDAP server on the secured port as required.

Using a non-default truststore

You can do this as follows:

1. If you are using the DS generated self-signed certificate, you must first export this with its alias of 'server-cert' using the following keytool command: $ keytool -export -alias server-cert -file server-cert.crt -keystore /path/to/ds/config/keystore -storetype [storetype] -storepass:file /path/to/ds/config/keystore.pin If you want to export the certificate in PEM format, you should use the following command instead: keytool -exportcert -alias [alias] -keypass [keypassword] -keystore [keystore] -storetype [storetype] -storepass [storepassword] -rfc -file [keyStore.pem]
2. Add the following JVM option to the web container or application server on which you have deployed AM to identify your truststore: -Djavax.net.ssl.trustStore=/path/to/truststore
3. Import the generated self-signed certificate or the issuer certificate of the CA who signed the LDAP server certificate (if it is not already present in the store) into your truststore using the following keytool command: $ keytool -importcert -alias [alias_of_certificate_entry] -file [path_to_certificate_file] -trustcacerts -keystore /path/to/truststore -storetype [storetype]

Finally, AM should be configured to connect to the LDAP server on the secured port as required.

See Also

AM (All versions) fails to connect to DS using a secured connection with an ERROR: Connection factory became offline

How do I troubleshoot connection via LDAPS issues in DS (All versions)?

FAQ: SSL certificate management in AM and Agents

FAQ: SSL certificate management in DS 5.x or 6.x

Setup and Maintenance Guide › Setting Up Keys and Keystores

Installation Guide › Using Self-Signed Certificates

Installation Guide › Preparing Configuration Stores​

Related Training

N/A

Related Issue Tracker IDs

N/A