The specification of all Active Directory protocols is based on a definition, shared by all Active Directory protocols, of the state of a server running Active Directory that is implied by the protocols. Call this the "state model" of Active Directory.

The Active Directory state model is divided into two categories:

  1. Certain state that is represented as objects and attributes within Active Directory is promoted directly into the state model. State within Active Directory becomes part of the state model if it satisfies one of the following conditions:

    1. It is replicated.

    2. It is nonreplicated, but a protocol exists in the protocol documentation set of applicable Windows Server releases whose behavior is dependent upon the state.

      The representation of nonreplicated state that is only accessed by a process running on the same server, that is itself implementing Active Directory, is private to the implementation. Therefore, such attributes are not promoted directly into the state model. It might still be required for this state to be modeled as described in category 2 later in this section.

      Excluded from the second condition above is all generic access by browsing tools such as ldp.exe that can access any attribute of any object in the directory. If ldp.exe or a similar tool covered by a Windows license can display or even modify a nonreplicated attribute of an object using only the attribute's syntax as defined by the schema, that does not make the attribute part of the state model. If ldp.exe or a similar tool covered by a Windows license accesses a nonreplicated attribute and decodes or encodes its value using information outside the attribute's syntax as defined by the schema, that nonreplicated attribute is included in the state model under condition 1 (2) above. For example, by using LDP, it is possible to look at a nonreplicated attribute using an attribute's syntax of type String(Unicode). However, if the string stored in that attribute would be an XML content defined by an external XSD, then if LDP had special knowledge of how to interpret that XML, that nonreplicated attribute would be included in the state model under condition 1 (2) above.

  2. Other state, however represented within Active Directory, is "abstracted" in the state model. Such state is included only as necessitated by the requirement that a licensee implementation of the protocols of applicable Windows Server releases has to be capable of receiving messages and responding in the same manner as applicable Windows Server releases.

    For example, certain values sent by the Active Directory replication protocol [MS-DRSR] are accompanied by metadata. If the replicated values are stored by the receiving system, it must also store the metadata associated with the values. Otherwise, the receiving system will make incorrect responses to subsequent replication requests. These incorrect responses will, in general, prevent replication from converging. So this metadata must be included within the state model. The specific way that this metadata is stored by Active Directory, and the algorithms that optimize access to this metadata, are excluded from the state model.

    The various indexes used by the Active Directory implementation to improve the performance of directory search are another example of state within Active Directory. These indexes have no effect, other than performance, on the protocol responses that Active Directory makes. Therefore, these indexes are not included in the state model.

In this specification, the first category of state is modeled in a variant of LDAP information structures: naming contexts, objects, attributes, and values. These structures are defined precisely in the following sections. The set of replicated attributes is defined in [MS-ADA1], [MS-ADA2], and [MS-ADA3]. The set of nonreplicated attributes covered under condition 1 (2) (described earlier in this section) consists of the repsFrom and repsTo attributes documented in [MS-DRSR] sections 5.172 and 5.173.

Note Only the schema elements and instances of objects that are fundamental to Active Directory are described in this specification. If a protocol defines its own schema objects or otherwise creates its own objects in the directory, those objects are described in that protocol's specification. A summary of schema elements defined by such other protocols is included in [MS-ADA1], [MS-ADA2], [MS-ADA3], [MS-ADSC], and [MS-ADLS] as a convenience for the reader, but the documentation for the protocols using those schema elements should be consulted for a complete description.

In this specification, the second category of state is modeled using standard mathematical concepts. The concepts used and their associated notational conventions are described in the next section.

LDAP mandates very little about the behavior of a directory. Active Directory has many specific behaviors that are observable through LDAP. The remainder of this section describes the most pervasive of these behaviors. The remainder of the specification completes the discussion.