LDAP supports three different types of classes, called abstract, structural, and auxiliary. Each one has a different use.
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.
Choosing Attribute Syntaxes
Part I: Fundamentals
Introduction to LDAP and Active Directory
Introduction to .NET Directory Services Programming
Binding and CRUD Operations with DirectoryEntry
Searching with the DirectorySearcher
Advanced LDAP Searches
Reading and Writing LDAP Attributes
Active Directory and ADAM Schema
Security in Directory Services Programming
Introduction to the ActiveDirectory Namespace
Part II: Practical Applications
Part III: Appendixes
Appendix A. Three Approaches to COM Interop with ADSI
Appendix B. LDAP Tools for Programmers
Appendix C. Troubleshooting and Help