Date: Thu, 6 Oct 2005 18:39:18 -0400 (EDT) From: "Brian A. Seklecki" <lavalamp@spiritual-machines.org> To: ldap@listserver.gpcc.itd.umich.edu, freebsd-questions@freebsd.org, jason@lixfeld.ca, Joerg Pulz <Joerg.Pulz@frm2.tum.de>, jesk@killall.org Subject: Re: LDAP + PAM + pam_groupdn / pam_member_attribute (revisited) Message-ID: <20051006180949.P95280@arbitor.digitalfreaks.org> In-Reply-To: <20051006171215.S95280@arbitor.digitalfreaks.org> References: <20051006164231.R95280@arbitor.digitalfreaks.org> <20051006171215.S95280@arbitor.digitalfreaks.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? But... "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 "posixGroup". 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 [snip] $ 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. ~BAS 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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "freebsd-questions-unsubscribe@freebsd.org" >> > > l8* > -lava > > x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 > l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051006180949.P95280>