On Wed, 2011-06-08 at 16:35 -0700, Steve Langasek wrote: > That's only an issue if LDAP provides a password entry with 'x' for the > password field (which denotes a shadow account), *and* does not provide > shadow information. That's a misconfigured nss_ldap, nothing more.
Thanks for pointing that out. It seems that current nss-pam-ldapd provides 'x' as a password when the shadowAccount objectclass is present. It should also probably check if shadow is configured in /etc/nsswitch.conf is present. > To me, that sounds like feature creep in pam_ldap. I don't see any reason > for pam_ldap to check account expiry when pam_unix was doing that already. It could be handy with certain PAM configurations. Sadly, there are a lot of ways to achieve basically the same thing with PAM. > Incorrect. pam_unix as an 'account' module will return PAM_NEW_AUTHTOK_REQD > when a password change is required. Then I think there is either a bug in the documentation or in pam_unix. The shadow(5) manual page says (on account expiration date): Note that an account expiration differs from a password expiration. In case of an acount expiration, the user shall not be allowed to login. In case of a password expiration, the user is not allowed to login using her password. I've just tested it with libpam-modules 1.1.3-1 and it seems that pam_unix tries to lock out the user on password expiration (not account expiration). This means that a user is not able to log in (for example using SSH key-based authentication) with an expired password. -- -- arthur - [email protected] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
