On Sun, 2010-11-21 at 22:35 +0100, Vincent Danjean wrote: > I added "debug" for pam_ldap.so into the 5 common-* files in /etc/pam.d > Then, I started "nslcd -d" > And then I type "sudo su" > > Here what I get in /var/log/auth.log: > [after the first wrong password] > Nov 21 22:11:30 aya sudo: pam_unix(sudo:auth): authentication failure; > logname=vdanjean uid=0 euid=0 tty=/dev/pts/7 ruser=vdanjean rhost= > user=vdanjean > Nov 21 22:11:30 aya sudo: pam_ldap(sudo:auth): nslcd authentication; > user=vdanjean > Nov 21 22:11:30 aya sudo: pam_ldap(sudo:auth): Échec d'authentification; > user=vdanjean > [after the second correct password] > Nov 21 22:11:42 aya sudo: pam_ldap(sudo:account): nslcd authorisation; > user=vdanjean > Nov 21 22:11:42 aya sudo: pam_ldap(sudo:account): ; user=vdanjean > Nov 21 22:11:42 aya sudo: vdanjean : pam_acct_mgmt: 7 ; TTY=pts/7 ; > PWD=/home/vdanjean ; USER=root ; COMMAND=/bin/su > [after the third correct password] > Nov 21 22:11:49 aya sudo: pam_ldap(sudo:account): nslcd authorisation; > user=vdanjean > Nov 21 22:11:49 aya sudo: pam_ldap(sudo:account): ; user=vdanjean > Nov 21 22:11:49 aya sudo: vdanjean : pam_acct_mgmt: 7 ; TTY=pts/7 ; > PWD=/home/vdanjean ; USER=root ; COMMAND=/bin/su > Nov 21 22:11:49 aya sudo: vdanjean : 3 incorrect password attempts ; > TTY=pts/7 ; PWD=/home/vdanjean ; USER=root ; COMMAND=/bin/su
It seems that the PAM stack does not retry the pam_ldap authentication (sudo:auth) check and only does authorisation (sudo:account) checks. > And, "nslcd -d" output: [...] This again only shows authentication (nslcd_pam_authc) requests for the first entered password and authorisation (nslcd_pam_authz) check later on. > My remark was due to the fact that /var/log/auth.log talk about > sudo:auth after the first password and sudo:account after the second > and third one. But this is probably due to the fact that the first > password is wrong whereas the second and third are correct. [and > indeed, this is the case: I tried with a wrong password the three > times and /var/log/auth.log talks about sudo:auth three times] This gave me an idea. What probably happens is that pam_unix is doing the authentication in the second and third tries (always as it succeeds). You probably expose password hashes through the shadow map (getent shadow as root shows password hashes for LDAP users). Like I described earlier, the authentication phase retrieves some authorisation information from the LDAP server. That saved authorisation information is used when doing authorisation. Since only pam_ldap's authentication check is done for incorrect passwords, this ensures that the cached authorisation value is always an error. There is not an easy solution for this within nss-pam-ldapd since it has no way of knowing whether the cached authorisation error is from a new attempt or not. The nslcd daemon could return an authorisation success alongside the authentication failure but that could also have other consequences. The easiest workaround is to not expose password hashes through NSS. From your logs your LDAP server returns the hashes even without authentication. Your LDAP server should have an ACL like this: access to attrs=userPassword by anonymous auth by self write by * none Failing that you can put this in nslcd.conf to avoid exposing password hashes through nslcd: map passwd userPassword "x" map shadow userPassword "*" (I'm thinking about making this the default in later releases of nss-pam-ldapd) Hope this is a usable workaround for you. -- -- arthur - [email protected] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
