LDAP + PAM + pam_groupdn / pam_member_attribute (revisited)

Brian A. Seklecki lavalamp at spiritual-machines.org
Thu Oct 6 14:24:06 PDT 2005

This should be so insanely easy.  I'm relatively certain this a 
FreeBSD PAM specific issue.  From "LDAP system administration [electronic 
resource] / Gerald Carter. 1st ed.  Beijing ; Sebastopol, CA : O'Reilly, 

....in ldap.conf and nss_ldap.conf


# Group to enforce membership of
pam_groupdn cn=groupName,ou=posixGroups,o=priv,dc=root,dc=com

# Group member attribute
pam_member_attribute memberUid


...and then in LDAP, have an object, *ANY* object will function as a 
"group", as long as it supports a multi-value attribute, in this case 
memberUid such as a posixGroup:

# groupName, posixGroups, priv, root, dn
dn: cn=groupName,ou=posixGroups,o=priv,dc=root,dc=com
cn: cfdev
objectClass: posixGroup
objectClass: top
gidNumber: 65532
memberUid: user1
memberUid: user2
memberUid: user3
memberUid: user4
memberUid: user5
memberUid: user6

...this result returned by the same search I'm asking PAM to do:

$ ldapsearch -D "cn=bofh,dc=root,dc=com" -b dc=root,dc=com -H 
ldap://ldapserver -Z -W "(objectClass=posixGroup)"

Then adjust for PAM in SSHD:

# auth
auth            required        pam_nologin.so          no_warn
auth            sufficient      pam_opie.so             no_warn 
auth            requisite       pam_opieaccess.so       no_warn 
#auth           sufficient      pam_krb5.so             no_warn 
#auth           sufficient      pam_ssh.so              no_warn 
auth            sufficient      /usr/local/lib/pam_ldap.so no_warn 
auth            required        pam_unix.so             no_warn 

# account
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        /usr/local/lib/pam_ldap.so 
ignore_authinfo_unavail ignore_unknown_user
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so
session         required        pam_permit.so
#session         sufficient      /usr/local/lib/pam_ldap.so no_warn 

# password
#password       sufficient      pam_krb5.so             no_warn 
password        required        pam_unix.so             no_warn 
#password         required      /usr/local/lib/pam_ldap.so no_warn 

...when I change "account ..pam_ldap.so" to sufficient, it allows users in 
who aren't in the required group (as it should if the check fails).  When 
I change it to required, it doesn't let them in, but there isn't a single 
useful debugging error message.

How could something so widely used as PAM make it into the wild without 
hooks for debugging?


On Thu, 6 Oct 2005, Brian A. Seklecki wrote:

> Did anyone every get this combination working?
> Is 'pam_member_attribute' supposed to be uniqueMember or memberUid?
> When you look at a postGroup entity, the multi-value attribute is memberUid!
> Is there *any* way at all get debugging information out of PAM libraries, or 
> is it just so insanely esoteric that it's not an option?
> My favorite thing about PADL's documentation by far is the lack of examples.
> ~BAS >:}
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"


x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8

More information about the freebsd-questions mailing list