- Package:
- nslcd
- Source:
- nss-pam-ldapd
- Description:
- daemon for NSS and PAM lookups using LDAP
- Submitter:
- ganomi
- Date:
- 2015-08-05 17:30:04 UTC
- Severity:
- normal
ISSUE =============== Unable to login with cached LDAP credentials - stoping nslcd fixes the issue Packes installed on the client: libpam-ldapd libnss-ldapd nslcd nscd libpam-ccreds libpam-mklocaluser LDAP/Kerberos logins are working well when I am connected to the network. nscd was adjusted to allow keep credentials longer. If I try to login without access to the network I will pass the login screen, which reports that I am using cached credentials, but the screen goes black and stays there. The following messages are logged: Sep 7 10:57:01 clientmachine nslcd[1998]: [95f874] <host="1.debian.pool.ntp.org"> no available LDAP server found: Server is unavailable Sep 7 10:57:01 clientmachine nslcd[1998]: [138641] <host="2.debian.pool.ntp.org"> no available LDAP server found: Server is unavailable Sep 7 10:57:01 clientmachine nslcd[1998]: [7ff521] <host="2.debian.pool.ntp.org"> no available LDAP server found: Server is unavailable Sep 7 10:57:01 clientmachine nslcd[1998]: [3dbd3d] <host="3.debian.pool.ntp.org"> no available LDAP server found: Server is unavailable Sep 7 10:57:01 clientmachine nslcd[1998]: [7b8ddc] <host="3.debian.pool.ntp.org"> no available LDAP server found: Server is unavailable Sep 7 10:57:29 clientmachine nslcd[1998]: [eaf087] <host="ldapserver.30.168.192.in-addr.arpa"> failed to bind to LDAP server ldap://ldapserver.domain.tld: Can't contact LDAP server: Transport endpoint is not connected Sep 7 10:57:29 clientmachine nslcd[1998]: [eaf087] <host="ldapserver.30.168.192.in-addr.arpa"> no available LDAP server found: Can't contact LDAP server Sep 7 10:57:29 clientmachine nslcd[1998]: [221a70] <host="ldapserver.30.168.192.in-addr.arpa"> no available LDAP server found: Server is unavailable Sep 7 10:59:29 clientmachine nslcd[1998]: [16dde9] <host="ldapserver.30.168.192.in-addr.arpa"> failed to bind to LDAP server ldap://ldapserver.domain.tld: Can't contact LDAP server: Transport endpoint is not connected Sep 7 10:59:29 clientmachine nslcd[1998]: [16dde9] <host="ldapserver.30.168.192.in-addr.arpa"> no available LDAP server found: Can't contact LDAP server Sep 7 10:59:29 clientmachine nslcd[1998]: [06c83e] <host="ldapserver.30.168.192.in-addr.arpa"> no available LDAP server found: Server is unavailable Sep 7 11:01:29 clientmachine nslcd[1998]: [4fd4a1] <host="ldapserver.30.168.192.in-addr.arpa"> failed to bind to LDAP server ldap://ldapserver.domain.tld: Can't contact LDAP server: Transport endpoint is not connected Sep 7 11:01:29 clientmachine nslcd[1998]: [4fd4a1] <host="ldapserver.30.168.192.in-addr.arpa"> no available LDAP server found: Can't contact LDAP server Sep 7 11:01:29 clientmachine nslcd[1998]: [9ac241] <host="ldapserver.30.168.192.in-addr.arpa"> no available LDAP server found: Server is unavailable WORKAROUND =============== Stoping the nslcd daemon fixes the problem # /etc/init.d/nslcd stop Then I can login without access to network with cached LDAP credentials without any problem. Any idea? Thanks Jiri
Sorry to not reply sooner. I don't think you use nscd to cache the credentials, only the account information. That being said nscd doesn't cache all queries. For instance it doesn't cache "get all users" queries. I must say I don't have that much experience with a setup like yours (libpam-ccreds and libpam-mklocaluser) but the following log messages are all related to failing hostname lookups. Some of these seem to be hostname lookups for the LDAP server itself (or some broken reverse lookups). If you enable hostname lookups through LDAP it is often a good idea to specify the URI with an IP address instead of a host name. This avoids bootstrapping problems in some cases. The others are NTP servers. Perhaps something is starting NTP when you login (NetworkManager comes to mind)? A workaround could be (depending on your setup) would be to stop nslcd on network down and start it when the network goes up. If you're using /etc/network/interfaces, the post-up and pre-down options should do the trick. Hope this helps.
found 647978 0.9.4-3 found 640774 0.9.4-3 quit Hello, I am experiencing the issue of login failure with cached credentials, yet stopping nslcd no longer helps, rather I get this in /var/log/auth.log: Apr 15 18:19:42 myhostname login[13342]: pam_ldap(login:auth): error opening connection to nslcd: No such file or directory
Could you provide the contents of /etc/pam.d/common-auth? The default configuration has auth [success=1 default=ignore] pam_ldap.so minimum_uid=1000 use_first_pass which is supposed to ignore PAM_AUTHINFO_UNAVAIL and continue with the next PAM module. Thanks,
---end quoted text--- Please find /etc/pam.d/common-auth attached.
that package or a configuration mix-up. Anyway, if I disable shadow lookups via ldap in /etc/nsswitch.conf I got it to work, otherwise the PAM stack fails with: authpriv.err su[9407]: pam_acct_mgmt: Authentication failure which seems to indicate that something is going wrong in the account (authorisation) part of PAM. I've added debug to pam_unix and pam_ldap in /etc/pam.d/common-account but neither module seems to be logging anything. Without shadow lookups via LDAP at least pam_ldap logs in the account check that it can't connect to nslcd if it is not running. Also, now login works (but slow) if nslcd is still running but the LDAP server is reachable. Some background on the intricacies of the PAM stack can be found here: https://bugs.debian.org/583492
connection to nslcd: No such file or directory I've found out that nslcd init script does not properly process nlscd error messages, and says OK whet running actually fails. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794686 check /var/run/nslcd/ to see if nlscd is actually running. If it is not, run nslcd manually # nslcd and it will tell you why id does not want to start