On Fri, May 30, 2008 at 10:41:09AM +0300, Bogdan Cehan wrote: > Ok > so now my configuration looks like this > > # Server1, Groups, pol.mediaimage.ro > dn: cn=Server1,ou=Groups,dc=pol,dc=ro > objectClass: top > objectClass: posixgroup > cn: Server1 > gidNumber: 100 > memberUid: alex > memberUid: vion > > and ldap.conf : > [snip] > pam_member_attribute memberUid > pam_groupdn cn=Server1,ou=Groups,dc=pol,dc=ro That's probably not going to work -- pam_ldap is still going to check for the DN of the user's entry in the memberUid attribute, and not the user's name. [snip] > and pam system-auth : [snip] > account sufficient pam_unix.so > account required pam_access.so > account sufficient pam_ldap.so I suspect pam_unix is checking for an expired password (and if you're using nss_ldap, it'll be able to "see" users you've defined in the directory), determining that the user's password has not expired, and returning success. There's also the subtle problem that if a "sufficient" module fails, it doesn't actually cause the whole PAM stack to be counted as a failure, so even if both pam_unix.so and pam_ldap.so failed, the user might still be allowed access. I'd suggest something like this instead: account required pam_unix.so account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_access.so I haven't tried it myself, but I think that'll work. HTH, Nalin
