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
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:
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
The login stalls after a few minutes. The syslog reports nss_ldap errors, and
the desktop login messages start to report dbus connection failures.
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]
Created attachment 302482 [details]
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:
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
Thanks, and sorry for the delay.