Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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)
share|improve this question
    
Is there a certificate available to negotiate an SSL connection? –  Greg Askew Jul 31 '12 at 14:56
    
if i connect using novell.com/coolsolutions/tools/13765.html i am challenged to accept the certificate –  Ikkoras Jul 31 '12 at 15:05
    
Are you sure about this? Is this trace from the test lab server or the external server? Your question is confusingly worded actually, it's not clear what happens in which situation. –  EJP Jul 31 '12 at 23:50
    
The trace is from the test lab server. Somewhere there is cert handling issue as once we added a cert ignoring statement to our test code that was able to bind as well. However wireshark still shows port 389. I'll try to restructure the question to make it a bit clearer. –  Ikkoras Aug 1 '12 at 9:59
    
This must be a problem with the observations. The LDAP server won't attempt SSL on port 389, or plaintext on port 636, so if it works it must be going to the right ports. Are you sure Wireshark is really saying port 389? or maybe just 'LDAP'? And is port 389 visible inside the TCP packets? –  EJP Aug 1 '12 at 10:10
add comment

2 Answers

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 common name (CN) in the Subject field
    • The Subject Alternative Name (SAN) extension in the DNS entry

      • The enhanced key usage extension includes the Server Authentication object identifier (1.3.6.1.5.5.7.3.1).
      • The associated private key is available on the domain controller. To verify that the key is available, use the certutil -verifykeys command.
      • The certificate chain is valid on the client computer. To determine whether the certificate is valid, follow these steps:
        1. On the domain controller, use the Certificates snap-in to export the SSL certificate to a file that is named Serverssl.cer.
        2. Copy the Serverssl.cer file to the client computer.
        3. On the client computer, open a Command Prompt window.
        4. At the command prompt, type the following command to send the command output to a file that is named Output.txt:

      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 enhanced key usage extension includes the Client Authentication object identifier (1.3.6.1.5.5.7.3.2).
  • The associated private key is available on the client computer. To verify that the key is available, use the certutil -verifykeys command.
  • The certificate chain is valid on the domain controller. To determine whether the certificate is valid, follow these steps:

    1. On the client computer, use the Certificates snap-in to export the SSL certificate to a file that is named Clientssl.cer.
    2. Copy the Clientssl.cer file to the server.
    3. On the server, open a Command Prompt window.
    4. 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

share|improve this answer
    
Why? He doesnt have an SSL connection problem. He already has a working SSL connection, and has retrieved the bad DSA information. The question is about ports. Spectactular, but not an answer. –  EJP Jul 31 '12 at 23:49
add comment

+1 EJP. In your wireshark capture make sure you aren't inadvertently filtering out 636 traffic with a capture filter, or just simply doing "ldap" using the display filter. Verify the the src/dst ip addresses, and port (numbers not alias) you are expecting in the trace.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.