Right about Michael's note. And to reiterate a point I made much earlier, LOOK 
AT THE WINDOWS EVENT LOG! Windows is really very good about telling you when 
something is wrong, but you need to go to the Event Log to find the message.

-----Original Message-----
From: bounce-ldap-3356...@listserver.itd.umich.edu 
[mailto:bounce-ldap-3356...@listserver.itd.umich.edu] On Behalf Of Michael 
Sent: Friday, November 27, 2009 5:07 AM
To: LDAP list
Subject: [ldap] Re: ldap ssl MS AD

Howard Chu wrote:
>> From: Simon Walter <simon.wal...@hokkaidotracks.com>
>> Date: Thu, 26 Nov 2009 17:41:15 +0900
>> Howard Chu wrote:
>>> > No. Specifying the port number only does that, it doesn't turn on SSL
>>> > at all. (Nor should it. The Microsoft tools are, as usual, playing
>>> > fast and loose with the LDAP specs.) The way to get SSL is to use a
>>> > URI, and stop using the old/deprecated -h and -p options. Read the
>>> > ldapsearch(1) manpage.
>>> >
>>> >    ldapsearch -H ldaps://adserver:636
>> Thanks Howard. I've tried that as well and have read some of the man
>> page. However, I suspect that perhaps the server is not configured
>> correctly if the above should work. I still get:
>> ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
> Try it with -d7 and see what kind of network traffic shows up. It will
> also show you the SSL handshake, if the server actually answered.

If you haven't correctly configured the SSL server cert and the accompanying
CA cert(s) in the DC's server profile you can connect to port 636 at TCP level
but SSL handshake will fail. So use the MMC snap-in certmgr.msc and configure
the _server's_ cert store.

Ciao, Michael.

Reply via email to