This page complements information from LDAP Integration with additional details related to security. When configuring the LDAP server connection, specifying LDAPS as a protocol (property URL of LDAP server starting with LDAPS:) will lead to encrypted connection using SSL/TLS. Supported SSL/TLS versions are SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. The default protocol is TLS 1.2 since several weaknesses were found in the lower versions. To change the protocol version, go to the System settings (using Expert options) and modify the cryptographicProtocolsForOutboundCommunication property (the recommended setting is configured by the value TLSv1.2). More protocols can be specified in order of priority separated by comma. Use values in following format: SSLv3, TLSv1.2, TLSv1.1, TLSv1.

SSL/TLS cipher suites used for LDAPS communication can be customized by the customCipherSuitesForOutboundCommunication property (use the IANA names in order of priority, separated by comma). However, not all cipher suites are supported for this communication link and note that some combinations of protocols and ciphersuites are not valid. 8 high-security and tested cipher suites compatible with TLS 1.2 are set by default:

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

The configured cipher suites are used only when the property allowCustomCipherSuitesForOutboundCommunication is set to Enabled (the default setting). By setting it to Disabled, a wider range of cipher suites will be automatically used based on the protocol configured. This setting can ensure better compatibility with legacy systems but also potentially decrease the security level.

Server authentication

The authentication is ensured via SSL/TLS certificates. There are four options for certificate verification available in System > LDAP Integration > Settings (in Basic mode):

  • Windows certificate store -The LDAP server certificate is verified using certification authorities set in Windows and has to match the value of URL of LDAP server. This is the default option.
  • Java truststore (with hostname check) -The certificate is verified using authorities in a dedicated Java truststore where the certificate authority needs to be installed. The certificate also has to match the value of URL of LDAP server.
  • Java truststore (without hostname check) - The certificate is also verified using the Java truststore but the certificate doesn't have to match any URL.
  • No certificate check (insecure) - Any certificate is accepted for TLS connection.

See below for more details regarding the required configuration and security of different options.

These options supersede options hash and secure available in previous product versions. During the update, if LDAPS is configured, the option hash is automatically changed to No certificate check (insecure) and the option secure is converted to Java truststore (without hostname check). Please select an option which suites your needs the best. If plain LDAP is configured in the time of update, the option Windows certificate store is used as the default. Change the protocol in the URL of LDAP server option to LDAPS to enable secure connection.


For the Windows certificate store option, that store has to contain the certificate authority which signed the LDAP server certificate. If it is not already imported or the LDAP server certificate is not signed properly, see System communication hardening for instructions.

For the both Java truststore options, the certificate authority (or the certificate itself) needs to be present in a dedicated Java truststore. This ssl-truststore file can be found in the <management_folder>\conf\ folder. If the LDAP server certificate is not signed by a public certificate authority, run the following keytool command to import the certificate or the private authority used to sign it:

keytool -import -keystore ssl-truststore -file ldap_server_certificate.crt -alias ldap_server_certificate

The command will ask for a truststore password, which can be found in the <management folder>/tomcat/conf/server.xml file. Third party tools with graphical interface such as KeyStore Explorer can also be used if preferred.

Note that for Windows certificate store and Java truststore (with hostname check) options, the LDAP server certificate has to have SAN (Subject Alternative Name) or Common Name extensions correctly set as specified in RFC 2830. The value in that field has to match the hostname or IP address configured by the URL of LDAP server setting. For example, if the certificate contains only the domain name of the LDAP server in SAN, the configured URL has to use that domain name and not the IP address nor a different domain name pointing to the server.

The Java truststore (without hostname check) option does not check values in SAN nor Common Name. This means that certificates signed by authorities in the truststore are interchangeable and every owner of a private key for any of those certificates can spoof the LDAP server identity and thus break the confidentiality or integrity of the data transferred. For this reason, all public certificate authorities have to be removed from the ssl-truststore file. This option should be used only in specific cases where certificates with proper server identification cannot be used.

For the Windows certificate store option and the both Java truststore options, note that very weak algorithms such as MD5 for hashing or RSA with a key length below 1024 bits for signature are disabled. Certificates using those algorithms cannot be used for LDAPS connection as they provide poor security. Certificate revocation is not supported.

The No certificate check (insecure) option skips all certificate security checks and server identity is not verified. The communication is still encrypted but as any certificate is considered valid, the LDAP server identity can be spoofed and an active attacker might break the confidentiality or integrity of data transferred. This option is intended especially for testing environments where no sensitive data is transferred but LDAPS connection needs to be used.

Client authentication

Dispatcher Paragon authenticates to the LDAP server with username and password (unless anonymous access is configured). One of the two bind methods can be selected in System > LDAP Integration > Settings (in Basic mode) – Simple bind or LDAPv3 SASL DIGEST-MD5. Simple bind is configured by default; however, it is not recommended to be used without LDAPS as all data (including service account credentials) would be transferred without any confidentiality or integrity protection. Moreover, Microsoft advises to enforce LDAP signing on Active Directory servers which prevents to connect to such server with plain LDAP and simple bind. In contrast, LDAP integration using simple bind and LDAPS is still supported as the whole communication channel is protected by TLS (SSL).

When method LDAPv3 SASL DIGEST-MD5 is configured, Dispatcher Paragon can integrate with an LDAP server enforcing LDAP signing even if LDAPS is not used. In this case, password confidentiality and data integrity is enforced on the level of LDAP protocol. Also, the data is encrypted if the LDAP server supports it. However, it is still recommended to use LDAPS for higher security. Note that using the DIGEST-MD5 method together with LDAPS will fail if the LDAP server strictly enforces LDAP channel binding, which is not supported in this case.

Limitations of using LDAPv3 SASL DIGEST-MD5 binding method

Using the DIGEST-MD5 method has several limitations in contrast to simple bind (which is more universal):

  • IP address in the LDAP URL is not supported, only a domain name
  • The domain name in the LDAP URL must match a Service Principal Name (SPN) of the LDAP server, this may be an issue if DNS load balancing/failover is used (unless that DNS name is added as SPN to the end servers)
  • Default authentication realm (offered by the LDAP server) is used, there is no way to use a different realm, username must be unique globally
  • DIGEST-MD5 method with LDAPS does not support channel binding, it cannot be used if the server has registry LdapEnforceChannelBinding configured to value 2
  • The method has only been tested with Active Directory in the role of the LDAP server

Troubleshooting

Dispatcher Paragon replicator logs

javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C09023C, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4563 ]

Plain LDAP is used with simple bind to connect to a server requiring signing. Switch to LDAPS or change the bind method to DIGEST-MD5.


Dispatcher Paragon replicator logs

javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C090569, comment: AcceptSecurityContext error, data 52e, v4563 ]

Credentials are invalid. If DIGEST-MD5 method is used, check if format of the username is correct (it should be plain username with no prefixes or suffixes).


Dispatcher Paragon replicator logs

javax.naming.AuthenticationException: [LDAP: error code 49 - 80090346: LdapErr: DSID-0C090569, comment: AcceptSecurityContext error, data 80090346, v4563 ]

LDAP channel binding is required by the LDAP server. Use LDAPS with simple bind or plain LDAP with DIGEST-MD5 method.


Dispatcher Paragon replicator logs

javax.naming.CommunicationException: <URL> [Root exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

LDAPS is configured but the certificate of the LDAP server is not trusted. Import the certificate authority correctly and select an appropriate method of certificate check. (This is actually an error in server authentication.)