Attributes for the attributeSchema class are described in the following table.

Attributes for the attributeSchema Class

Some attributes contain a single value, and other attributes can contain multiple values. For example, the password attribute on a user object contains a single value: the password that is associated with the user account. The memberOf attribute contains multiple values: a list of the various groups of which the user account is a member. Each item in the list is stored as a separate value in the memberOf attribute. Attributes that can store more than a single value are referred to as “multivalue” attributes.

Whether or not attributes are single-value or multivalue is defined by the singleValue attribute as a Boolean value. The Active Directory Schema snap-in reports this attribute as “single-value” or multivalue rather than as the attribute-value pair. (Active Directory Schema is a Microsoft Management Console (MMC) graphical interface tool in Windows Server 2003 that administrators can use to manage the schema.)

All values that are defined for a multivalue attribute must have a uniform syntax. Multivalue attributes that are not linked can store a maximum of 1,300 entries. This limit is based on the size and type of the values that are stored.

Note

• When it retrieves data, LDAP reads a multivalue attribute as a single entity. This can be inconvenient or even impossible when the number of values in a multivalue attribute becomes large. A property called Range can be specified as part of an attribute description to retrieve the values of a multivalue attribute incrementally. Servers might or might not honor the Range property. Servers that support the Range property include the object identifier 1.2.840.113556.1.4.802 in the supportedControls operational attribute on the rootDSE. Clients must not use the Range property unless this object identifier is present. The Range property is a constant, case-insensitive string value (Range=), followed by a range specifier that lists the initial value and terminal value in the range.
  

Linked attributes make it possible to associate one object with another object. A linked attribute represents an interobject, distinguished-name reference. Linked attributes occur in pairs: forward link and backward link (back link). Linked attribute pairs exist on source objects and target objects, as follows:

• The forward link is a linked attribute on a source object (for example, the member attribute on the group object). It can be a single-valued attribute or a multi-valued attribute.
  
• As an option, a back link can be defined on a target object (for example, the memberOf attribute on the user object). A back-link attribute should be created as a multi-valued attribute, and it cannot exist without a corresponding forward link. The back-link attribute cannot be updated directly. Instead, it is automatically calculated when it is queried, based on the corresponding forward link. A back-link value on any instance of an object consists of the distinguished names of all source objects that have the target object's distinguished name in their corresponding forward link.
  

A linked pair is identified by the linkID values of two attributeSchema objects. The linkID of the forward link is an even, positive, nonzero value, and the linkID of the associated back link is the value of the forward linkID, incremented by one. For example, the value of linkID for member is 2 and the value of linkID for memberOf is 3.

The linkIDs must be unique within the forest. In Windows 2000 Server, linkIDs are allocated by the applications that used them, and it is up to application developers to make sure that the linkIDs for the applications do not conflict with linkIDs that are already in use. Windows Server 2003 can generate link values automatically to ensure that there are no conflicts within the forest. When new objects that use linked attributes are created, Active Directory automatically generates the necessary linkIDs.

Directory searches for attributes that are indexed are more efficient than searches for attributes that are not indexed. Attributes are indexed when the least significant bit in their searchFlags attribute is set to the value 1. Changing the value of the bit to 1 dynamically builds an index; changing the value to 0 or deleting it removes an index for the attribute in question. The index is built automatically by a background thread on the directory server.

The values for indexed attributes are stored in a sorted list. This makes searching much more efficient because the system needs to search only until it locates the area in the list where the value should be, based on the sort. If the value is not there, the system can assume it will not find the value anywhere else in the list, and it can terminate the search. When attributes are not indexed, the entire list must be searched to determine whether or not a particular value actually exists.

Indexing requires more storage to maintain the lists, but it makes searching more efficient. Nonindexed attributes are less efficient to search, but they require less storage to maintain. With this in mind, only attributes that are frequently referenced should be indexed. Ideally, indexed attributes are single-value attributes with unique values that are evenly distributed across the set of instances. Multivalue attributes can be indexed, but building the index requires more storage and updating.

On domain controllers running Windows Server 2003 with SP1, attributes whose attributeSchema objects are marked with a specific search flag are interpreted as confidential. Attributes that are so marked can be read only by users to whom the following access is granted:

• READ_PROPERTY
  
• CONTROL_ACCESS
  

The ability to mark attributes as confidential allows administrators to protect attributes from the read access that is granted by default to most users. Rather than changing the defaults that are expected by existing applications, administrators can create new attributes that can be read only by administrators or those to whom access is specifically granted. Because domain controllers must be running Windows Server 2003 with SP1 to recognize the flag that marks the attribute as confidential, protection of marked attributes is fully effective only in environments where all domain controllers have been upgraded to Windows Server 2003 with SP1. In particular, the schema operations master (also known as the schema flexible single-master operations (FSMO) role holder) must be upgraded to Windows Server 2003 with SP1.

By default, Active Directory performs a read-access check on an object in the following cases:

• When evaluating whether the object matches the search filter
  
• When returning attributes of an object that matches the search filter
  

Default security in Windows 2000 Server and Windows Server 2003 allows read access to the Pre-Windows 2000 Compatible Access group, which usually contains Authenticated Users. Authenticated Users is a security group that includes users whose identities can be authenticated by the server or by a trusted security authority. Because the Pre-Windows 2000 Compatible Access group is granted Read_Property permissions on user objects (including inetOrgPerson) and group objects, it is difficult to introduce a new attribute on these objects that is protected from reading by most users. For example, you might want to add a social security number attribute to the user class.

To solve this problem, Windows Server 2003 SP1 provides a way to mark an attribute as confidential by setting a searchFlags value on the attributeSchema object in the schema. The search flag contains multiple bits representing various properties of an attribute. In Windows 2000 Server and Windows Server 2003 schemas, the searchFlags attribute has six bits that can be set. (See the bits that are defined for the searchFlags attribute in "Attributes for the attributeSchema class" earlier in this section.) For example, a value of 1 in the least significant bit means that the attribute is indexed. The binary form of this flag value is 00000001. A new bit is added in Windows Server 2003 with SP1: A value in bit 128 (10000000) designates the attribute as confidential. Therefore, on a domain controller running Windows Server 2003 with SP1, you can designate an attribute as confidential by setting bit 128 in the searchFlags attribute of the respective attributeSchema object.

Note
You cannot set this flag on base-schema attributes, such as common-name.

When an attribute is so designated, in addition to READ_PROPERTY permission (for that attribute or all attributes on that object), CONTROL_ACCESS permission (for that attribute or a property set that contains that attribute) is required to read the attribute.

Note
When you assign CONTROL_ACCESS permissions to a user or group, you must specify a GUID — in this case, the GUID of the attribute or property set that contains the attribute.

To set the bit flag when no values are set, you can simply add the value 128 to the searchFlags attribute in the properties of the attributeSchema object for the confidential attribute. If a value is already present in the attribute, perform a bitwise OR operation to add 10000000 to the existing binary value, and then convert to decimal. For example, if the bit is set for indexing and containerized search (00001001), the combined values 10000000 OR 00001001 equal 10001001, translating to a decimal value of 137.

By default, only members of the Administrators built-in group are granted CONTROL_ACCESS to all objects. Therefore, only administrators can read confidential attributes. You can delegate the CONTROL_ACCESS right to any specific group by using the Dsacls command-line tool or by scripting. Dsacls is included in Windows Support Tools. To grant access to a confidential attribute, use Dsacls to grant the CONTROL_ACCESS right (CA) to the required group or user. Doing so introduces a way to impose additional security checks that control read access to selected attributes. For more information about Dsacls, see Dsacls.exe in the Active Directory Management Support Tools section of Windows Support Tools on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=43235. For more information about property sets and CONTROL_ACCESS permissions, see the Security Descriptors and Access Control Lists Technical Reference.

The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. The syntax defines whether the attribute value must be a string, a number, or a unit of time. Each attribute of every object is associated with exactly one syntax. The syntaxes are not represented as objects in the schema, but they are programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined. You cannot add new syntaxes.

When you define a new attribute, you must specify both the attributeSyntax and the oMSyntax numbers of the syntax that you want for that attribute. The attributeSyntax number is an object identifier, and the oMSyntax number is an integer. oMSyntax is defined by the XOM specification. Using this model, the syntax can provide detailed syntax definitions. For example, distinct oMSyntax attributes distinguish several types of printable strings, according to such factors as the supported character set and whether case is significant. The following table lists the valid syntaxes for attributes in the Active Directory schema.

Valid Syntaxes for Attributes in the Active Directory Schema

Object identifiers are unique numeric values that are granted by various issuing authorities to identify data elements, syntaxes, and other parts of distributed applications. Because they are globally unique, object identifiers ensure that the objects that are defined by these issuing authorities do not conflict with one another when different directories, such as Active Directory and Novell Directory Services, are used concurrently within a global directory namespace.

Object identifiers are found in Open Systems Interconnection (OSI) applications, X.500 directories, applications that use Simple Network Management Protocol (SNMP), and other applications in which uniqueness is important. Object identifiers are based on a tree structure in which a superior issuing authority allocates a branch of the tree to a subordinate authority, which in turn allocates subbranches of the tree.

LDAP requires a directory service, such as Active Directory, to identify object classes and attributes with an object identifier syntax. The object identifier is the value for the governsID attribute in a classSchema object and for the attributeID attribute in an attributeSchema object. These are required attributes; therefore, object identifiers are necessary when you create new classes or attributes.

Object identifiers in the Active Directory base schema include some object identifiers that are issued by the International Organization for Standardization (ISO) for X.500 classes and attributes and some object identifiers that are issued by Microsoft. Object identifier notation is a dotted string of nonnegative numbers, for example, 1.2.840.113556.1.5.4. The components of this object identifier are shown in the following table.

Components of an Object Identifier (1.2.840.113556.1.5.4)

Object identifiers ensure that every object is interpreted appropriately, for example, that a telephone number is not mistaken for an employee number. A series of widely used objects and attributes is standardized for use in object identifiers. New object identifiers are issued by standards authorities, and they form a hierarchy below which new object identifiers can be managed internally.

Most countries and regions in the world have an identified National Registration Authority (NRA) that is responsible for issuing object identifiers to enterprises. In the United States, the NRA is the American National Standards Institute (ANSI). The NRA issues root object identifiers. An enterprise can register a name for the object identifier as well. A fee is associated with registering root object identifiers and registered names. Contact the NRA for your country or region for details. The ISO recognizes NRAs and maintains a list of contacts on its Web site.

The issuing authority assigns an object identifier space that is a branch of the ISO-International Telecommunication Union (ITU) object identifier tree. For example, your organization might be assigned the space 1.2.840.111111. You can extend this space internally within the constraints of the structure of an object identifier. You can subdivide this space further (by appending dotted decimals to the object identifier root) and assign these subspaces to various divisions within your organization. Each division, in turn, can further subdivide the subspace that is allotted to it.

For the example object identifier 1.2.840.111111, your organization might use the subspace 1.2.840.111111.1.4 for attributes and the subspace 1.2.840.111111.1.5 for classes. An internal issuing authority in your organization, using an Administrator account, might then allocate object identifiers from this space when requested. The governsID attribute on every classSchema object and the attributeID attribute on every attributeSchema object are mandatory attributes that contain an object identifier string. In this example, all of your organization-created classSchema objects have a governsID attribute of the form 1.2.840.111111.1.5.x, where x is a decimal number. Similarly, all of your organization-created attributeSchema objects have an attributeID attribute of the form 1.2.840.111111.1.4.x.

Microsoft also offers a free object identifier registration service.

The following table lists the attributes that a classSchema object can have.

Attributes for a classSchema Object

The attributes in a classSchema object’s mustContain attribute list are not the complete set of attributes that must be present for an instance of a class to exist. For example, in a 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 attributes are defined this way as well, except that possSuperiors attributes are inherited only from classes in the subClassOf list, not from the classes in the auxiliaryClass list.

Mandatory attributes are object attributes for which you must specify values. If you do not specify a value for a mandatory attribute, the attribute receives a default value or the object is not created until you specify a value for the attribute. The object’s mandatory attributes are determined by the class to which the object belongs.

Some mandatory attributes are inherited. Because every classSchema object belongs to a superclass called Top in the class hierarchy, each classSchema object inherits the mandatory attributes that belong to Top. The following table lists the mandatory attributes that every object inherits from Top. To see a graphical representation of the Active Directory class hierarchy, see the figure under “Object class hierarchy” later in this section.

Mandatory Attributes That All classSchema Objects Inherit

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 for the object. 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 to identify all the mandatory attributes of the object.

Some properties of a class-definition object are contained in pairs of attributes, in which the value of one of these attributes can be changed by administrators and the value of the other attribute cannot be changed. These attribute pairs are as follows:

• mustContain/systemMustContain
  
• mayContain/systemMayContain
  
• possSuperiors/systemPossSuperiors
  
• 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 to ensure that the schema stays consistent and usable. System-only properties can be changed only by the Directory System Agent (DSA). System-only properties are those properties on which Windows Server 2003 and Active Directory depend for normal operations. For example, the attributeID attribute and the governsID attribute in the schema are system-only attributes. The values of the other (nonsystem) attributes in each pair can be changed by administrators.

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.
  
• Is derived from either an abstract class or another 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 are templates that are used 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 structural 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. Abstract classes only provide attributes for subordinate classes, which are called subclasses. A subclass contains all mandatory and optional attributes of the class from which it is derived (its superclass) in addition to those attributes that are specific to the class itself. Likewise, the subclass of that class contains all attributes of both superclasses, and so forth.

Auxiliary classes are like include files; they contain a list of attributes. Adding an auxiliary class to the definition of a structural class or an abstract class’ adds the auxiliary classs 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 class. The attributes of the securityPrincipal class help the system recognize the user object as a security account. Similarly, the group class has securityPrincipal as an auxiliary class.

The behavior of auxiliary classes has changed in Windows Server 2003. In Windows 2000 Server, changes that are made to an auxiliary class affect its parent class as well as all instances of the parent object. For example, adding an auxiliary class called pager to the structural class user affects all instances of user, which is all of the user accounts that are created with the user class.

In Windows Server 2003, auxiliary classes can be assigned dynamically to individual instances of classes, rather than being applied automatically to all instances. For example, you can assign the pager auxiliary class to only those users who need it.

Classes that were 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 before the X.500 1993 standards are assigned to the 88 class. This type of class is specified by a value of 0 in the objectClassCategory attribute. Do not use 88 classes or define new 88 classes.

Inheritance, which is also referred to as derivation, is the ability to build new object classes from existing object classes. A new object is defined as a subclass of its 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 class. 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 the parent classes in the directory hierarchy (systemPossSuperiors and possSuperiors). This relationship between the superclasses and their subclasses represents the object class hierarchy, which is illustrated in the following figure.

Object Class Hierarchy

All structural object classes are subclasses, directly or indirectly, of a single abstract object class, which is called Top. Every object that is 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 do not create 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 later add another attribute 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.
  

Structure rules define the possible tree structures. When you create a new object, structure rules determine the validity of the object class to which you designate the new object. You cannot create an object that belongs to a nonexistent class. You must first create the new class.

Conversely, these rules do not allow you to delete or modify an object that has already been deleted. In Active Directory, the structure rules are completely expressed by the possSuperiors and systemPossSuperiors attributes that are present on each classSchema object. These attributes specify the possible classes that can be parents of an object instance of the class. In other words, the possSuperiors and systemPossSuperiors attribute values determine the object classes and, therefore, the location in the directory tree under which objects of the class can be instantiated.

Content rules determine the mandatory and optional attributes of the class instances that are stored in the directory. New objects must contain all the mandatory attributes that are specified by the classSchema object in the schema. New objects can contain any of the optional attributes. In Active Directory, the content rules are completely expressed by the mustHave, mayHavemayContain, systemMustContain, and systemMayContain attributes of the schema definitions for each class. In addition, there are some operational attributes that are read-only. These are identified by the first bit of the systemFlags property for an attribute definition that is set to 1, for example, lastLogon.

For more information about mandatory and optional attributes, see Active Directory Schema in the Microsoft Platform SDK on MSDN.

Planning to extend the schema involves examining the default schema that comes with Active Directory to verify that there is no way to use the existing classes or attributes for your needs. It also involves understanding the types of modifications that can and cannot be made.

For more information about modifying the schema, see “Active Directory Schema” in the Microsoft Platform SDK on MSDN.

After you decide to make changes to the schema and you carefully plan the types of changes that you are going to make, you can proceed by implementing and testing the schema extensions in a test environment that is isolated from your production network.

Because extending the schema is a significant operation, Active Directory has the following safety features, or interlocks, that restrict schema modifications:

• The Active Directory Schema snap-in must be registered. Active Directory Schema is not listed with the default MMC snap-ins. It must be registered before it can be made available. This means that Schmmgmt.dll must be registered by using Regsvr32.exe.
  
• Changes to the schema must be written only on the schema master. Although all domain controllers have a copy of the schema in their Active Directory database, only the domain controller that holds the schema operations master role (also known as flexible single master operations (FSMO)) is allowed to write changes to the schema.
  
• Administrators must have specific access rights. Only members of the schema administrators group (Schema Admins) or another administrator with explicit permission can make changes to the schema.
  
• Schema modifications must be enabled. By default, schema modification is disabled on all domain controllers, including the domain controller that hosts the schema operations master role.
  

Active Directory performs schema updates in a single-master fashion to prevent conflicts such as conflicts resulting from simultaneous schema updates on two different computers. The one domain controller in the forest that is allowed to perform schema updates at any specific time is referred to as the schema master. The schema master is the domain controller that holds the schema operations master role. After the schema master completes an update, it replicates the changes to all other domain controllers by normal replication channels. In this way, changes to the schema are distributed throughout the forest.

Note

• To update the schema, the domain controller that holds the schema operations master role must be available on the network. All schema modifications must be made to the domain controller that holds the schema operations master role. If you attempt to modify the schema from a domain controller that does not hold that role, the domain controller generates a referral to the current schema master to process the modifications.
  

Because the schema master must be used to extend the schema, the domain controller that currently holds the schema operations master role in the forest must be identified. As the forest grows and changes, it may also become necessary to assign the schema operations master role to a different domain controller. You can accomplish both of these tasks by using Active Directory Schema or the command-line tool Ntdsutil.

You can change the domain controller that serves as the schema master at any time. The current schema master in the enterprise is identified by the value of the FSMORoleOwner attribute on the schema head of the domain. By default, the first domain controller that is installed in the forest is the initial schema master.

To modify the schema, you must use an account that is a member of the Schema Admins group. By default, the only member in the Schema Admins group is the Administrator account in the root domain of the enterprise. You must explicitly add other accounts.

You can use Active Directory Users and Computers in MMC to verify that an account is a member of the Schema Admins group. Restrict membership in the Schema Admins group to prevent unauthorized access to the schema. Improper modification of the schema can have serious consequences.

By default, only members of the Schema Admins group have permission to write to the schema. You can grant explicit permissions to use Active Directory Schema to specific users. However, this is not recommended.

If you want to allow the domain controller that holds the schema operations master role to modify the schema, use Active Directory Schema to enable schema modifications.

You cannot deactivate schema objects that are part of the default schema that ships with Active Directory. You can freely deactivate schema objects that have been added to the default schema.

As a result of replication latency, it is not possible to accurately determine if any objects have been created by using a given schema definition or to predict if the objects may be restored from backup media. Therefore, Active Directory does not support the actual deletion of schema objects. Rather, it provides a mechanism for deactivating schema objects in such a way that they become unavailable for use in the directory. Although a schema object still physically exists in the directory after it has been deactivated, new instances of it cannot be created in the directory. Any existing instances of data that are associated with the deactivated schema object continue to exist in the directory; however, there is no way to modify these data instances other than to delete them. This behavior makes the schema object appear to be deleted from the schema.

You can use Active Directory Schema or ADSI Edit to deactivate a class or an attribute by setting the attribute isDefunct to the Boolean value of TRUE on the schema object.

You can use Active Directory Schema to view defunct schema objects: on the View menu, make sure that Defunct Objects is selected. In addition, you can write programs and scripts to search for all schema objects that have the attribute isDefunct set to TRUE. You can also use the Search function of the Ldp tool to search the schema with a filter that is set to isDefunct=TRUE.

As with the addition or modification of classes or attributes, some special validation checks are performed on the deactivation of classes or attributes to ensure consistency of the schema. In particular, when you deactivate a class, Active Directory verifies that the class is not used in the subClassOf, auxiliaryClass, or possSuperiors attributes of any existing active class. Similarly, when you deactivate an attribute, Active Directory checks that the attribute is not used in the mustContain or mayContain attributes of any existing active class.

Deactivation of schema classes and attributes is subject to the following restrictions:

• You cannot deactivate a class or attribute that appears in the base Active Directory schema. You can only deactivate schema extensions of the base schema.
  
• You cannot deactivate an attribute that is referenced in the mustContain,systemMustContain, mayContain, systemMayContain, or rdnAttId properties of an active class.
  
• You cannot deactivate a class that is referenced in the subClassOf, auxiliaryClass, or possibleSuperior properties of an active class.
  

To deactivate an attribute, set the isDefunct attribute of itsattributeSchema object to TRUE. When an attribute is deactivated, it can no longer be added to new class definitions. To reactivate an attribute, set the isDefunct attribute to FALSE.

To deactivate a class, set the isDefunct attribute of its classSchema object to TRUE. When a class is deactivated, new object instances of the class can no longer be created. To reactivate a class, set the isDefunct attribute to FALSE.

After a class salesUser is deactivated, any subsequent addition or modification of instances of salesUser fails as if salesUser has been deleted from the system; the same error codes are returned as if salesUser never existed at all. For example, creating a new instance of salesUser fails, and trying to modify or rename an existing instance of salesUser fails. Similarly, if an attribute hasPager is deactivated, hasPager is treated as nonexistent for new object creations, and attempting to modify (add or replace) the value of hasPager in an existing object fails.

However, you can still search for and delete existing instances of deactivated schema objects. For example, you can still search for all existing instances of salesUser and delete them, if necessary. Note that what you are doing is searching for and deleting objects that were created in the directory using the deactivated class, salesUser, not deleting the actual class definition from the schema. Similarly, you can search for all instances that have a value for the attribute hasPager and delete hasPager from the existing objects. This facilitates cleanup after a schema object is deactivated. If you decide that a class is not needed anymore, you can deactivate it so that no one can use it for any modifications. You can then clean up the existing instances of the class by searching for all instances and deleting them. Active Directory does not perform any automatic cleanup of data instances after a schema object is deactivated.

Similarly, you can deactivate an attribute and clean up all its instances. Note that, for a deactivated attribute, you can delete only the entire attribute from an object, not certain values of the attribute. For example, if hasPager is a multivalue attribute and an object has more than one value for hasPager, you cannot delete only one value of hasPager from the object.

In addition to affecting instances of the schema object, deactivating a schema object also affects schema updates, because schema object updates are subject to special validation checks. For example, if you deactivate the class salesUser or the attribute hasPager, subsequent schema object updates behave as follows:

• Deactivated classes and attributes can be renamed in the schema. They can also be modified to make other changes to the corresponding classSchema and attributeSchema objects. Note that this behavior is different from the behavior of the Windows 2000 Active Directory schema, in which no modifications are allowed on defunct classes or attributes, except modifications of the isDefunct attribute to reactivate the deactivated class or attribute.
  
• Validation checks that are performed when you add a new class or attribute or when you modify an existing nondefunct class or attribute treat salesUser as nonexistent. For example, if hasPager is a defunct attribute, trying to modify an existing nondefunct class by adding mayContain=hasPager fails because the validation checks that are performed at schema modification time fail as if hasPager does not exist. Or, in the case of a defunct class salesUser, trying to add a new class with subClassOf=salesUser fails, because salesUser is treated as nonexistent by the validation checks that are performed during the addition of the class.
  

There is an exception to the rule of defunct classes being treated as nonexistent in Windows 2000 Active Directory. When you try to add or modify a class or attribute so that it has the same distinguished name; object identifier (attributeID, governsID); lDAPDisplayName; mAPIID; or schemaIDGUID as the defunct class or attribute, the operation fails. In these cases, the class or attribute is treated as an active schema object from the standpoint of schema consistency checks during schema update operations. In Windows Server 2003, this behavior has changed. Defunct objects are still left in the directory. However, it is possible to create a new object that uses the same identification attribute values (that is, attributeID, governsID, lDAPDisplayName, mAPIID, or schemaIDGUID) as a defunct schema object, as long as the new object’s distinguished name is unique. This makes it possible to deactivate a schema object and then create an entirely new schema object — reusing the same values in its definition as the deactivated object — as if the old object were actually deleted. For example, you can change the canonical name (CN) of a defunct object so that you can reuse its old name in the definition of a new schema object. This is very valuable for developers who must constantly modify various classes and attributes for testing purposes. It is possible now to mark an old version of an object definition as defunct and install a new version of the object that uses the same identifiers, making it much easier to develop and test applications that interact with the directory.

This ability to make schema objects defunct can be very useful in different ways in production environments. You can clean up schema objects that are no longer needed by making them defunct. Defunct schema objects are not visible in Active Directory Schema unless you specifically select them on the View menu. Then, you can delete existing instances of those classes or attributes if you want to. At the same time, if you need a schema object later, you can reactivate it by modifying the isDefunct attribute on the object. This also protects against the accidental removal of a schema object by making it defunct. Making a schema object defunct can be reversed easily with no side effects. Note that because Active Directory does not do any cleanup of data instances after a schema object is made defunct, all instances of the schema object that are made defunct by mistake remain and become valid data when the defunct schema object is made active again.

You can reactivate a defunct schema object either by removing the isDefunct attribute from the object or by setting the value of the isDefunct attribute to FALSE. You can perform both operations by using either Active Directory Schema or ADSI Edit. Because reactivating a defunct schema object requires schema updates that are similar to adding a new schema object, Active Directory performs the same validation checks as it does when you add a new schema object.

The following validation checks are performed when a defunct schema object is reactivated:

• A defunct class cannot be reactivated unless the attributes that are referenced in its mustContain, systemMustContain, mayContain, systemMayContain, or rdnAttId attributes — as well as the classes that are referenced in its subClassOf, auxiliaryClass, and possibleSuperior attributes — are already active.
  
• A defunct class cannot be reactivated if the value of any of the attributes lDAPDisplayName, governsID, or schemaIDGUID is the same as the value that is stored in an already active class or attribute.
  
• A defunct attribute cannot be reactivated if the value of any of the attributes lDAPDisplayName, attributeID, schemaIDGUID, mAPIID is already in use by an active class or attribute.
  

A defunct schema object can be reactivated at any time. The only restriction is that the isDefunct attribute should be the only attribute that is present in the modify call. This helps prevent any ambiguity problems while schema consistency checks are performed.

The domain directory partition object is derived from the object class domainDNS. Therefore, the default security of the domain directory partition object is equivalent to the default security for domainDNS.

The default security descriptor for the domain directory partition includes the following permissions:

• Full Control to the Domain Admins group and the System group and Read to the Authenticated Users group.
  
• Read on all properties to the Everyone group. This permission provides backward compatibility for application programming interfaces (APIs).
  
• Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Enterprise Domain Controllers group. These permissions allow members of the Enterprise Domain Controllers group to manage replication automatically.
  
• Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin Administrators group. Administrators of individual domain controllers can use these permissions to troubleshoot replication problems.
  
• Inheritable Full Control to the Enterprise Admins group. Enterprise Admins, by definition, have complete control of each domain.
  
• Inheritable List Contents to the Pre–Windows 2000 Compatible Access group.
  
• Inheritable Read Property on Remote Access Service (RAS) Information, General Information, Membership, User Account Restrictions, and User Logon on all User Objects permissions to the Pre–Windows 2000 Compatible Access group.
  
• Inheritable Read on all Group objects.
  
• Inheritable Auditing successful/failed writes to the Everyone group. Activating the auditing policy ensures that writes that are performed on any object in the directory are audited immediately, without the need for extra user intervention. Inheritable access control entries (ACEs) provide a convenient way to remove auditing policy.
  

The default security descriptor for the configuration directory partition includes the following permissions:

• Full Control to the Domain Admins group and System and Read to the Authenticated Users group.
  
• Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Enterprise Domain Controllers group. These permissions enable domain controllers in the forest to replicate from each other and automatically reconfigure the replication topology on the basis of replication delays and latency for the configuration directory partition.
  
• Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin Administrators group. These permissions enable administrators from individual domain controllers to synchronize replication and topology management for the configuration directory partition.
  
• Enable Inheritable Full Control to the Enterprise Admins group. This permission allows members of the Enterprise Admins group exclusive control over the Configuration container. The Enable Inheritable Full Control permission is required to control the Configuration container throughout the forest.
  
• Enable Inheritable Auditing to the Writes by the Everyone group. Activating the auditing policy ensures that writes that are performed on any object in the directory are audited immediately, without the need for extra user intervention. Inheritable ACEs provide a convenient way to remove auditing policy.
  

The default security descriptor for the schema directory partition includes the following permissions:

• Write access to the schema head to the Schema Admins group.
  
• Change Schema Master control permission to the Schema Admins group. This permission enables members of the Schema Admins group to change which domain controller holds the schema operations master role.
  
• Inheritable Full Control permission to the Schema Admins group. By default, the Schema Admins group is the only group that has Write access to the entire schema head. A schema object does not have any exclusive control over its own security; therefore, the object inherits its security from the schema head.
  
• Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology to the Enterprise Domain Controllers group. These permissions enable the members of the Enterprise Domain Controllers group to manage replication of the schema in the forest automatically.
  
• Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin Administrators group. These permissions enable the administrators of domain controllers to resolve replication issues.
  
• Read permissions to the Authenticated Users group. This permission gives the members of the Authenticated Users group the right to read the schema.
  
• Audit successful/failed writes to the Everyone group. Activating the auditing policy ensures that writes that are performed on any object in the directory are audited immediately without the need for extra user intervention. Inheritable ACEs provide a convenient way of removing auditing policy.
  

All attributes and classes inherit security from the ACLs on the schema head. This ensures that security for the entire schema is consistent.

Note

• The default security settings allow Write access to the schema head only to the Schema Admins group.
  

Because the schema is replicated across all domain controllers in the forest, a schema update that is performed at one domain controller is propagated throughout the forest. This guarantees that the schema is consistent across the forest. However, because of replication latencies, there can be temporary inconsistencies.

Active Directory solves this problem by explicitly replicating the schema head from the originating server when failures occur. Additionally, the replication of the schema head triggers an immediate schema cache update on the target server. Active Directory then replicates the failed object again.

Programs that modify the schema should not be run concurrently unless the programs include provisions to check that schema modifications that are made by one program will not conflict with schema modifications that are made by the other programs. Active Directory must ensure that different program threads do not perform simultaneous, conflicting schema updates, such as one thread deleting an attribute when another thread is adding the attribute to the mayContain list of a class.

To ensure that different program threads do not perform simultaneous, conflicting schema updates, any thread that attempts to perform a schema update also writes a special attribute on the schema head automatically as part of the transaction. Active Directory automatically causes the thread to write the attribute so that you do not have to do so in your program code. Only one thread can write this attribute at any one time. This method guarantees schema consistency, but it does not guarantee which of the updates is successful. This is an important consideration when schema updates are made in a batch, such as during the installation of directory-enabled applications.

For example, consider a scenario in which two programs, program A and program B, are being installed simultaneously. Both programs are designed to create several new schema objects. Because Active Directory creates one thread per object update, it is possible that some of the objects in program A and some of the objects in program B are created (if the internal threads do not overlap). Then, one of the installations fails because a thread for a schema object creation for program A overlaps with a thread for a schema object creation for program B.

Assume that program A fails because of the thread conflict and the resulting failure to create some of the needed schema objects. Attempting to reinstall program A again does not work because some of the objects that program A created are already in the schema, and trying to create them again in the second run returns an error.

Schema updates can make an existing instance of an object invalid. For example, suppose a user account object, JohnDoe, is an instance of classSalesEmployee. The classSalesEmployee class has an attribute, POBox, in its mayContain list. Therefore, because JohnDoe is an instance of classSalesEmployee, JohnDoe can have the POBox attribute defined in it. Assume that JohnDoe does have this attribute currently defined in it. A schema update is performed that modifies classSalesEmployee by deactivating the attribute POBox from its mayContain list. Note that this change makes the instance of JohnDoe invalid because JohnDoe now has an attribute, POBox, that it is not allowed to have according to the class definition of classSalesEmployee (of which JohnDoe is an instance). Active Directory allows the now-invalid objects to remain in the directory and ensures that they do not cause problems in the rest of the schema. Active Directory does not automatically clean up invalid objects, but invalid objects and attributes appear in searches and can be deactivated manually.