Unity Connection LDAPS Dirsync No errors but not syncing users.

[AnthonyCSheehy]

Unity Connection 12.0.1.21900-10

Until our DCs where restricted to LDAPS only (to alleviate a serious NTLM exploit) Unity was happily syncing users.

After the restriction we turned to Unity and added the port number (3269) and ticked the "Use TLS" and saved. No error message! All good, or so we thought - but no new users were syncing, either at the scheduled time or when manually synced - and again, no error message.

So I pulled a trace of the dirsync service and what did I find?

The service is doing a reverse DNS on the provided FQDN (you can see where this is going, right?) It then constructs the LDAPS URL using the IPv4 address. It then tries to connect and, lo and behold, it can't verify the certificate? Much facepalm!

I really want to rant, ask if they actually paid someone to write this ****, but I really need a non-disruptive solution. We are a School, being targeted for Ransomware, right at the start of term with new staff and I need to add new users quickly. Re-enabling LDAP non-TLS is NOT an option!

Help?

[Elliot Dierksen]

What is the CA that issued the certificate that your DC's are using for LDAPS? I suspect the problem is that Unity does not trust the certificate/CA. Export the certificate chain for your DC's, and then upload that as a tomcat-trust certificate to Unity. You will have to restart the Cisco Tomcat service to make that change effective. Then attempt the LDAPS connections.

[AnthonyCSheehy]

Well firstly, both DCs Certificates are added to tomcat-trust as per documentation. The CA Certificate is also registered with tomcat-trust. The tomcat service has been restarted. The Certificates appear in the Dirsync trace. Besides, when this is the issue, you get an error in the interface when saving the LDAP page. There are no errors. 

And secondly, there is no way the certificates will verify on an IP address as opposed to a FQDN. The DC certs are issued from the CA based on AD information, not IP Address. 

[Roger Kallberg]

Speculation but could it be that you might use IP addresses for the configuration of the LDAP servers in CUC?

Example of config from one of our systems as a reference.

[AnthonyCSheehy]

Thanks @Roger Kallberg but as noted in the OP, FQDNs were provided. The trace also confirms that Dirsync removes the FQDN and replaces it with an IP Address.

[getHostAddress] Hostname=dc.**********.uk
[getHostAddress] Result string = 192.**.**.***
[makeConnection] New LDAP URL : ldaps://192.**.**.****:636
acquiring the default SSL socket factory
Creating DirSync Customized SSL Socket
ldaps://192.**.**.***:636 - javax.naming.CommunicationException: 192.**.**.***:636 [Root exception is javax.net.ssl.SSLException: Certificate not verified.]

There's no software on earth that will correctly connect to that URL unless you ignore certificate validation or use the IPv4 in the SAN on the server certificate, which is not an option for a Microsoft CA issued auto-enrolment.

[Roger Kallberg]

Something is truly off with this as your OP mention port 3269 and the log snippet says port 636. I think you'll need to reach out to the trusty TAC to sort this one out. We're on 12.5 and have not seen this and if I recall we might have been on 11.5 at the time of making the switch to secure LDAP, but I don't really remember the specifics for this as it was at least 18 months ago.

[AnthonyCSheehy]

Yes - 3269 is the global catalog LDAPS port (which allegedly provides better performance than the standard 636.) We tried both with the same response! We have reached out to our partners on this - but every avenue that helps...

[AnthonyCSheehy]

Update: After talking to our Partners, we restarted the Dirsync service.

Now - the LDAP interface throws up unverified certificate errors... but the dirsync service is now syncing users! Go figure!