Each instance of an object class has a multi-valued objectClass property that identifies the class of which the object is an instance, as well as all structural or abstract superclasses from which that class is derived. Thus, the objectClass property of a user object would identify the top, person, organizationalPerson, and user classes. The objectClass property does not include auxiliary classes in the list. The system sets the objectClass value when the object instance is created and it cannot be changed.
Each instance of an object class also has an objectCategory property, which is a single-valued property that contains the distinguished name of either the class of which the object is an instance or one of its superclasses. When an object is created, the system sets its objectCategory property to the value specified by the defaultObjectCategory property of its object class. An object's objectCategory property cannot be changed.
For most classes, the defaultObjectCategory is the distinguished name of the class's classSchema object. For example, the defaultObjectCategory for the organizationalUnit class is "CN=Organizational-Unit,CN=Schema,CN=Configuration,<DC=forestroot>". However, some classes refer to another class as their defaultObjectCategory. This allows a query to readily find groups of related objects, even if they are of differing classes. For example, the user, person, organizationalPerson, and contact classes all identify the person class in their defaultObjectCategory properties. This allows search filters like (objectCategory=person) to locate instances of all these classes with a single query. Queries for people are very common, so this is a simple optimization.
If you create a subclass from a structural class, the best practice is to set the defaultObjectCategory value of the new class to the same distinguished name of the superclass. This allows the standard UI to "find" the subclass.