We're trying to perform an LDAPS bind to a server which blocks 389 with a firewall so all traffic must travel over 636.
In our test lab we're connecting to a test ldap (located on the same server) which does not have this firewall so both ports are exposed. Running ldp.exe on the test server we generate the trace below which seems to suggest that it is successfully binding over 636. However if we monitor the traffic with wireshark all the traffic is being sent to 389 with no attempt to even contact 636.
Other tools will bind only with SSL on 636 or without SSL on 389 whjich seems to suggest it is behaving correctly but Wireshark shows 389.
Only the test server we are using RawCap to capture the local loopback traffic.
Any ideas?
0x0 = ldap_unbind(ld);
ld = ldap_sslinit("WIN-GF49504Q77T.test.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 WIN-GF49504Q77T.test.com.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
Best Answer
I would start by verifying the certificate as follows.
How to troubleshoot LDAP over SSL connection problems
http://support.microsoft.com/kb/938703
Step 1: Verify the Server Authentication certificate
Make sure that the Server Authentication certificate that you use meets the following requirements:
The Active Directory fully qualified domain name of the domain controller appears in one of the following locations:
The Subject Alternative Name (SAN) extension in the DNS entry
certutil -v -urlfetch -verify serverssl.cer > output.txt
Open the Output.txt file, and then search for errors.
Step 2: Verify the Client Authentication certificate
In some cases, LDAPS uses a Client Authentication certificate if it is available on the client computer. If such a certificate is available, make sure that the certificate meets the following requirements:
The certificate chain is valid on the domain controller. To determine whether the certificate is valid, follow these steps:
At the command prompt, type the following command to send the command output to a file that is named Outputclient.txt:
certutil -v -urlfetch -verify serverssl.cer > outputclient.txt
Open the Outputclient.txt file, and then search for errors.
Step 3: Check for multiple SSL certificates
Determine whether multiple SSL certificates meet the requirements that are described in step 1. Schannel (the Microsoft SSL provider) selects the first valid certificate that Schannel finds in the Local Computer store. If multiple valid certificates are available in the Local Computer store, Schannel may not select the correct certificate. A conflict with a certification authority (CA) certificate may occur if the CA is installed on a domain controller that you are trying to access through LDAPS.
Step 4: Verify the LDAPS connection on the server
Use the Ldp.exe tool on the domain controller to try to connect to the server by using port 636. If you cannot connect to the server by using port 636, see the errors that Ldp.exe generates. Also, view the Event Viewer logs to find errors. For more information about how to use Ldp.exe to connect to port 636, click the following article number to view the article in the Microsoft Knowledge Base:
321051 How to enable LDAP over SSL with a third-party certification authority
http://support.microsoft.com/kb/321051
Step 5: Enable Schannel logging
Enable Schannel event logging on the server and on the client computer. For more information about how to enable Schannel event logging, click the following article number to view the article in the Microsoft Knowledge Base:
260729 How to enable Schannel event logging in IIS
http://support.microsoft.com/kb/260729