System Checks and Restrictions Imposed on Schema Additions and Modifications

When you try to add or modify a class or attribute, Active Directory performs some checks to make sure that the changes do not cause inconsistencies or other problems in the schema. The checks can be divided into two classes:

• Consistency checks
• Safety checks

Consistency checks maintain the consistency of the schema. Safety checks reduce the possibility of a schema update by one application breaking another application.

Consistency Checks

For both class and attribute changes, the system makes sure that the values of lDAPDisplayName and schemaIDGUID are unique and also that lDAPDisplayName is valid.

The class-schema object addition and modification extensions are successful only if the new class definition passes all of the following tests as well as the normal extension checks.

• The value of governsID must be unique.
• All attributes that are defined in the systemMayContain, mayContain, systemMustContain, and mustContain lists must already exist.
• All classes that are defined in the subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors, and possSuperiors lists must already exist.
• All classes in the systemAuxiliaryClass and auxiliaryClass lists must have either 88 class or Auxiliary class specified as their objectClassCategory.
• All classes in the systemPossSuperiors and possSuperiors lists must have either 88 class or Structural class specified as their objectClassCategory.
• Classes in the subClassOf list must follow certain X.500 specifications for inheritance hierarchies. These specifications are that Abstract classes can inherit only from other Abstract classes, Auxiliary classes cannot inherit from Structural classes, and Structural classes cannot inherit from Auxiliary classes.
• The attribute specified in the rDNAttID attribute must have Unicode-string as its syntax and be single-valued.

For attribute changes, the system also checks the following:

• The value of attributeID must be unique.
• The value of mAPIID, if any, must be unique.
• If rangeLower and rangeUpper are present, rangeLower must be smaller than rangeUpper.
• The values of attributeSyntax and oMSyntax must match, as shown in Table 4.11.
• If the attribute is object-syntaxed (oMSyntax=127), it must have the correct oMObjectClass, as shown in Table 4.12.
• The linkID, if any, must be unique. In addition, a back link must have a corresponding forward link. (For more information about links, see "Active Directory Data Storage" in this book.)

Note

A complete syntax specification consists of both the attributeSyntax and the oMSyntax. Hence, whenever more than one oMSyntax can be used with an attributeSyntax, the correct oMSyntax must be used.

Table 4.11 Values of attributeSyntax and Corresponding Syntaxes

For attributes with oMSyntax=127, the oMObjectClass also must be correctly specified according to the attributeSyntax. For attributes with any other oMSyntax value, it is not relevant and need not be specified. Because an oMObjectClass, being a binary value, is somewhat inconvenient to specify and because in most cases there is a one-to-one mapping between the attributeSyntax and oMObjectClass, the value defaults if none is specified by the user. There are a couple of cases where the mapping is not one-to-one, however, and the value defaults to the more common value. Table 4.12 is a list of the oMObjectClass values that correspond to the different attributeSyntax values for attributes with oMSyntax=127.

Table 4.12 Values of attributeSyntax and Corresponding oMObjectClass Values

Safety Checks

The purpose of the safety checks is to reduce the possibility of schema updates by one user or application breaking another application. These checks are necessary because multiple applications might share a schema definition.

When you modify existing schema objects, the modifications are subject to certain restrictions enforced by Active Directory. In some cases, these restrictions are determined according to whether the objects are part of the original schema or whether they have been added after the original installation. So the schema objects are really divided into two categories:

• Category 1 objects
• Category 2 objects

Category 1 objects are the default base schema objects that are included with Windows 2000 in the base schema. Category 2 objects are objects that are added subsequently to the schema by administrators or applications. You can determine the category in which an object is located by looking at the second bit (starting at the least significant bit) in the systemFlags attribute. If the bit is set, it has the value FLAG_SCHEMA_BASE_OBJECT, which indicates that the object is part of the base schema, that is, category 1. If this bit is not set or the attribute is not present, the object is category 2.

The following restrictions apply to both category 1 and category 2 schema objects:

• You cannot add a new mustContain attribute to a class either directly or through inheritance by adding an auxiliary class.
• You cannot add or delete any mustContain attribute of a class either directly or through inheritance.

The following restrictions apply to category 1 schema objects:

• You cannot change the rangeLower and rangeUpper of an attribute.
• You cannot change the atributeSecurityGUID of an attribute.
• You cannot deactivate a class or an attribute (make it defunct).
• You cannot change the lDAPDisplayName of a class or an attribute.
• You cannot rename a class or an attribute.
• You cannot change the defaultObjectCategory of a class.
• You cannot change the objectClassCategory of instances of a class.

© 1985-2000 Microsoft Corporation. All rights reserved.