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.
Prior to Windows Server 2008, the objectClass attribute is not indexed. This is because it has multiple values and is highly non-unique; that is, every instance of the objectClass attribute includes the top class. This means an index would be very large and ineffective. To locate objects of a given class, use the objectCategory attribute, which is single-valued and indexed. For more information about using these properties in search filters.
Both the objectCategory and objectClass attributes can refer to a given schema class of a directory object. However, there is an important distinction in semantics between the two. "objectClass=joy" refers to such directory objects in which "joy" represents any class in the object class hierarchy. "objectCategory=joy", on the other hand, refers to those directory objects in which "joy" identifies a specific class in the object class hierarchy.
objectClass can take multiple values whereas objectCategory takes a single value. Because of this, objectCategory is better suited for type matching of objects in a directory search. ADSI uses this as the default matching criterion. Searches using one objectClass are not scalable to large databases. ADSI supports "(objectCategory=SomeDN)" and "(objectCategory=Ldap_Display_Name_of_Class)" syntaxes.
The exception to all of this is that the LDAP search filter "(objectClass=*)" does not specify a search on object class, but merely tests for the presence of the objects.
© 2020 Digcode.com. All rights reserved.