Patrick Nelson wrote: ----------------->>>> Putting ssl yes in ldap.conf doesn't really do (at least it doesn't seem to) anything different. The results were the same.
So just running authconfig and setting values for server, base DN, and selecting Use TLS, should do this... OK cool a tool... The moment of truth or at least committal What happens if it doesn't work? Single user mode and then turn off all the settings in authconfig? ----------------->>>> Committed myself on one system then did packet capture on the ldap server during login and logout and looked at all the packet data and sure enough it's encrypted, even though it is going across the 389 port (ldap) and not the 636 port (ldaps). I noticed that prior to a block of data being sent (it is seen as an invalid ldap message by the sniffer) there seemed to be the ssl cert which I could see because of some text in the packet which had [EMAIL PROTECTED] in it which I don't have anywhere in the ldap data. I then ran the previous test and examined the data: Results matched the above findings. The only time ldap tools use port 636 is when specifically told to by using -H ldaps://<ldap server>. If -Z (or -ZZ) is used the SSL/TLS is utilized on 389, but if -Z (-ZZ) is not used then everything is clear text. Just some good info. Onto locking down permissions in slap.conf and then maybe start moving out to production. -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
