LDAP/X.500 defines only group objects which have member attributes, the inverse relation where a user object has a memberof attribute in OpenLDAP can be achieved with the memberof
overlay. NDS/eDir and AD make this happen by magic. LDAP proper does not define dynamic bi-directional member/group objects/attributes. Related to that overlay is the refint overlay which helps complete the illusion (and also addresses the mildly irritating problem of a group always requiring at least one member).
There are generally two interesting group types to pick, groupOfNames
or groupOfUniqueNames
, the first one GroupOfNames
is suitable for most purposes. The latter, groupOfUniqueNames
, has a slightly esoteric feature: it allows the member DN to contain a numeric UID suffix, to preserve uniqueness of members across time should DNs be reassigned to different entities. Neither form enforces unique DNs in the list of members.
Other types of groups have distinct purposes (defined by schema and application). A less common group-type object is RFC 2256 roles (organizationalRole
type, with roleOccupant
attribute), this is implicitly used for role-based access control, but is otherwise similar to the other group types (thanks to EJP for the tip).
The posixGroup
type represents the conventional unix groups, identified by a gidNUmber
and listing memberUid'
s. It is not a general purpose group object in the DIT, it's up to the application (i.e. the LDAP client layer) to implement/observe it.
When it comes to user accounts, account object-types should not be thought of as exclusive, each type typically adds attributes to a user object in a compatible way (though an objectClass
can be exclusive if it's structural, that's not something you'll often have to worry about generally).
organizationalRole
. – Reni