Description of problem: authconfig cannot create a proper authorization system when trying to auth to an ldap server that requires SSL. Version-Release number of selected component (if applicable): authconfig-5.3.21-3.el5 nss_ldap-253-13.el5_2.1 How reproducible: always Steps to Reproduce: 1. Fresh 5.2 install, seperate ldap server using ssl 2. craft authconfig command: authconfig --kickstart --nostart --enableshadow --enablemd5 --disablecache --enablelocauthorize --enableldap --enableldapauth --ldapserver ldaps://mytestserver1.ucla.edu,ldaps://mytestserver2.design.ucla.edu --ldapbasedn dc=test,dc=ucla,dc=edu Actual results: /etc/ldap.conf gets created/modified with a line saying: "ssl no" which causes the auth to fail (and the system to hang on most any command) adding the --enableldaptls option sets "ssl start_tls" which also fails since this is an ldaps:// URL (though this would work fine for regular ldap:// URLs that support TLS). Expected results: either an option to --enableldapssl or automatic checking for ldaps:// URLS such that the end result is an /etc/ldap.conf file that contains the line: "ssl yes"
Actually nss_ldap should be fixed to ignore ssl yes/no setting when uri is used instead of host. It should just look whether ssl start_tls is used and then try to issue the start tls commands. But otherwise it should switch ssl on and off based on whether ldap or ldaps is used in the uri. The ssl setting is just a single setting but there might be multiple ldap and ldaps uris mixed.
The nss_ldap version in current Rawhide works exactly like this so this is just a matter of backport.
that sounds good. I should note that when upgrading from 5.1 to 5.2 the upgrade process hung halfway through. Turns out that was because the behaviour in dealing with ldap.conf changed. I used to have ssl=no now I have ssl=yes with ldaps:// URIs. When that behavior changed it caused my update to fail since some of the later updates involved using useradd, which was just hanging without timeout trying to get at the ldap stuff... anyway, thanks for taking care of this. -alan
*** Bug 450604 has been marked as a duplicate of this bug. ***
*** Bug 241887 has been marked as a duplicate of this bug. ***