Trying to determine if LDAP over SSL is working using LDP.exe

Question

Hi,
I just wanted to confirm that LDAP over SSL is working properly on our domain controller.  When I connect using LDP.exe on my Windows 7 computer, I get the following output:
ld = ldap_sslinit("dc1.domain.com", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 128 bits
Established connection to dc1.domain.com.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
<unnecessary details>
It looks like it is working, but I wasn't sure if the Error 0's mean there is some sort of problem.
Also, when I run a Simple bind with my credentials, I get the following output:
res = ldap_simple_bind_s(ld, 'myuseraccount-at-domaindotcom', <unavailable>); // v.3
Authenticated as: 'DOMAIN\myuseraccount'.
Finally, when I run a Bind as currently logged on user (with Encrypt traffic after bind checked), I get the following output:
53 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
{NtAuthIdentity: User='NULL'; Pwd=<unavailable>; domain = 'NULL'}
Authenticated as: 'DOMAIN\myuseraccount'.
I followed all the instructions found in Microsoft article KB-321051 to get LDAP over SSL working with a valid 3rd party certificate on one of our Windows 2008 R2 domain controllers.  However, when I test Active Directory Authentication on our
WatchGuard Management Server after importing the CA certificate, the test fails.  In order to use Active Directory Authentication, LDAPS (LDAP over SSL) must be enabled in the Active Directory domain and I am not 100% sure that it is enabled properly.
Any advice or additional insight would be greatly appreciated.
Thanks!

Answer 1

Some ideas:
DNS Name: KB-321051 says that you need the DNS name in either Subject CN or Subject Alternative Name. Which one did you use? Windows clients are fine with an empty CN and only the SAN populated (there the "either or" statement in the article)
but third-party tools often look for the DNS name in the Subject CN.
Even if the WatchGuard Server runs on Windows it might use its own certificate checking logic.
DC certificate(s): Does the DC have more than this certificate? If yes I'd run a network trace to check which one the machine is actually sending in the SSL handshake.
Chaining issues at your LDAP client / the WatchGuard Management Server:
Very often such issues are related to the fact that the certificate chain is not validated properly. Some typical issues:
It is not clear whether the client uses the Windows certificate store (even if it runs on a Windows server).
Tools / systems / PKI clients can only deal with a single root CA, not with a hierarchy.
You need to import both Root and intermediate CAs as the client cannot fetch the intermediates from AIA URLs.
The client cannot access CRL URLs because of firewalls rules or missing access (e.g.: A CRL URL in AD is used but the client does not have an AD user in whose context it would try to fetch the CRL).
The client has issues with blanks or special characters in CDP or AIA URLs.
Having a quick look at
WatchGuard documentation it seems to me that they are using their own certificate stores you need to import CA certificates to. And they only mention a "Root CA" so if your PKI has two levels you might need to import both CAs to the so-called Root store.
Elke