#640774 Unable to login with cached LDAP credentials - stoping nslcd fixes the issue

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
#640774#5
Date:
2011-09-07 06:44:22 UTC
From:
To:
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

#640774#10
Date:
2011-10-02 19:12:13 UTC
From:
To:
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.

#640774#17
Date:
2015-04-15 17:07:04 UTC
From:
To:
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

#640774#24
Date:
2015-04-16 20:39:59 UTC
From:
To:
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,

#640774#29
Date:
2015-04-17 17:28:33 UTC
From:
To:
---end quoted text---

  Please find /etc/pam.d/common-auth attached.

#640774#34
Date:
2015-04-19 18:57:21 UTC
From:
To:
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

#640774#39
Date:
2015-08-05 17:23:31 UTC
From:
To:
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