ldap@mm.st writes:
While sniffing traffic using tcpdump and using various ldapsearch options I noticed that if the client doesn't request starttls or connect on 636 is is possible to grab a users ldap record and the transmission is in clear text.
Yup...
If I authenticate to the server using the -W option to ldapsearch the record is sent with the SSHA encrypted password.
No, -W has nothing to do with it. ldaps:// or -Z(Z) does. Packet-sniff "ldapwhoami -xh ldap://<server>/ -W" without -Z to see.
I guess this behavior is expected since the server is listening on 389 and it is up to the client to initialize the starttls session, but I was wondering if there was a way to force the server to only use starttls on 398 and not rely on the the client to set up starttls?
No, it's the client which takes the initiative to send Bind with an unencrypted password as its first network packet, without a StartTLS first. The best you can do is to make the server complain in the hope that the user will learn to Not Do That. We use this:
security simple_bind=128 update_ssf=128 localSSF 128
The first returns the error "Confidentiality required" to Bind and update requests with security strength < 128, the 2nd raises the security strength which slapd considers ldapi:// to have, so we don't receive that error when updating the database over ldapi://.
(I don't know what would be good values nowadays, the rationale of these numbers are lost in the mist of time. The default for localSSF is 71, so maybe that's fine for security too.)
One option would be to only have the server start on 636 and not have it listen on 389, but we would like to keep the same functionality if possible. Am I missing something obvious? The only option that I see as a possiblity is the TLSVerifyClient { never | allow | try | demand } in slapd.conf. But, it's unclear to me if this will provide the desired effect.
It won't. That is about what happens when the client does use TLS, it doesn't affect what happens when it doesn't.