User data import from AD Logins Data Source failing with SSL handshake exception

Products

• Data Loss Prevention

Issue/Introduction

The user data import sync job starts to fail if the directory connection is configured to use a secure connection on port 636. The directory connection test is successful however the related data source for the AD logins sync is failing.

Below errors are seen in the localhost logs on the Enforce:

18 Jul 2021 07:00:05,719- Thread: 177 SEVERE [com.vontu.enforce.domainlayer.datauser.source.DataUserSyncTask] User Synchronization failed:
Cause: org.springframework.ldap.PartialResultException: nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: simple bind failed: DomainDnsZones.example.corp:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching DomainDnsZones.example.corp found.]]org.springframework.ldap.PartialResultException: nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: simple bind failed: DomainDnsZones.example.corp:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching DomainDnsZones.example.corp found.]]

Environment

15.8, 16.x

Cause

Certificates did not include the CN or SAN for which the LDAP certificate authentication fails.

Resolution

To resolve this issue the certificate imported should have DomainDNSZones added as a SAN and then reimported to DLP. Ie DomainDNSZones.<example>.com

Using a SAN is preferred but if this is not an option, try on of the following:

 

Specify Domain server

In the directory connection instead of only specifying the domain such as DomainDNSZones.<example>.com specify the DC server name specifically for example <dcservername>.DomainDNSZones.<example>.com

A DC server name can be determined by testing the connection and using wireshark (preferred). Checking to see the server name used in the handshake process when communicate over port 636.

Alternatively a server name can be found by using "echo %logonserver%" at the command prompt.

This will only work as long as the root ca from the domain has been included in the keystore.

 

Disable host name verification

A workaround can be applied to disable the Host Name verification (not recommended). Note: We encourage to use the Host Name verification and recommend updating the certificate. 

1. Stop the Symantec DLP Manager Service. 
2. In SymantecDLPManager.conf under Services folder, uncomment the following lines (to uncomment remove # )
   # wrapper.java.additional.30 = -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true
3. The uncommented line should like below
   wrapper.java.additional.30 = -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true
4. Save the file.
5. Restart the Symantec DLP Manager Service.

 

Use the insecure connection on port port 389

Another possible alternative is to switch to port 389 instead of 636 on the directory connection.