Choosing an Object Class

LDAP supports three different types of classes, called abstract, structural, and auxiliary. Each one has a different use.

• Abstract classes, similar to the object-oriented design principle of the same name, contain a base set of attributes that other objects inherit. No instances of an abstract class can be created in the directory. Instead, they must be subclassed from other abstract, structural, or auxiliary classes. The top class is an example of this type of class. Abstract classes can contain auxiliary classes in their definition.
• Structural classes are the only type of class that can actually have an instance in the directory. All structural classes derive from at least one abstract class (the top abstract class must be defined as the root class for all classes), but they can also derive from another structural class. These classes can contain any number of auxiliary classes in their definition.
• Auxiliary classes contain a collection of attributes (usually of a set or similar categorization). These classes can be part of any type of class, but they must be derived from either another auxiliary class or an abstract class. Auxiliary classes can contain any number of other auxiliary classes as well. We typically use these classes to apply similar characteristics orthogonally to otherwise dissimilar classes. For instance, we would apply the Security-Principal auxiliary class to all classes that can represent security principals in Active Directory (users, computers, groups, etc.). Using our object-oriented design analogy again, auxiliary classes are a bit like interface definitions.

Most developers will typically be adding only a few attributes to existing classes. As such, they do not necessarily deal with creating a new class in the directory. However, when extending the schema to accommodate an application or a set of services, it is not a bad idea to group the attributes to be added into one or more auxiliary classes. This way, we can just add the auxiliary class to any type of object should we need to later, and all of our attributes will simply appear as part of the object. It will also serve as a logical grouping and as a single security grouping for the attributes. We can apply the security only to the auxiliary class and have it apply through inheritance to the attributes it contains.

If we are creating a new class where an actual instance will be created in the directory, it is important to give the objectCategory attribute some thought as well. In Windows 2000, the objectClass was not indexed, though it is indexed today in Windows 2003. This multivalued class holds the complete hierarchy of classes from which our class is derived (not including auxiliary classes). We never actually set this attribute, as it is created automatically when an instance is created and it cannot be changed. The objectCategory attribute, however, is a single-valued attribute that is indexed by default in all versions of Active Directory and ADAM. Its value is set to whatever is specified for the defaultObjectCategory on the structural class when an instance is created. It is meant to categorize object types across different structural classes and is often used for searching. For instance, the contact, user, organizationalPerson, and person classes share the same objectCategory attribute of person. This allows us to find information about a user across all types of objects that might represent them easily, using the objectCategory attribute in the search filter.

If we are to create our own structural class, it is best to set its defaultObjectCategory value to a common superclass if it is derived. Otherwise, the defaultObjectCategory value should be set to the class itself. For example, if we were to create our own type of user called specialUser, derived from the user class, we should probably set the defaultObjectCategory value to be the person class in order to have our object returned as part of typical (objectCategory=person) types of searches.