LDAP + PAM + pam_groupdn / pam_member_attribute (revisited)
Brian A. Seklecki
lavalamp at spiritual-machines.org
Thu Oct 6 15:39:19 PDT 2005
Ahhh. Cheeky bastards. You sit around and think "group" for 18 hours
with regard to POSIX Groups. Then it comes time to sit down and configure
"group membership" login restriction. But really, they are entirely
unrelated concepts. It even says in the man page:
"Specifies the distinguished name of a group to which a user must belong
for logon authorization to succeed."
"pam_groupdn" has absolutely nothing to do with whether the DN/RND of the
user trying to authenticate contains an attribute "uid=user1", which
matches a "memberUid" multi-value attribute in any object type
This is simply not what the code checks. That would make too much sense
to use the symantics of UNIX / POSIX to make this determination. I.e.,
"You're in that UNIX group, you can login."
Instead, it checks to see if the entire DN of authenticating user/DN is in
SOME/ANY multi-value attribute defined by "pam_member_attribute".
That explains why the authors of "LDAP System Administration" go to the
trouble of creating an entirely different "ou=Hosts" (which, once again,
is an entirely ambiguous name) for containing "host/group" objects (which
are really supposed to be used for DNS!) with "member:" attributes for
What's more, the values of your "pam_member_attribute", in this case
"memberUid", but really should be, "memberDN", must be the entire DN and
not an RDN.
memberDN: cn=Keyser Soze,ou=People,o=priv,dc=root,dc=com
but this won't work (RDN?):
$ ldapsearch blah blah
# dev, posixGroups, priv, root, com
memberUid: cn=Keyser Soze,ou=People,o=priv,dc=root,dc=com
memberUid: cn=Am Biguity,ou=People,o=priv,dc=root,dc=com
Of course, this isn't explained anywhere in the man page and has probably
lead to unfathomable ammounts of similar confusion previously. One would
naturally thing "Oh, excellent, POSIX groups as ACLs for restricting
access to groups of machines", but no >:}
A better name would be "Cluster ACL" or "Host ACL" or "ACL Group"
Another option would be some kind of ldap.conf(5) style regular expression
you could use to convert/match a POSIX ACL into a "pam_groupdn". That
would be nice and dirty and would keep par.
Good times, good times.
And now to go submit a send-pr(1) to the FreeBSD port maintainer with a
patch to pam_ldap.5, pray it gets commited back upstream, and then drink
myself blind in the left eye so I can never read another LDAP man page.
On Thu, 6 Oct 2005, Brian A. Seklecki wrote:
> 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, c2003."
> ....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 allow_local
> #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
>> 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
>> ~BAS >:}
>> freebsd-questions at freebsd.org mailing list
>> To unsubscribe, send any mail to
>> "freebsd-questions-unsubscribe at freebsd.org"
> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
More information about the freebsd-questions