I am in the process of moving our older existing openldap server infrastructure that we use to authenticate multiple users to our Linux infrastructure to use RH5 openldap 2.3 server. The current ldap servers support starttls and listen on 389 and 636. We want to continue with this setup. 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. If I authenticate to the server using the -W option to ldapsearch the record is sent with the SSHA encrypted password. Also in the in the tcpdump stream my password I use to authenticate to the server is sent in clear text.
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? 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.