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.
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
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
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? ?
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).