On Thu, Jan 10, 2013 at 10:51:41AM +0000, Philip Colmer wrote:
What I want to do is use the LDAP store for two purposes: Linux authentication and syncing with Google Apps for profile/group information and SSO. To that end, and specifically focussing on groups, I need a group in LDAP to serve two purposes: to act as a security group (i.e. it needs a gidNumber and be a posixGroup so that Linux will use it for group membership and ACLs) and to act as an email group (at a minimum have a list of members, an owner, a description and an email address).
In my approach to the choice of classes to use here, I find myself being somewhat constrained by the tools I want to use. Atlassian Crowd is being used as the means of providing Google SSO and OpenID functionality. When it comes to groups, Crowd "prefers" groupOfNames or groupOfUniqueNames. Although I can reconfigure Crowd to "see" posixGroup entries instead of groupOfUniqueNames entries, it doesn't see the members, presumably because they are UIDs and not DNs.
I'm also using LDAP Account Manager as the primary tool to allow administrators and staff manage information stored in LDAP. For group management, it supports both posixGroup and groupOfUniqueNames.
Can you persuade that tool to work with other classes?
I can, in theory at least, add extensibleObject to the groups defined as posixGroup so that I can then add description, displayName, mail and owner. That gives me a different problem when it comes to syncing the groups up to Google, though, because it also (like Crowd) seems to be expecting attribute values for members to be DNs.
I think you would do best to use RFC2307bis if all of your tools can work with it. Any recent Linux distro should have NSS and PAM libraries that accept DN-style group membership, so I would use 'member' rather than the 'memberUID' attribute for groups. You may need to adjust some settings in /etc/ldap.conf or similar.
2307bis prefers the use of groupOfMembers as the structural class. This is better than groupOfNames or groupOfUniqueNames because it permits empty groups.
In 2307bis, posixGroup is AUXILIARY [amusing, given my earlier comments on changing standard stuff :-)]. So you could have group entries that are both groupOfMembers and posixGroup. If your tools really cannot cope with groupOfMembers then you could consider groupOfNames with posixGroup, but you will then have to put a bogus member in each group to satisfy the definition of groupOfNames.
I would avoid using extensibleObject as that removes all the limits on what may be in an entry.
If you still need to add a mail address to your groups, you will also need to define an auxiliary class of your own to permit it.
Andrew