Categories of Object Classes

The X.500 1993 specification requires that object classes be assigned to one of four categories:

• Structural

• Abstract

• Auxiliary

• 88

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

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 https:// windows.microsoft.com/windows2000/reskit/webresources .

System and Changeable Attribute Pairs

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.

Mandatory Attributes

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:

• The attribute takes on a default value.

• The object is not created until you specify a value for the attribute.

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 https:// 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 snap-in. (The attributes are displayed on the Attributes tab in the Properties dialog box.) Because some of an object's mandatory attributes are inherited from its parent class, you might need to view the attributes of the parent class in order to identify all of the mandatory attributes of your object. The Active Directory Schema snap-in is an MMC tool that is provided by Windows 2000 to enable administrators to modify the schema by using a graphical interface.

Attributes for classSchema O bjects

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; Auxiliary = 3.
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.