How are nested groups in LDAP normally implemented?

Chris Adams picture Chris Adams · Jan 5, 2011 · Viewed 28.7k times · Source

I'm coming to LDAP as a possible tool for managing access servers and source code at work, and while I've been able to grasp the basic concepts, like representing users and machines as entities, that create attributes, and defining which attributes should apply to an entity based on the objectClasses applied to them, there are a few errors that still make no sense to me, and I'm hoping someone can help explain how they work.

How do nested groups work?

I can understand what ou(organisational unit)'s are, and I can understand putting people inside them, and using the groupOfNames class to act as a container for members, like this LDIF snippet from zytrax:

    # create FIRST Level groups branch

    dn: ou=groups,dc=example,dc=com
    objectclass:organizationalunit
    ou: groups
    description: generic groups branch

    # create the itpeople entry under groups

    dn: cn=itpeople,ou=groups,dc=example,dc=com
    objectclass: groupofnames
    cn: itpeople
    description: IT security group
    member: cn=William Smith,ou=people,dc=example,dc=com

    # create the hrpeople entry under groups

    dn: cn=hrpeople,ou=groups,dc=example,dc=com
    objectclass: groupofnames
    cn: hrpeople
    description: Human Resources group
    member: cn=Robert Smith,ou=people,dc=example,dc=com

How would I add further levels of nesting though?

What I'm after is something like this pseudocode here:

ou='Projects' /
description: This top level group has a few people in it that can create new groups, and control who's in them
member: cn=Robert Smith,ou=people,dc=example,dc=com

    -- somethingsomethingAbitrarilyNestedGroup='project-name'
        member: cn=Robert Smith,ou=people,dc=example,dc=com

        -- groupOfNames = 'project-name development'
            member: cn=Robert Smith,ou=people,dc=example,dc=com
            member: cn=Jane Doe,ou=people,dc=example,dc=com
            member: cn=server1$,ou=servers,dc=example,dc=com

        -- groupOfNames = 'project-name staging'
            member: cn=Jane Doe,ou=people,dc=example,dc=com
            member: cn=server2$,ou=servers,dc=example,dc=com

Given this hierarchy,what's the best way to grant access to this group now?

I don't see a simple way to do the arbitrary group nesting here - among the normal classes available, without using an expensive closed source tool, yet it feels like it shouldn't be this complex.

How is this normally done using a tool like OpenLDAP, to let other ldap clients control group membership once they're authenticated as a user with the correct rights? ?

Answer

superdupersheep picture superdupersheep · Feb 27, 2011

Your question is a bit confused - I'm not sure what you mean "what's the best way to grant access to this group now" in the context of the initial few paragraphs.

Nested groups are dead simple. If you're using the groupOfNames objectClass, just add another member attribute to your parent group, with the value being the DN of the child group.

From your pseudo-code:

# Assuming your "groups" OU already exists...
# First create the child groups

dn: cn=project-name development,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: project-name development
member: cn=Robert Smith,ou=people,dc=example,dc=com
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server1$,ou=servers,dc=example,dc=com

dn: cn=project-name staging,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: project-name development
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server2$,ou=servers,dc=example,dc=com

# Now create the parent group
dn: 'project-name,ou=groups,dc=example,dc=com'
objectclass: groupofnames
member: cn=Robert Smith,ou=people,dc=example,dc=com
member: cn=project-name staging,ou=groups,dc=example,dc=com
member: cn=project-name development,ou=groups,dc=example,dc=com

Hiearchy within OUs is really only to separate your LDAP tree into "logical" segments based on the structure of your organisation. So, for example, you could stick all your groups for managing the "Development Department" in their own OU, so it's nice and clear what they pertain to. Objects can reference each other, and nest quite happily, by referencing each other with appropriate attributes (in this case, member).