Object Classes

Every object in the directory is a member of at least one object class. Object classes are used to indicate what sort of real-world object the entry represents - person, role, room etc. There is a hierachy of object classes, and many of the commonly-used classes inherit characteristics from simpler classes.

There are three types of object class: abstract, structural and auxiliary. This division was introduced in X.500(1993) and it applies to all but the very oldest versions of LDAP.

Abstract Classes

There are only two of these: top and alias.

Every normal directory entry is a member of top which simply requires that the entry must contain an objectClass attribute - a rather circular definition!

Alias entries are the directory equivalent of Unix symbolic links. They often confuse management tools, and the usual advice is to avoid using them.

Structural Classes

Every normal directory entry is a member of exactly one structural object class. By inheritance this also makes it a member of all superior classes, so an entry in the inetOrgPerson class is also a member of organizationalPerson and person and top.

Once an entry has been created, its structural object class may not be changed (though some servers allow this rule to be relaxed on request if the server administrator chooses to permit that action).

Auxiliary Classes

These can be added to or removed from entries at any time, as long as the resulting entry has values for the correct set of attributes at the end of the modify operation.

Best Practices for Object Classes

• Never change the definition of a standard object class - some future application might assume that it knows what to expect in objects of that class.
• Avoid subclassing the standard structural object classes - it is better to define your own abstract classes.
• When defining an abstract class do not list top as the superior (SUP) class. Abstract classes do not need superior classes at all, and top will be referenced anyway as part of the structural inheritance chain of any normal directory entry.
• If inheriting from a superior class, make sure that abstract classes only inherit from other abstract classes. Structural classes may inherit from other structural classes, or directly from top.
• Avoid listing attributes as mandatory (MUST). It is much easier to manage entries when attributes are optional (MAY).
• If you need to reduce the set of attributes permitted in an entry then consider using a DIT Content Rule with a standard structural class rather than defining a new structural class of your own.

-- AndrewFindlay - 12 Jun 2012