Solved: AD LDS authentication with SSL on 10.5.2

Jakub Stroinski · ‎08-29-2015

Recently we updated our CUCM from version 10.5.2.10000-5 to version 10.5.2.12901-1

Before the update we were authenticating our users with no trouble using LDAP AD LDS over SSL. Immediately after the update, authentication has been broken and none of our users are able to login to their phone management, Jabber or CAD. I've perused the release notes and saw nothing related to this.

We have SSL certificates that contain the FQDN of the AD provider and it is resolvable in DNS from CUCM. Setting the IP address/FQDN in the server settings in LDAP does not change the behaviour.

Error message in CUCM phone management is "An LDAP error has occurred. Please contact your administrator"

Does anyone have any ideas why this has stopped working? I've presently disabled SSL in CUCM and SSL requirements on the AD LDS provider but this is a bandaid solution and it cannot stay this way for long.

Jonathan Schulenberg · ‎08-29-2015

Take a look at the certificates presented and verify that the CN= attribute matches what you have defined as the server name. IPv4 won't work since that wouldn't be in a certificate; however, it's possible there is some other difference such as only the server hostname vs. the FQDN.

After that make sure you have the entire certificate chain installed, not only the LDS server certificate. Assuming that you have a Microsoft CA in place you need to install the root CA as well as any intermediary CAs into the Tomcat-trust store on every CUCM node.

If neither of those address it I suggest pulling DirSync and Tomcat Security traces. Those should show where the breakdown in the SSL handshake occurred.

PS- Make sure that your username is in Distinguished Name format and not simply the username attribute sAMAccountName. I see a lot of installs make this mistake. You can use ADSI Edit to verify what the DN is but it should look similar to this: CN=Display Name,OU=Service Accounts,DC=cisco,DC=com

View solution in original post

Jonathan Schulenberg · ‎08-29-2015

Take a look at the certificates presented and verify that the CN= attribute matches what you have defined as the server name. IPv4 won't work since that wouldn't be in a certificate; however, it's possible there is some other difference such as only the server hostname vs. the FQDN.

After that make sure you have the entire certificate chain installed, not only the LDS server certificate. Assuming that you have a Microsoft CA in place you need to install the root CA as well as any intermediary CAs into the Tomcat-trust store on every CUCM node.

If neither of those address it I suggest pulling DirSync and Tomcat Security traces. Those should show where the breakdown in the SSL handshake occurred.

PS- Make sure that your username is in Distinguished Name format and not simply the username attribute sAMAccountName. I see a lot of installs make this mistake. You can use ADSI Edit to verify what the DN is but it should look similar to this: CN=Display Name,OU=Service Accounts,DC=cisco,DC=com

Jakub Stroinski · ‎09-17-2015

Finally got this sorted out. Like Jonathan said, it was a certificate issue. The certificate was accepted for authentication but it seems Jabber CTI didn't want to accept our self-signed certificate. We bought a certificate and installed that one (plus root) and it works immediately.