How the Active Directory Schema Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

How the Active Directory Schema Works

In this section

• Active Directory Schema Architecture

• Active Directory Schema Physical Structure

• Active Directory Schema Processes and Interactions

• Related Information

The schema is the Active Directory component that defines all the objects and attributes that the directory service uses to store data. The physical structure of the schema consists of the object definitions. The schema itself is stored in the directory.

The schema is stored in its own partition (the schema partition) in the directory. The schema is replicated among all the domain controllers in the forest, and any change that is made to the schema is replicated to every domain controller in the forest. Because the schema dictates how information is stored, and because any changes that are made to the schema affect every domain controller, changes to the schema should be made only when necessary — through a tightly controlled process — after testing has been performed to ensure that there will be no adverse effects on the rest of the forest.

Active Directory Schema Architecture

In Active Directory, the schema defines the following:

• Objects that are used to store data in the directory

• The rules that govern the structure of those objects

• The structure and the content of the directory itself

These definitions consist of objects, attributes, and classes, which are described in the following section.

Schema Components

Objects, attributes, and classes are the basic components that are used to build object definitions in the schema.

Objects

Objects are structures that store both data that the objects represent and data that controls the content and structure of the objects. For example, a user account object contains a user’s logon name as well as data that indicates the proper syntax for storing the user’s logon name in the user object.

Active Directory uses objects to store data while the data is maintained in the directory. When the directory stores an object, some associated data is also stored along with the object. The extra data is stored in the attributes of the object.

Attributes

Attributes contain data that defines the information that is stored in an object or in another attribute. For example, a user account object has attributes that store user information, such as the user’s first name, last name, password, office number, and telephone number. Different types of objects have different attributes. A printer object has attributes that store information that is related to printers, such as the printer model, the number of paper trays, the current location of the printer, and the port to which the printer is attached.

Some attributes contain information that relates to other attributes, such as syntax information or flags that label the attribute as optional or required. Syntax attributes define the format that is used to store data in other attributes. For example, because a telephone number comprises only digits, a syntax attribute might specify that the phone number attribute can only store digits 0 through 9, and letters of the alphabet are prohibited. Active Directory uses syntax attributes to ensure that information is stored in a legitimate format and that the information is a valid data type.

Attributes can be required or optional. A user account object requires a user name attribute and a password attribute, although the office number attribute is optional. That is, a user account cannot be used without a user name; however, it can be used without an office number. The office number attribute is included for convenience, and it is considered an optional attribute.

An object definition is really an association of various attributes that are used to describe the characteristics of an object that stores specific pieces of data. The kind of data that the object stores determines which attributes are needed to define the object.

Large objects are made up of many smaller objects. In the user account object example, the user’s logon name attribute is a smaller object that contains a number of attributes of its own, including attributes that define the syntax of the logon name and that specify whether or not the logon name attribute is optional or required. The first name and last name attributes are also smaller objects that are defined in the schema. The object definition for the user account object lists the logon name attribute and the first name and last name attributes, as well as many other attributes, and it defines how these attributes relate to each other to store the data that represents a user account.

Defining objects and attributes this way gives the schema the ability to efficiently define many different types of objects. Many objects have some attributes in common. For example, many objects have a security descriptor to define who is allowed to access and make changes to the contents of the object. Rather than create a separate security descriptor definition for each object definition, the schema defines a single security descriptor object, and all other object definitions refer to the single security descriptor definition. This makes it possible for every object that needs a security descriptor to have one, while keeping only one definition for the security descriptor in the schema.

Classes

Object definitions are categorized into groups that are called classes. Classes act as blueprints that can be used each time a new object is created. When a new object is created in the directory, the object’s class determines the attributes that are associated with the new object, including which attributes are required and which attributes are optional.

Active Directory has predefined classes that define all of the different object type’s that the directory needs to function properly. For example, when a new user account object is created in the directory, its definition comes from the classUser class. The class dictates that the new account object is required to have a user name attribute and a password attribute, and optionally it might have an office number attribute.

Object definitions are created by nesting classes inside one another. Nesting classes produces a parent/child relationship between the classes. Classes that are nested inside another class are referred to as subclasses. The parent of a subclass is referred to as a superclass. When one class is nested inside another, the nested class inherits the properties of the parent superclass. When various classes that contain particular attributes are nested inside another object class, a new object definition is created. Which classes are nested depends on which attributes are needed to define the new object type.

The schema stores class information, but it does not store the actual objects that are derived from a class. For example, when a new user account object is created, it is not stored in the schema. Active Directory looks up the user class in the schema. Active Directory then retrieves information regarding the object type and its associated attributes from the user class in the schema and uses that information to create the new user account object. When the new account is created, the data is stored in the new object, and Active Directory then writes the new account information into the directory database.

The schema is the master list of all classes and attributes that can be used in the directory. During the installation of Active Directory, the Schema.ini file is used to build the default schema on the first domain controller in the forest. The default schema provides all the necessary classes that Active Directory needs to function. Administrators or developers might want to add their own classes or add their own attributes to an existing object type. They can do this through the process of extending the schema. The schema should only be extended in special situations. For more information about extending the schema, see “Modifying the Schema” later in this section.

Schema Objects

Active Directory uses objects to store and reference data in the directory. The schema defines the types of objects that are available to the directory service. The schema is stored in the schema partition, which is also defined as an object in the directory. The attributes and classes in Active Directory are stored in the schema partition as directory objects that are called schema objects. The schema partition itself is represented in Active Directory by an object that is an instance of the Directory Management Domain (dMD) class.

Storing the schema in the directory has many advantages. For example, when user applications locate the schema in the directory, they can read the schema to discover what types of objects and properties are available. Because the schema is stored in the directory — like the rest of the data in the directory — applications can locate the schema by using the same process that they use to locate any other object in the schema.

A schema object, called a classSchema object, defines each class in the schema. Another schema object, called an attributeSchema object, defines each attribute in the schema. Therefore, every class is actually an instance of the classSchema class, and every attribute is an instance of the attributeSchema class, as shown in the following figure.

Schema Objects

Schema objects are used to define classes and attributes in the schema. Classes in the schema are used to define objects in the directory.

attributeSchema Objects

Attributes describe the classes that are defined in the schema. Attributes are defined in the schema separately from classes, which enables a single attribute definition to be applied to many classes.

Attributes are attributeSchema objects. Each attributeSchema object is an instance of the attributeSchema class. Like any other object, the attributeSchema object has its own attributes. The attributes for the attributeSchema object store, among other things, the following information:

• The Lightweight Directory Access Protocol (LDAP) display name of the attribute

• The object identifier for the attribute

• The globally unique identifier (GUID) for the attribute

• The syntax of the attribute

• The range for the attribute. For integers, range defines the minimum and maximum value; for strings, range defines the minimum and maximum length.

• Whether the attribute is a multivalue attribute. Note that multivalue attributes hold a set of values with no particular order. Multivalue attributes might not be returned in the order in which they were stored (or in any other order).

• Whether and how the attribute is indexed

Attributes for the attributeSchema class

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

Attributes for the attributeSchema Class

Attribute	Syntax	Mandatory?	Multivalue?	Description
cn	Unicode	Yes	No	Descriptive relative distinguished name for the schema object
attributeID	Object identifier	Yes	No	Object identifier that uniquely identifies this attribute
lDAPDisplayName	Unicode	Yes, but automatic	No	Name by which LDAP clients identify this attribute
schemaIDGUID	String(Octet)	Yes	No	GUID that uniquely identifies this attribute
mAPIID	Integer	No	No	Integer by which Messaging API (MAPI) clients identify this attribute
attributeSecurityGUID	GUID	No	No	GUID by which the security system identifies the property set of this attribute
attributeSyntax	Object identifier	Yes	No	Syntax object identifier of this attribute
oMSyntax	Integer	Yes	No	Syntax of this attribute as defined by the XAPIA X/Open Object Model (XOM) specification
isSingleValue	BOOL	Yes	No	Indicates whether this attribute is a single-value or multivalue attribute Note that multivalue attributes hold a set of values with no particular order. Multivalue attributes might not be returned in the order in which they were stored (or in any other order).
extendedCharsAllowed	BOOL	No	No	Indicates whether extended characters are allowed in the value of this attribute Applies only to attributes of syntax String(teletex).
rangeLower	Integer	No	No	Lower range of values that are allowed for this attribute
rangeUpper	Integer	No	No	Upper range of values that are allowed for this attribute
systemFlags	Integer	No	No	Flags that determine specific system operations Note: This attribute cannot be set or modified. The following systemFlags attributes are relevant to the schema objects: Attribute is required to be a member of the partial set = 0x00000002 Attribute is not replicated = 0x00000001 Attribute is a constructed attribute = 0x00000004
searchFlags	Integer	No	No	The searchFlags property of each property’s attributeSchema object defines whether a property is indexed and other behavior. The seven currently defined bits for this attribute are: 1 = Index over attribute only 2 = Index over container and attribute 4 = Add this attribute to the ambiguous name resolution (ANR) set (should be used in conjunction with 1) 8 = Preserve this attribute on logical deletion (that is, make this attribute available on tombstones) 16 = Include this attribute when copying a user object 32 = Create a Tuple index for the attribute to improve medial searches 64 = Reserved for future use; value should be 0. 128 = Available in Windows Server 2003 Service Pack 1 (SP1) only. Mark the attribute confidential (CONTROL_ACCESS is required to read it).
isMemberof PartialAttributeSet	BOOL	No	No	A Boolean value that defines whether the attribute is replicated to the global catalog A value of TRUE means that the attribute is replicated to the global catalog. In environments where domain controllers are running Windows 2000 Server, changing this value might cause full synchronization of the Partial Attribute Set. For more information about the conditions under which full synchronization occurs, see How the Global Catalog Works on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=47817.
systemOnly	BOOL	No	No	Attributes on which Windows Server 2003 and Active Directory depend for normal operations If TRUE, only the system can modify this attribute. No user-defined attribute must ever have the systemOnly flag set.
objectClass	Object identifier	Yes	Yes	Class of this object, which is always attributeSchema
nTSecurityDescriptor	NT-Sec-Des	Yes	No	Security descriptor on the attributeSchema object itself
oMObjectClass	String(Octet)	No	No	For object-syntaxed attributes (OM-syntax = 127), the Basic Encoding Rules (BER) encoded object identifier of the XOM object class For more information about BER encoding, see Request for Comments (RFC) 2251 in the IETF RFC Database.
LinkID	Integer	No	No	Value that determines whether the attribute is a linked attribute. An even integer denotes a forward link; an odd integer denotes a back link. A forward link references a target object in the directory; a back link refers back to the source object that has a forward link to it.

Single-value and multivalue attributes

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

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.

Automated links

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.

Indexed attributes

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.

Confidential attributes

On domain controllers running Windows Server 2003 SP1 and later, 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 SP1 or later 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 SP1 or later. 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 SP1 or later.

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 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 and later 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 the 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 SP1 or later: A value in bit 128 (10000000) designates the attribute as confidential. Therefore, on a domain controller running Windows Server 2003 SP1 or later, you can designate an attribute as confidential by setting bit 128 in the searchFlags attribute of the respective attributeSchema object.

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.

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 https://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.

Syntaxes

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

Syntax	attributeSyntax	oMSyntax	ASN 1-Encoded Object Identifier	Description
Undefined	2.5.5.0		\x550500	Not a legal syntax
Object(DN-DN)	2.5.5.1	127	\x550501	The fully qualified name of an object in the directory
String(Object-Identifier)	2.5.5.2	6	\x550502	The object identifier
Case-Sensitive String	2.5.5.3	27	\x550503	General string — differentiates uppercase and lowercase
CaseIgnoreString(Teletex)	2.5.5.4	20	\x550504	Teletex — does not differentiate uppercase and lowercase
String(Printable), String(IA5)	2.5.5.5	19, 22	\x550505	Printable string or IA5-String Both character sets are case sensitive.
String(Numeric)	2.5.5.6	18	\x550506	A sequence of digits
Object(DN-Binary)	2.5.5.7	127	\x550507	A distinguished name plus a binary large object
Boolean	2.5.5.8	1	\x550508	TRUE or FALSE values
Integer, Enumeration	2.5.5.9	2, 10	\x550509	A 32-bit number or enumeration
String(Octet)	2.5.5.10	4	\x55050A	A string of bytes
String(UTC-Time), String(Generalized-Time)	2.5.5.11	23, 24	\x55050B	UTC time or generalized-time
String(Unicode)	2.5.5.12	64	\x55050C	Unicode string
Object(Presentation-Address)	2.5.5.13	127	\x55050D	Presentation address
Object(DN-String)	2.5.5.14	127	\x55050E	A DN-String plus a Unicode string
String(NT-Sec-Desc)	2.5.5.15	66	\x55050F	A Windows NT security descriptor
LargeInteger	2.5.5.16	65	\x550510	A 64-bit number
String(Sid)	2.5.5.17	4	\x550511	Security identifier (SID)

Object identifiers

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)

Numerical Values of the Object Identifier	What the Numerical Values Mean
1	ISO (“root” authority) issued 1.2 to ANSI.
2	ANSI issued 1.2.840 to the USA.
840	USA issued 1.2.840.113556 to Microsoft.
113556	Microsoft internally manages several object identifier branches under 1.2.840.113556 that include the following three identifiers.
1	A branch called Active Directory that includes the following two identifiers.
5	A branch called Classes that includes the following identifier.
4	A class called Builtin-Domain.

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.

classSchema Objects

The classSchema object specifies the various attributes of the class with which it is associated. Among other things, it defines the following constraints for objects that are instances of the class:

• mustContain attributes, which include mandatory attributes that must be present on any object that is an instance of this class

• mayContain attributes, which include optional attributes that may be found on an object that is an instance of this class

• Hierarchy rules that determine the possible parents in the directory tree of an object that is an instance of the class

An object can have attributes that belong only to either the mustContain list or the mayContain list for the class.

The classSchema object is essentially a template that contains the rules for creating objects in an Active Directory class. When a new object is created in a class, the classSchema object ensures that this new object has the same attributes as all other objects in the class.

The classSchema object contains, among other things, the following information:

• The LDAP display name of the class

• The object identifier for the class

• The GUID for the class

• The attributes that must be present for an instance of the class

• Other attributes that can be present for an instance of the class

• The classes to which the parent of instances of this class may belong

• The superclass from which this class inherits characteristics

• Other auxiliary classes from which this class inherits attributes

• The type of class (abstract, structural, or auxiliary)

• The default hiding state for the class. If you do not want instances of the class to be displayed by the end-user user interface (UI), you can define the class as hidden by default.

Attributes for classSchema objects

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

Attributes for a classSchema Object

Attribute	Syntax	Mandatory?	Multivalue?	Description
cn	Unicode	Yes	No	Descriptive relative distinguished name for the schema object
governsID	Object identifier	Yes	No	The object identifier that uniquely identifies this class
lDAPDisplayName	Unicode	Yes	No	The name by which LDAP clients identify this class
schemaIDGUID	String(Octet)	Yes, but defaulted	No	The GUID that uniquely identifies this class
rDNAttID	Object identifier	No	No	The relative distinguished name type of instances of this class (OU, CN)
subClassOf	Object identifier	Yes	No	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 the class is created, 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 This is 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 the class displayed in the UI for Active Directory admin tools New menus, you can define the class as hidden.
defaultSecurityDescriptor	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 that is merged into a security descriptor if a security descriptor is specified
objectClassCategory	Integer	Yes	No	Class types are defined as follows: 88 Class = 0 Structural = 1 Abstract = 2 Auxiliary = 3 The 88 class type is included for compatibility with older directories. Active Directory does not use 88 class type objects, and they should not be used in defining new classes for Active Directory.
systemOnly	BOOL	No	No	An attribute of a classSchema object If it is set to TRUE, only the system can create and modify instances of this class. If it is set to FALSE, modifications can also be made by users who have appropriate permissions.
objectClass	Object Identifier	Yes	Yes	This object’s class, which is always classSchema
nTSecurityDescriptor	NT-Sec-Desc	Yes	No	The 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, the objectClass value is used.

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

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

Inherited Mandatory Attribute	Default Status
nTSecurityDescriptor	Set to a default value if not specified. The default value depends on the default security descriptor for the classSchema object.
objectCategory	Automatically set 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. An administrator must specify the class.

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.

System and changeable attribute pairs

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 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.

Categories of Object Classes

Different categories of object classes make it possible to define structure in the directory. The 1993 X.500 specification requires that object classes be assigned to one of three categories:

• Structural

• Abstract

• Auxiliary

A fourth category, which is referred to as 88 classes, is associated with object classes, although this category is not part of the 1993 specification. The 88 class category is in the specification that existed before 1993, and it should not be used for adding classes to Active Directory.

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.

• 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

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

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 and later. 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 and later, 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.

88 classes

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.

Object class hierarchy

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 and Content Rules

The schema enforces rules that govern both the structure and the content of Active Directory. These rules validate changes to objects to ensure the integrity of the directory.

Structure rules

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

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.

Active Directory Schema Physical Structure

The schema exists as a set of directory objects, and it is stored in the directory. Active Directory partitions the information in the directory to facilitate more efficient replication. The schema is stored in its own directory partition so that it can replicate independently of other data that is stored in the directory.

Schema Location

The objects that are stored in Active Directory are arranged in a logical hierarchy called the directory tree. The directory tree is divided into directory partitions. A directory partition is a tree of objects that forms a unit of replication in Active Directory. The schema has its own directory partition to prevent potential dependency problems that can arise when new schema classes and new instances of the class are replicated simultaneously. Because the schema has its own tree, it is possible to replicate new schema changes to other domain controllers before replicating any new objects that may have been created based on those changes. This is important because the other domain controllers must have access to the object definitions that are stored in the schema before those domain controllers can properly store any new objects that are created by using those definitions.

Active Directory includes a preconfigured database, commonly referred to as the base directory information tree (DIT), which contains the information that is required to install and run Active Directory. The base DIT is created during a fresh installation of a Windows Server 2003 or later domain controller. The base DIT is contained in a file named Ntds.dit. One section of the base DIT is the base schema.

Schema Head

The schema head is the topmost object of the schema directory partition. Conceptually, the schema head functions like other containers in the directory tree, which means that it contains all of the schema information. However, the schema head is not a container in the sense of a special Active Directory object that contains other objects; rather, it is a special-purpose object class. Therefore, it is referred to as the schema head rather than the Schema container. The schema head contains all of the class definitions and attribute definitions that are required to locate objects in Active Directory and create new objects.

The relationships of the schema head, Configuration container, and Domain container are illustrated in the following figure.

Schema Head

Every Active Directory object can be referenced by a unique and unambiguous name known as the distinguished name. The distinguished name identifies the domain that holds the object as well as the complete path through the container hierarchy by which the object is reached. The distinguished name of the schema head can be expressed as follows:

cn=schema,cn=configuration,dc=ForestRootDomainName

You can view the contents of the schema head by using the Active Directory Schema snap-in. You can also bind to the schema directory partition and view schema objects by using the Active Directory Service Interfaces (ADSI) Edit snap-in or the Ldp tool.

Note

• ADSI Edit is not one of the default MMC snap-ins provided. To use ADSI Edit and Ldp, install the support tools that are located in the Support\Tools folder on the Windows Server 2003 or later operating system CD.

You can locate the schema head without knowing the domain name. Installation scripts and other applications can gain access to the schema because they bind to a special entry at the top of the logical namespace, called the root DSA-specific Entry (rootDSE), which provides the schema location. rootDSE represents the top of the logical namespace and, therefore, the top of the LDAP search tree. The attributes of rootDSE identify, among other things, the directory partitions — that is, the domain, schema, and configuration directory partitions — as well as the forest root domain directory partition. One attribute, schemaNamingContext, provides the location of the schema so that applications that connect to any domain controller can find and read the schema.

subSchema Subentry

rootDSE also carries a mandatory attribute called subSchemaSubEntry. The value of this attribute is the distinguished name of a subSchema object in the directory that defines the attributes (in attributeTypes) and classes (in objectClasses) that make up the Active Directory schema. This special object, which is an instance of the unique subSchema class, is used for administering information about the schema, in particular, the object classes and attribute types that are supported. This enables client applications to retrieve the schema information by querying the subSchema entry. Clients must only retrieve attributes from a subSchemaentry by requesting a base object search of the entry, where the LDAP search filter is (objectClass=subSchema). The following distinguished name describes the location of the SubSchemaSubEntry container:

CN=Aggregate,CN=Schema,CN=Configuration,DC=DomainName,DC=DomainRoot

For more information about LDAP searches, distinguished names, and containers, see “Data Store Technical Reference.”

Schema Files

Active Directory data is distributed among all domain controllers in the forest. No single domain controller stores all Active Directory data for the entire forest, but every domain controller does hold a copy of the schema. The database that stores the Active Directory data on a particular domain controller is in a file named Ntds.dit. The location of the Ntds.dit file is an option that you can set during the domain controller promotion process while you create the directory. The default location for Ntds.dit and the database log files is systemroot\Ntds. For more information about the Ntds.dit file, see “Data Store Technical Reference.”

Another file, the Schema.ini initialization file, contains the information that is necessary for creating the default directory objects and the default security for the directory tree, as well as the Active Directory display specifiers. Although this file is named Schema.ini, the schema itself is actually stored in the Active Directory database, Ntds.dit. Schema.ini is only used by the Active Directory Installation Wizard to build the initial schema structure in the directory during the domain controller promotion process. The Schema.ini file must not be modified.

Active Directory Schema Processes and Interactions

Normally, you do not interact directly with the schema on a daily basis. Active Directory uses the schema to help create objects that are stored in the directory. You interact with those objects, not the schema. You interact directly with the schema when you make modifications to the schema by adding definitions to it or by modifying existing definitions.

Schema changes can affect the entire directory. Before you make any changes to the schema, you should thoroughly test those changes in an isolated environment to ensure that the directory continues to function as planned after the changes have been deployed. Only members of the Schema Admins group can make changes to the schema.

The two most common reasons for modifying the schema are:

• Installation of an application that needs to add customized object definitions so that it can store information in the directory, for example, an e-mail program that stores the user’s e-mail names in the directory

• Testing of the development of applications that use the directory for data storage in which customized object definitions need to be added to the schema and modified throughout their lifetimes as the development process proceeds

Modifying the Schema

When the existing class and attribute definitions in the schema do not meet the needs of your organization, you can add or modify schema objects to extend the schema. You modify an existing attribute or add a new class or attribute to the schema to store a new type of information in the directory. The process of modifying or updating the schema is often referred to as extending the schema.

Before you extend the schema, you must take steps to ensure that the extension does not cause problems in the directory. Do not extend the schema in your production forest without testing the extension in a private forest. First, make changes in a test environment, and check that the changes behave as expected and that they meet your needs. After verifying the changes, you can use various utilities, such as Ldifde, and scripts or customized applications to export the extensions from the test environment and import them into the production environment. You perform most schema extensions by using applications or scripts that are written to extend the schema.

Note

• As is true for every object in Active Directory, schema objects are protected by access control lists (ACLs). Therefore, only authorized users can alter the schema.

To add or modify a class definition or attribute definition, you add or modify the corresponding classSchema object or attributeSchema object. This process is similar to adding or modifying any object in Active Directory, except that additional checks are performed to ensure that changes do not cause inconsistencies or problems in the schema.

Adding Information to the Schema

Extending the schema is a major change, with implications throughout the directory. Extend the schema only when it is absolutely necessary. Many schema modifications cannot be reversed; therefore, you must thoroughly plan and test changes before you deploy them in your production forest.

Planning to extend the schema

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.

Enabling schema extensions

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.

Identifying or transferring 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.

Granting access rights to make schema changes

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.

Enabling schema modifications on a domain controller

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.

Removing Information from the Schema

It is not possible to remove object definitions from the schema. However, object definitions can be rendered unusable through the process of deactivation. When an object definition is deactivated, it can no longer be used to create new objects in the directory. Objects whose definitions have been deactivated in the schema are referred to as defunct.

Deactivating schema objects

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.

Deactivating existing classes and attributes

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.

Effects of deactivating a schema object on schema updates

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 or later, 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.

Reactivating schema objects

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.

Updating the Schema Cache

When changes are made to Active Directory, they are validated against the schema, which can affect domain controller performance.

The schema is stored in the directory database. Because all changes are validated against the schema, they result in queries of the schema in the directory database, which can increase the workload on a domain controller. To make the operation more efficient, domain controllers cache the schema in memory. Anytime the schema is updated, the schema cache is also updated automatically.

After the domain controller is started, the schema cache is loaded from the schema information in the underlying database and updated automatically whenever the schema is updated. When changes are made, the schema cache is updated automatically within five minutes after the first change is applied. During the interval before the schema updates are copied to the schema cache, objects that reference a new or modified class or attribute cannot be added. If another domain controller attempts to use the new schema modifications, a replication interval must pass before the change becomes available. This behavior keeps the cache consistent, but it can be confusing because changes are not apparent until the cache is updated, even though they are applied to the directory database. When a change is replicated to a domain controller from a replication partner, the cache is updated immediately, without the five-minute delay.

You can update the schema cache by adding the schemaUpdateNow attribute to rootDSE with a value of 1. The value is not used; it acts as a trigger or operational attribute. You can write this attribute to start a cache reload.

Adding the schemaUpdateNow attribute causes a schema cache update to start immediately. The update operation is “blocking,” which means that no other modifications can be made until this operation is complete. This prevents multiple changes from being made to the schema simultaneously. If the operation finishes with no errors, the cache is updated and all schema updates are ready to be used. The return of an error, however, indicates that the cache update is not successful. Applications that add the schemaUpdateNow attribute should be designed to accommodate the blocking write, particularly to provide feedback if the program or script runs interactively.

You can also update the schema cache immediately by using Active Directory Schema: in the console tree, right-click Active Directory Schema and then click Reload the Schema.

Note

• If you must make multiple changes to the schema, complete all changes before forcing an immediate schema cache update, rather than forcing an update after each change. Multiple cache loads can result in increased workload on the server.

Default Security Settings for Active Directory Objects

The default security descriptor for an Active Directory object is specified in the schema. When a new object is created, Active Directory configures the default access rights for that new object. The security descriptor contains the settings that are used to configure the default access rights, and the security descriptor is stored in the schema as part of that object types definition.

Note

• There are special cases in which default security is not applied on newly created objects. For more information about access rights, see “Active Directory Schema” in the Microsoft Platform SDK on MSDN.

Default security settings for the domain directory partition

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.

Default security settings for the configuration directory partition

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.

Default security settings for the schema directory partition

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.

Default security settings for attributes and classes

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.

Issues Related to Modifying the Schema

Three main issues relate to modifying the schema:

• The impact on replication

• Managing concurrent schema modification operations

• Handling invalid object instances

Impact on replication

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.

Managing concurrent schema modification operations

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.

Handling invalid object instances

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.

Interoperating with Other Directories

To provide more support for industry standards in Active Directory, the schema supports the inetOrgPerson object class and the use of a standard file format for importing and exporting schema modifications.

inetOrgPerson Object Class

The Active Directory schema in Windows Server 2003 supports the inetOrgPerson object class. The inetOrgPerson object class and its associated attributes are defined in RFC 2798. The inetOrgPerson object class is used in several non-Microsoft LDAP and X.500 directory services to represent users in the directory.

Support for inetOrgPerson makes migrations from other LDAP directories to Active Directory more efficient. The inetOrgPerson class was added by adding new attributes to the schema and deriving inetOrgPerson from the user class and the new attributes. As a result, inetOrgPerson can be used as a security principal.

inetOrgPerson in Windows Server 2003 and Later

To help organizations migrate their applications and directory data to Active Directory, the inetOrgPerson class has been added to the base schema.

The definition of the inetOrgPerson class is based on RFC 2798. However, some issues have caused the Active Directory definition of this class to differ from the RFC definition, as follows:

• The inetOrgPerson class is derived from the user class, not the organizationalPerson class. This makes it possible for inetOrgPerson to operate as a security principal. Accounts that are created as inetOrgPerson objects can log in to Active Directory.

• Attributes that are already defined in the base schema are not changed.

  Several attributes in the base schema are defined as single-value instead of multivalue, or the reverse, as defined in the RFC 2798. The object identifier of some attributes differs from the definition in the RFC. Changing the definition of these attributes in the base schema to match the RFC causes backward compatibility problems with the Windows 2000 Active Directory schema and may result in application problems. For example, Microsoft Outlook will not display the data for attributes that have an unexpected value for the isSingleValued attribute. Active Directory management tools may treat the attributes incorrectly and inadvertently overwrite data or fail to update them at all.

• The inetOrgPerson class inherits two mandatory attributes:

  • The cn attribute is used to name a new instance of the class. The samAccountName attribute is the user’s login ID.

  • The objectCategory attribute for inetOrgPerson is set to Person. This has the effect of returning all user, computer, and inetOrgPerson objects when the filter in a query is objectCategory=Person.

Importing and Exporting Directory Information

Active Directory supports the use of files that are formatted with LDAP Data Interchange Format (LDIF) for importing and exporting information in the directory. This includes information that is stored in the schema, such as schema modifications.

LDIF is an industry-standard, ASCII, text-based file format that can be used to define data in a text file that is used to import information, such as schema modifications, into LDAP-based directories. LDIF is defined in RFC 2849.

After an LDIF file is created, a tool such as Ldifde.exe, which is available in Windows Server 2003 or later, performs the import operation using the data file for input. Ldifde.exe can also be used to export data from the directory. Exported data is also stored using the LDIF file format to make it easier to import the data into another LDAP-based directory. For more information about LDAP, see “Data Store Technical Reference.”

Related Information

The following resources contain additional information that is relevant to this section.

• RFC 2251 in the IETF RFC Database

• Microsoft Platform SDK on MSDN for more information about mandatory and optional attributes, modifying the schema, and access rights (in Active Directory Schema)

• Data Store Technical Reference