Active Directory Schema
Active Directory Schema |
|
The X.500 1993 specification requires that object classes be assigned to one of four categories:
Different categories of classes allow for defining structure in the directory. The four categories of classes are applied as follows:
Structural Classes Structural classes are the only classes that can have instances in the directory. That is, you can create directory objects whose class is one of the Structural classes. A Structural class can be used in defining the structure of the directory and is derived from either an Abstract class or another Structural class. A Structural class can include any number of Auxiliary classes in its definition. This type of class is specified by a value of 1 in the objectClassCategory attribute.
Abstract Classes Abstract classes are templates that are used only to derive new Structural classes. Abstract classes cannot be instantiated in the directory. This means that no object can belong only to an Abstract class; each object of an Abstract class also belongs to some nonabstract subclass of that class. A new Abstract class can be derived from an existing Abstract class. This type of class is specified by a value of 2 in the objectClassCategory attribute. Classes of the abstract category have the sole function of providing attributes for subordinate classes, called subclasses. A subclass contains all mandatory and optional attributes of the class from which it is derived, called its superclass, in addition to those specific to the class itself. Likewise, the subclass of that class contains all attributes of both superclasses, and so forth.
Auxiliary Classes Auxiliary classes are like "include" files; they contain a list of attributes. Adding the Auxiliary class to the definition of a Structural or Abstract class adds the Auxiliary class's attributes to the definition. An Auxiliary class cannot be instantiated in the directory, but new Auxiliary classes can be derived from existing Auxiliary classes. This type of class is specified by a value of 3 in the objectClassCategory attribute. For example, the securityPrincipal class is an Auxiliary class, and it derives its attributes from the parent abstract class called top. Although you cannot create a security principal object in the directory (because Auxiliary classes cannot have instances), you can create an object of the Structural class user, which has the securityPrincipal class as an auxiliary. The attributes of the securityPrincipal class contribute to making the user object recognizable to the system as a security account. Similarly, the group class has securityPrincipal as an Auxiliary class.
88 Classes Classes defined before 1993 are not required to fall into one of the preceding categories; assigning classes to categories was not required in the X.500 1988 specification. Classes that were defined prior to the X.500 1993 standards, default to the 88 class. This type of class is specified by a value of 0 in the objectClassCategory attribute. Do not define new 88 classes.
Note
Active Directory does not return an error for 88 classes; it only performs looser semantic checking. For example, an 88 class can be used as an abstract superclass, but it can also be directly instantiated. When you define new schema classes, you need to use one of the X.500 1993 categories.
Inheritance, which is also referred to as derivation, is the ability to build new object classes from existing object classes. The new object is defined as a subclass of the parent object. A subclass is a class that inherits from some other class; for example, a subclass inherits structure and content rules from the parent. The parent object becomes a superclass of the new object. A superclass is a class from which one or more other classes inherit information. The inherited information includes mandatory and optional attributes (systemMustContain, mustContain, systemMayContain, and mayContain) and its parent classes in the directory hierarchy (systemPossSuperiors and possSuperiors). The diagram in Figure 4.2 illustrates an object class hierarchy.
Figure 4.2 Object Class Hierarchy
For example, you can specify a Salesperson class that defines information about the salespeople in your company, including specialized information, such as commission rate and travel route. You can specify the Salesperson class as subClassOf of the User class. This would cause the Salesperson class to inherit all the mandatory and optional attributes and directory-parent classes of the User class after the schema cache is updated. You would not have to define these attributes for each salesperson in your company.
All structural object classes are subclasses, directly or indirectly, of a single abstract object class, which is called top. Every object represented in the directory belongs to top and, as a result, every entry must have an objectClass attribute. When you create a new class, you must specify the superclass: If you are not creating a subclass of an existing class, the new class is a subclass of top.
A new class can inherit mandatory and optional attributes from more than one existing class. However, any additional classes must be specified by the auxiliaryClass attribute.
Note
If you add another attribute later to a class that has subclasses or auxiliary subclasses, the new attribute is automatically added to the subclasses after the schema cache has been updated.
To view a graphical representation of the Active Directory class hierarchy, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
Some aspects of a class-definition object are contained in pairs of attributes, where the value of one of these attributes can be changed by administrators and the other cannot. These attribute pairs are mustContain/systemMustContain, mayContain/systemMayContain, possSuperiors/systemPossSuperiors, and auxiliaryClass/systemAuxiliaryClass.
In each of these pairs, the value of the attribute that begins with the word system cannot be changed by administrators. This enables Active Directory to protect certain key attributes of certain classes and ensure that the schema stays consistent and usable. System-only properties can only be changed by the directory system agent (DSA). System-only properties are those properties on which Windows 2000 and Active Directory depend for normal operations. For example, the attributeID and governsID attributes in the schema are system-only attributes. The value of the other (nonsystem) attributes in each pair can be changed by administrators.
The term mandatory attributes refers to object attributes for which values must be specified. If you do not specify a value for a mandatory attribute, one of the following happens:
Which of the object's attributes are mandatory is determined by the class to which the object belongs.
Some mandatory attributes are inherited. Because every schemaClass object belongs to a subclass called top in the class hierarchy, each schemaClass object inherits the mandatory attributes that belong to top. Table 4.2 is a list of the mandatory attributes that every object inherits from top. To see a graphical representation of the Active Directory class hierarchy, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
Table 4.2 Mandatory Attributes That All schemaClass Objects Inherit
| Inherited Mandatory Attribute | Default Status |
|---|---|
| nTSecurityDescriptor | Defaults if not specified. The default value depends on the default security descriptor for the classSchema class. |
| objectCategory | Defaults to the value of the default object category of the class (which is usually the class itself). Can be changed after the class is created. |
| objectClass | No default. Administrator must specify the class. |
Note
You can view an object's mandatory attributes by using the Active Directory Schema
Table 4.3 is a list of the attributes a classSchema object can have.
Table 4.3 Attributes of a classSchema Object
Attribute |
Syntax |
Mandatory? |
Multi- value? |
Description |
|---|---|---|---|---|
| cn | Unicode | Yes | No | Descriptive relative distinguished name for the schema object. |
| governsID | Object identifier | Yes | No | Object identifier that uniquely identifies this class. |
| lDAPDisplayName | Unicode | Yes | No | Name by which LDAP clients identify this class. |
| schemaIDGUID | String(Octet) | Yes, but defaulted. | No | GUID that uniquely identifies this class. |
| rDNAttID | Object identifier | No | No | Relative-distinguished-name-type of instances of this class (OU, CN). |
| subClassOf | Object identifier | Yes | No1 | The class from which this object inherits attributes. |
| systemMustContain | Object identifier | No | Yes | The list of mandatory attributes for instances of this class. This list cannot be changed. |
| MustContain2 | Object identifier | No | Yes | The mandatory attributes for instances of this class. |
| systemMayContain | Object identifier | No | Yes | The optional attributes for instances of this class. |
| mayContain2 | Object identifier | No | Yes | The optional attributes for instances of this class. |
| systemPossSuperiors2 | Object identifier | No | Yes | The classes that can be parents of this class in the directory hierarchy. After creation of the class, this property cannot be changed. |
| possSuperiors2 | Object identifier | No | Yes | The classes that can be parents of this class in the directory hierarchy.
For an existing classSchema object, values can be added to this property but not removed. |
| systemAuxiliaryClass2 | Object identifier | No | Yes | The Auxiliary classes from which this class inherits its optional (mayContain) and mandatory (mustContain) attributes. After creation of the class, this property cannot be changed. |
| auxiliaryClass2 | Object identifier | No | Yes | The Auxiliary classes from which this class inherits its optional (mayContain) and mandatory (mustContain) attributes. A multivalue property that specifies the auxiliary classes that this class inherits from. For an existing classSchema object, values can be added to this property but not removed. |
| defaultHidingValue | BOOL | No | No | The default hiding state for the class. If you do not want instances of your class displayed in the user interface, you can define the class as hidden. |
| DefaultSecurity Descriptor |
String(Octet) | No | No | The default security descriptor that is assigned to new instances of this class if no security descriptor is specified during creation of the class or is merged into a security descriptor if one is specified. |
| objectClassCategory | Integer | Yes | No | Class types are defined as follows:
88 Class = 0; Structural = 1; Abstract = 2; |
| systemOnly | BOOL | No | No | If TRUE, only the system can create and modify instances of this class. |
| objectClass | Object Identifier | Yes | Yes | This object's class, which is always classSchema. |
| nTSecurityDescriptor | NT-Sec-Desc | Yes | No | Security descriptor on the classSchema object. |
| defaultObjectCategory | Distinguished name | Yes | No | The default object category of new instances of this class if none has been specified. |
| 1 Objects cannot inherit from more than one class by using this attribute. Use the auxiliaryClass attribute to define additional parent classes.
2 Each value is the lDAPDisplayName of a class that is a class object identifier. Note that you must ensure that the classes exist or will exist when the new class is written to the directory. If one of the classes does not exist, the classSchema object is not added to the directory. |
||||
Note
When you look at the attributes in a classSchema object's mustContain attribute list, you are not seeing the complete set of attributes that must be present for an instance of a class to exist. For example, in the class A, the classSchema object B specifies a list of mustContain attributes that an instance of A must have through the systemMustContain and mustContain attributes. However, because mandatory attributes are also inherited, the complete list of attributes for an instance of class A includes the inherited mustContain attributes from all classes from which B inherits — that is, all classes in the subClassOf and auxiliaryClass lists for the classSchema object B. The mayContain attributes for object B are also defined this way. The possSuperiors are defined this way as well, except that possSuperiors are inherited only from classes in the subClassOf list, not from the classes in the auxiliaryClass list.
