Huh. Okay, well, that is actually the worst possible case then that
comes out of the debate between Howard and I. It isn't configurable and
you can get a false positive when testing it the way I mentioned. Sigh.

-----Original Message-----
[] On Behalf Of joe
Sent: Monday, November 30, 2009 6:56 AM
To: 'LDAP list'
Subject: [ldap] Re: ldap ssl MS AD

Unfortunately that is incorrect. The DC will open port 636 regardless of
whether or not it is ready for LDAPS traffic. For example, if you don't
a cert installed on the server it will still open 636. As soon as the
sends Client Hello the server will RST the connection. You will be able
connect via TCP but not perform the SSL handshake. The LDAP ports used
by a
DC are hardcoded into the AD code, they cannot be changed. ADAM (or
ports, OTOH, can be configured as needed. 

You can argue all day about the goodness or badness of it but the logic
doing so isn't really solid unless you are in a position to be able to
something about it. I mentioned some time ago to MSFT that it should be
configurable to make sure that point was made and then just forgot about
IMO, MSFT is not going to change it on the fly for current operating
due to some other hardcoded dependencies in the OS, specifically a)
not fully using the SRV records to find LDAP services (specifically the
port) and b) the lack of any LDAPS SRV records being published by the
Last I looked at it, StartTLS works fine through 389/3268.

The OP's issue is possibly due to not having the CA's cert on the


O'Reilly Active Directory Fourth Edition -

-----Original Message-----
[] On Behalf Of
Sent: Friday, November 27, 2009 11:19 AM
To: Howard Chu; LDAP list
Subject: [ldap] Re: ldap ssl MS AD

No, it's not. If a Windows AD DC is listening on port 636/tcp, it can
safely be assumed that SSL is running, unless someone has mucked around
with the Registry and changed the default ports.

-----Original Message-----
[] On Behalf Of
Howard Chu
Sent: Thursday, November 26, 2009 2:02 AM
To: LDAP list
Subject: [ldap] Re: ldap ssl MS AD

> From: Simon Walter<>
> Date: Thu, 26 Nov 2009 09:37:47 +0900

> Dustin Puryear wrote:
>> If you connect to port 636/tcp on a DC via ldp.exe then SSL is

That's assuming quite a lot, since port 636 is not officially reserved
for SSL 
use in any IETF/IANA registry.

> OK that's good news. So since I can connect with ldp.exe, what should
> be doing to connect via ldapsearch? This is what I've tried:
> $ ldapsearch -W -LLL -E pr=200/noprompt -h adserver -p 636 -D
> "" -b "dc=domain, dc=com" -s sub "(cn=*)" cn mail sn
> Should it work?

No. Specifying the port number only does that, it doesn't turn on SSL at
(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

> There was one thing I was not sure of, do I need to
> install a certificate on the client? That was never very clear to me
> what I've read so far.

Then you haven't been reading the right docs. Try this instead:

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

Reply via email to