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-----
From: bounce-ldap-3356...@listserver.itd.umich.edu
[mailto:bounce-ldap-3356...@listserver.itd.umich.edu] 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
have
a cert installed on the server it will still open 636. As soon as the
client
sends Client Hello the server will RST the connection. You will be able
to
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
ADLDS)
ports, OTOH, can be configured as needed. 

You can argue all day about the goodness or badness of it but the logic
in
doing so isn't really solid unless you are in a position to be able to
do
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
it.
IMO, MSFT is not going to change it on the fly for current operating
systems
due to some other hardcoded dependencies in the OS, specifically a)
machines
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
DCs.
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
machine. 

  joe

--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm



-----Original Message-----
From: bounce-ldap-5210...@listserver.itd.umich.edu
[mailto:bounce-ldap-5210...@listserver.itd.umich.edu] On Behalf Of
Dustin
Puryear
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-----
From: bounce-ldap-3356...@listserver.itd.umich.edu
[mailto:bounce-ldap-3356...@listserver.itd.umich.edu] 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<simon.wal...@hokkaidotracks.com>
> 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
enabled.

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
I
> be doing to connect via ldapsearch? This is what I've tried:
>
> $ ldapsearch -W -LLL -E pr=200/noprompt -h adserver -p 636 -D
> "u...@domain.com" -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
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

> 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
in
> what I've read so far.

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

http://www.openldap.org/doc/admin24/tls.html

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/








Reply via email to