Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on the design of LDAP structure, that basically should hold users and groups. There should be support for nested groups (so I thought on using groupOfNames object class) and for the users I will use inetOrgPerson. There's one extra condition though - there's groups that currently will have no members.

Thus my research shows, that I may consider using groupOfEntries as object class in my openLDAP instance. It's the same as groupOfNames except that the member attribute is optional (was MUST). I cannot find any official documentation that states how to deal with optional membership using the standard LDAP object classes.

I found the draft paper for groupOfEntries to IETF from 2008, but I was not able to gather any more information.

Is there an official decision if we should use this object class?

Is it present in any optional schema that could be imported into openLDAP?

My consideration is mostly "how well supported", "how secure" and "how official" is considered to use this object class? I would like to hear some opinions on the matter, also any alternatives suggested will be appreciated. Thanks for your time!

share|improve this question
up vote 1 down vote accepted

The Findlay draft was created in order to provide a grouping mechanism wherein the member attribute is MAY (not MUST) as you have discovered. Some servers have the schema, others do not. The schema is contained in the draft. I do not think has been activity since the draft, however.

Some directory server products are shipped with support for groupofEntries but not all. The UnboundID Directory Server and probably OpenDS have support for groupofEntries in the form of a schema, but there is nothing to prevent an administrator from providing the appropriate schema elements.

As to whether it's a good idea: if you need it and your LDAP clients require it and cannot be re-coded to support an RFC (as opposed to a dormant draft), or if the data model requires it, then the administrator should support it. Clients, servers, and data modelers should adhere to standards, but where it's felt that the standard is deficient, an alternative might become popular.

share|improve this answer

Have a look at organizationalRole and groupOfUniqueNames.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.