Defining Objects: classSchema Objects
Schema NC classSchema objects contain class definitions. These definitions specify the following information:
- the rules that define where you can create an AD object (e.g., in an organizational unit—OU)
- the relationships, or class derivations, between classSchema objects (e.g., the class's parent class, called a superclass)
- the relationships between attributes and classSchema objects (e.g., the class's mandatory and optional attributes)
Table 1, page 53, shows mandatory and optional attributes that AD typically uses to create a classSchema object. (For a complete list of available attributes, visit the Microsoft Developer Network—MSDN—at http://msdn.microsoft.com/library/psdk/adsi/glschema3_88fn.htm.) Each classSchema object falls into one of three class categories: abstract, auxiliary, and structural.
Abstract class. classSchema objects (i.e., classes) that belong to the abstract category serve as placeholders; you can't use these classes to create an object instance in another AD NC. AD uses abstract classes primarily as parent classes, or superclasses, for other classes so that you can create a hierarchical structure of object classes and define a system of attribute inheritance between classes. (A class's subClassOf attribute names its superclass.) Inheritance isn't dedicated to the abstract classes, but it's their primary purpose. Abstract classSchema objects have an objectClassCategory attribute value of 2.
Auxiliary class. Auxiliary classSchema objects are similar to abstract classes in the sense that you don't use these classes to create AD object instances. Auxiliary classes are similar to include or header files: You can use this category of classes to include a set of multiple attributes in another class's definition. (The systemAuxiliaryClass and auxiliaryClass attributes are multivalue attributes; in other words, many auxiliary classes can exist for one classSchema object. A single-value attribute can contain only one value; a multivalue attribute can contain multiple values.)
When you install Exchange 2000 in an AD forest, the Exchange 2000 Setup adds many classes to the AD schema. Some of these classes belong to the auxiliary category and define attributes that are specific to Exchange 2000. A classSchema object's systemAuxiliaryClass or auxiliaryClass attributes define any applicable auxiliary class objects. Auxiliary classes have an objectClassCategory attribute value of 3.
Structural class. The structural class is the only class type you can use to create object instances in other AD NCs. Structural classSchema objects use the systemPossSuperiors and possSuperiors attributes to define the classes under which a created instance of the class can reside. (For example, the user class's systemPossSuperiors attribute defines the organizationalUnit class as a possible container for instances of the user class, so you can create a User object in an instance of the organizationalUnit class.) These definitions are known as instantiation rules. A structural classSchema object's objectClassCategory attribute value is 1.
Figure 4 shows how the three class types work together. Top is an abstract classSchema object that serves as the superclass of the abstract classSchema object Person. Person, in turn, serves as the superclass of the abstract classSchema object organizationalPerson. That object serves as the superclass of the user class (i.e., the classSchema object user). The classSchema object user is a structural class object that defines User objects (i.e., instances of the user class).
As Figure 4 shows, the user class inherits attributes from its superclasses and from various auxiliary classes. All objects have a set of mandatory attributes and a set of optional attributes. A classSchema object's systemMustContain and mustContain attributes define these mandatory attributes; a classSchema object's systemMayContain and mayContain attributes define the object's optional attributes. ADSI Edit shows no defined value for the user class's systemMustContain and mustContain attributes. This fact doesn't mean the user class has no mandatory attributes. Rather, the user class inherits the mandatory attributes of its superclasses (e.g., Person) and auxiliary classes (e.g., mailRecipient).
Defining Attributes: attributeSchema Objects
Schema NC attributeSchema objects define the attributes available in AD. As with classSchema objects, each attribute-Schema object has a set of attributes that defines its characteristics. Table 2 describes the mandatory and optional attributes that AD typically uses to create an attributeSchema object. (For a complete list, visit the MSDN site at http://msdn.microsoft.com/library/psdk/adsi/glschema3_92yb.htm.)
Every attribute in the AD schema has a predefined syntax that specifies the type of information the attribute can store. (For example, attributes store telephone numbers differently from binary values or strings.) An attributeSchema object's attributeSyntax attribute uses an Object Identifier (OID) to specify the syntax, and the object's oMSyntax attribute uses the X/Open Object Model designation to specify the syntax. The object's oMObjectClass attribute also specifies the syntax, albeit in a different form, whenever the oMSyntax attribute uses a value of 127. (This value indicates that the syntax references an object data type.) In these cases, you must ensure that the object's oMObjectClass attribute displays the correct value for the chosen syntax, as Table 3, page 58, shows. Table 3 lists the available syntaxes and their corresponding OID, oMSyntax attribute, and oMObjectClass attribute values. As of this writing, you can't add new attribute syntaxes to AD.
Register
