Re: not so clear about tls and replica

[Aaron Richton <richton@nbcs.rutgers.edu>]

> 1. when client connect to OpenLDAP server with TLS, does it use port 389
> or port 636?  ( I tried to test it with  "openssl s_client -connect
> ldap.example.com:389 blah blah.. ".  when I used port 389, it faild but
> port 636 is ok.   Does it mean TLS always use port 636? )

See the excellent FAQ entry http://www.openldap.org/faq/data/cache/185.html

> 2. I run my OpenLDAP server on both port 389 and 636 ( again with TLS ). I
> have set "TLSVerifyClient demand".  However, people can still search my
> directory on port 389 as anonymous.  I thought with "TLSVerifyClient
> demand", client need to have a valid certificate in order to connect to
> the server. is that right?
I think the certificate will be validated if presented, but TLS won't be
necessary server-wide without a corresponding directive such as "security
tls=1" present. i.e. "anonymous" may never present a TLS handshake
(ergo never presents a cert), so there's no cert to be demanded/verified
by TLSVerifyClient directive.

> 3. I have replication working between master/slave but I think the way I
> am setting the replication is not very secure.  can someone suggest a
> better way to replica between the master/slave.  Perphar something simple
> without Kerberos ,etc... :)
As a simple enhancement, if you have TLS/SSL working, you could specify
starttls option to your replica statement or switch it to ldaps://. At
least then your bindpw won't go over the wire in cleartext. As you
mention, there are much more elaborate SASL/GSSAPI/etc. options available.
The admin guide and list archives are good resources if you want to try them.

> 4. on my slave's slapd.conf.  I have this "updateref
> ldap://server.example.com"; but I don't think this is right as I am using
> TLS.  I will assume this should be "updateref ldaps://server.example.com"
Chasing the referral is a client's responsibility. Personally, I would
hope that a well coded client would try to negotiate appropriate transport
security for all connections, ldap:// or ldaps://. I'm going to go out on
a limb and claim that not all clients are well coded. You'll probably have
to experiment to see what works best in your environment.