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."

Right? Right?


"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 
this purpose.

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.

For example:

memberDN: cn=Keyser Soze,ou=People,o=priv,dc=root,dc=com

but this won't work (RDN?):

memberDN: uid=ksoze,ou=People,o=priv,dc=root,dc=com


$ ldapsearch blah blah

# dev, posixGroups, priv, root, com
dn: cn=dev,ou=posixGroups,o=priv,dc=root,dc=com
cn: dev
objectClass: posixGroup
objectClass: top
gidNumber: 65532
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" 
"HostGroup Object".

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 
> no_fake_prompts
> auth            requisite       pam_opieaccess.so       no_warn allow_local
> #auth           sufficient      pam_krb5.so             no_warn 
> try_first_pass
> #auth           sufficient      pam_ssh.so              no_warn 
> try_first_pass
> auth            sufficient      /usr/local/lib/pam_ldap.so no_warn 
> try_first_pass
> auth            required        pam_unix.so             no_warn 
> try_first_pass
> # 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 
> try_first_pass
> # password
> #password       sufficient      pam_krb5.so             no_warn 
> try_first_pass
> password        required        pam_unix.so             no_warn 
> try_first_pass
> #password         required      /usr/local/lib/pam_ldap.so no_warn 
> try_first_pass
> ...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?
> ~BAS
> 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"
> l8*
> 	-lava
> 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 mailing list