I was just wondering, for an LDAP structure, would it be possible for a group to have an organizational unit as a member? Or am I pretty much guaranteed that anything under a group object will either be a user or another group?
Also are the following guaranteed?
1) The parent of a user is either a group or organizational unit
2) The parent of a group is either a group or organizational unit
3) The parent of an organizational unit is a organizational unit or the root
Thanks, I'm still pretty new to LDAP.
Using the groupOfUniqueNames objectClass, the optional multi-valued attribute uniqueMember may be any valid distinguished name, including a distinguished name where the any or all of the RDN components are ou or organizationalUnit.
note that some implementations of groupOfUniqueNames require uniqueMember, and others do not.
organizationalUnit is an object class that does not allow uniqueMember. groupOfUniqueNames allows (or in some cases requires) uniqueMember. There would be no point in having a groupOfUniqueNames without uniqueMember entries. To summarize: 1) uniqueMember is allowed in entries that have the groupOfUniqueNames objectClass 2) uniqueMember must have a value of distinguishedName, therefore, if ou is an RDN in a distinguished name, it can be used as a value for uniqueMember - Terry Gardner 2012-04-11 14:35
No, an OU cannot be member of an LDAP group
(at least not in Windows Active Directory, which is the LDAP implementation I know and I'm talking about here)
Organizational units are containers that can contain other objects - security principals like user and computer accounts as well as groups.
Containers also cannot have any permissions assigned to them - they're not security principals, you cannot grant an OU rights on a file or directory or anything like that.
Groups can contain security principals as their members - other groups, users, or computers - but not containers. It wouldn't make sense to include containers, anyway - since those aren't "security principals", e.g. they cannot have any permissions assigned to them, so adding them to a group doesn't make any logical sense, either.
This is quite different from other directory systems - like Novell's NDS / eDirectory - where organization and OU's do have permissions (although I can't recall whether you could add those objects to group's membership list)
Also, you need to keep apart containment (a group or user is always contained in exactly one container) and group membership (a user can be member of many groups, but he's not contained by those groups - just member of them) - which are two totally different concepts.