Linux – I cannot su when LDAP is running

debianldaplinuxpam

I have problem with ldap, that when it is online, I login with user/pass from LDAP db and then cannot su to root with local pass. When I turn offline LDAP I can login with local user/pass and su to root with local pass. auth.log:

Sep 27 12:18:33 intranet sshd[18321]: pam_unix(sshd:session): session opened for user mejmo by (uid=0)
Sep 27 12:18:39 intranet unix_chkpwd[18340]: check pass; user unknown
Sep 27 12:18:39 intranet unix_chkpwd[18340]: password check failed for user (root)
Sep 27 12:18:39 intranet su[18339]: pam_unix(su:auth): authentication failure; logname=mejmo uid=10009 euid=10009 tty=/dev/pts/1 ruser=mejmo rhost=  user=r
Sep 27 12:18:42 intranet su[18339]: pam_authenticate: Permission denied
Sep 27 12:18:42 intranet su[18339]: FAILED su for root by mejmo

I'm typing the good password, because I can login when LDAP server is offline. Please help, getting crazy …

EDIT: I figured out, that when I create user locally as well, turn LDAP online, then I am able to su to root. I think the problem is, that pam_unix can't see the user that is using su, because there is no entry in passwd, but nssswitch.conf is ok (files ldap on passwd,shadow,etc.)

EDIT2:

account         sufficient      pam_ldap.so debug
account         sufficient      pam_unix.so audit

auth    sufficient      pam_ldap.so
auth    sufficient      pam_unix.so audit likeauth use_first_pass
auth    required        pam_deny.so

EDIT3: It works with nscd running, but it does nasty logs and occasionally I cannot login .. Where could be the problem with nscd ? 🙁 

Sep 27 16:27:35 intranet sshd[25830]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Sep 27 16:27:35 intranet sshd[25830]: pam_ldap: reconnecting to LDAP server...
Sep 27 16:27:35 intranet sshd[25830]: pam_ldap: ldap_simple_bind Can't contact LDAP server

Best Answer

Are you sure that you check the local authentication first, then the LDAP backend ?

Check your /etc/nsswitch.conf

It should show:

passwd: files ldap group: files ldap shadow: files ldap

or maybe also the "compat" option

Edit:

nscd has been a source of problems on my RHEL machines, creating bugs where you'd never expected one from nscd. So the answer is yes, nscd can be the cause of this strange behavior. You should try to clean the cache of nscd during your tests.

nscd -i passwd nscd -i group

Related Topic