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
"[EMAIL PROTECTED]"
l8*
-lava
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
l8*
-lava
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
