Description of problem: KDE sessions do not login properly under some configurations that use ldap user authentication. Specifically, if the ldap host in /etc/ldap.conf is configured using a FQDN instead of an IP address, the following is reported in the syslog: Apr 7 15:09:57 somehost dbus: nss_ldap: failed to bind to LDAP server ldap://ldap.example.com: Can't contact LDAP server Apr 7 15:09:57 somehost dbus: nss_ldap: could not search LDAP server - Server is unavailable If I set the ldap client configuration in /etc/ldap.conf to use a fully-resolved IP address, then KDE is able log users in without a problem. Version-Release number of selected component (if applicable): I'm not sure which package this is associated with. I'm running a F9 system (8.93) with rawhide components. Some that may be of interest: nss_ldap-259-1.fc9.x86_64 kdelibs-4.0.3-6.fc9.x86_64 dbus-qt-0.70-4.fc9.x86_64 dbus-libs-1.2.1-1.fc9.x86_64 dbus-1.2.1-1.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure the system with ldap user authentication 2. Configure the ldap authentication source to use a FQDN instead of an IP address 3. Create a non-local user (only exists in LDAP) 4. Try to log in Actual results: The login stalls after a few minutes. The syslog reports nss_ldap errors, and the desktop login messages start to report dbus connection failures. Expected results: Additional info: On this same system, I verified that local users (not in LDAP) are not affected.
Are you using SSL? If so, what does the server's certificate contain? Can you attach your /etc/ldap.conf and /etc/nsswitch.conf files?
Created attachment 302481 [details] /etc/ldap.conf
Created attachment 302482 [details] /etc/nsswitch.conf
The ldap server on my LAN is not using SSL, and allows unauthenticated queries from the local subnet. That is, I can run queries like ldapsearch -x -b ou=People,dc=ursus,dc=net 'uid=someuser' without entering a password or bind DN. Slapd has other ACLs (with DNs and passwords) also for things like password change. The 'host' entry in ldap.conf is the only difference between the working- and non-working configurations. In the working configuration, 'host' spells out an IP address. In the non-working configuration, 'host' spells out an FQDN.
Hmm, so that's a "no" on SSL then. (This looked like a certificate subject name mismatch, but no joy.) It doesn't look like it's KDE-specific -- something weird's going on inside of gdm, but I haven't chased it beyond that level yet.
Can you check if the packages built at http://koji.fedoraproject.org/koji/buildinfo?buildID=46358 make this work as expected? (It's a pretty nasty hack, but as we're running out of time for F9 it might be all we have time to do.)
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
This appears to work fine now with when I revert the ldap server to a FQDN instead of an IP address. At least, the initial login works, which is where I saw the issue. I'll report back if I seen any other issues, but AFAIK this is fixed. Thanks, and sorry for the delay.