Re: LDAP + PAM + pam_groupdn / pam_member_attribute (revisited)
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 authrequiredpam_nologin.so no_warn authsufficient pam_opie.so no_warn no_fake_prompts authrequisite 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 authsufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass authrequiredpam_unix.so no_warn try_first_pass # account #accountrequiredpam_krb5.so account requiredpam_login_access.so account required/usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user account requiredpam_unix.so # session #sessionoptionalpam_ssh.so session requiredpam_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 passwordrequiredpam_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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ldap] Re: LDAP + PAM + pam_groupdn / pam_member_attribute (revisited)
right! ...from pam_ldap(5): PAM CONFIGURATION It is possible to configure some aspects of pam_ldap on a per-service basis, in the PAM configuration file (this is usually /etc/pam.conf; for PAM implementations based on Linux-PAM, per-service files in /etc/pam.d are also supported). [..] debug: This option is recognized by pam_ldap but is presently ignored. ~bas AA [A On Thu, 6 Oct 2005, Jeff Saxton wrote: you can run pam modules in debug mode: The last option listed in a PAM configuration line supplies any additional arguments that should be passwd toe the module upon invocation. idebug/i Enables generation of debugtging information either to standard output or via the syslogd daemon Good luck 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 authrequiredpam_nologin.so no_warn authsufficient pam_opie.so no_warn no_fake_prompts authrequisite 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 authsufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass authrequiredpam_unix.so no_warn try_first_pass # account #accountrequiredpam_krb5.so account requiredpam_login_access.so account required/usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user account requiredpam_unix.so # session #sessionoptionalpam_ssh.so session requiredpam_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 passwordrequiredpam_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 --- You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message. -- Jeff Saxton SenSage, Inc. 55 Hawthorne Street Suite 700 San Francisco, CA 94105 Phone: 415.808.5900 Fax:415.371.1385 Direct: 415-808-5921 Cell: 415-640-6392 mailto:[EMAIL PROTECTED] Enterprise Security Analytics SenSage, the leading provider of enterprise security analytics, offers unparalleled performance and a scalable means for organizations to centrally aggregate, efficiently analyze, dynamically monitor and cost-effectively store massive volumes of event log data. l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
Re: LDAP + PAM + pam_groupdn / pam_member_attribute (revisited)
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 authrequiredpam_nologin.so no_warn authsufficient pam_opie.so no_warn no_fake_prompts authrequisite 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 authsufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass authrequiredpam_unix.so no_warn try_first_pass # account #accountrequiredpam_krb5.so account requiredpam_login_access.so account required/usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user account requiredpam_unix.so # session #sessionoptionalpam_ssh.so session requiredpam_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 passwordrequiredpam_unix.so no_warn try_first_pass #password required /usr/local/lib/pam_ldap.so no_warn
