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