GroupOfUniqueNames vs groupOfNames


The discussion of GroupOfUniqueNames vs groupOfNames is more a discussion of Member vs uniqueMember as other than these two attributes they behave the same.

There are of course some differences between LDAP Server Implementations, but these two attributes are the primary differences.


groupOfNames stores its members in the Member attribute using FDN as the value.


groupOfUniqueNames stores its members in the uniqueMember attribute also using FDN as value.

uniqueMember attribute however is designed to be able to hold an extra unique identifier to tell the difference between two FDN's who have the same value in a group.

Multiple objects, at different times, can be named by the same FDN.

For instance, uid=adam,dc=example may at one time refer an object representing "Adam Smith" and at another time refer to an object representing "Adam Jones".

This new entry is added with the same FDN, but it is a different person. This person needs access to the group, but you need a way to differentiate between this recent addition and the earlier FDN.

If you have several thousand members, simply deleting the earlier DN may not be a reasonable option.

Example: If

 ou=1st Battalion,o=Defense,c=US 

is a battalion that was disbanded, establishing a new battalion with the "same" name would have a unique identifier value added, resulting in:

 ou=1st Battalion, o=Defense,c=US#'010101'B 


While we are speaking about Member and UniqueMember we should probably mention MemberUid which is used in PosixGroup.

In the original RFC2307Schema, the MemberUid was represented as a RDN value similar to "jwilleke" vs an FDN of cn=jwilleke,ou=People,dc=willeke,dc=com.

The SchemaRFC2307Bis is a modification of the RFC2307Schema where posixGroup is auxiliary and the SchemaRFC2307Bis, which requires that NSS_LDAP be capable to support the SchemaRFC2307Bis, which allows you to use groups of FDNs to represent posixGroups rather than groups of MemberUids (or RDN values).

In SchemaRFC2307Bis the requirement of NSS_LDAP is the NSS library also maintains a cache of DN->uid lookups (called the dn2uid cache) in a db file to speed things up. Since PAM & NSS LDAP was made by PADL.COM, they produced the SchemaRFC2307Bis file.

More Information#

There might be more information for this subject on one of the following: