Informational Model

The informational (data) model of the LDAP protocol, and therefore, of Active Directory as well, is based on X.500 — the International Standards Organization (ISO) special standard defining elements of a distributed directory service. This standard proposes an object-oriented data model; therefore, it uses such terms as class, instance, and inheritance.

Schema

The schema defines classes and attributes, from which all directory objects can be derived. The schema itself is stored in the directory as a set of objects.

Directory Entry (Object)

Entry is an instance of a specific structural class and in Active Directory is usually called an object. An object can either be a container or a leaf. It is uniquely identified by its relative distinguished name (RDN) and distinguished name (DN).

Classes

Each directory object is an instance of one or more classes defined in the schema. In general, every object inherits from at least one structural object class and zero or more auxiliary object classes. There are three types of classes:

• Abstract classes serve as templates for deriving new abstract, auxiliary, and structural classes. Abstract classes cannot be instantiated in Active Directory, i.e., you cannot create a directory object of an abstract class. The definition of an abstract class can include any number of auxiliary classes.

• Structural classes are derived from abstract or structural classes and inherit all attributes of all parent classes. Active Directory objects can only be instances of structural classes. The definition of a structural class can include any number of auxiliary classes.

• An auxiliary class is derived from an abstract or auxiliary class and can be included in the definition of a structural, abstract, or auxiliary class. The defined class inherits all attributes of the auxiliary class listed in the mustContain, systemMustContain, may Contain, and systemMayContain properties. Auxiliary classes cannot be instantiated in Active Directory. The definition of an auxiliary class can include any number of auxiliary classes.

Attributes

Attributes contain the data used to describe properties of the defined classes. Attributes may be mandatory or optional, single- or multi-valued. An attribute is defined in the schema by a name and an object identifier (OID). Attributes are defined in RFC 2252 and RFC 2256. Here are the examples of attributes (these are the values of the lDAPDisplayName and attributeID attributes of the attributeSchema objects in the Schema container):

• nTSecurityDescriptor (1.2.840.113556.1.2.281)

• distinguishedName (2.5.4.49)

Attribute Syntax

The attribute syntax (see RFC 2252) defines the type of an attribute (e.g., a Unicode string, a number, an octet string, etc.), byte ordering, and the matching rules for comparisons of property types. The syntax of LDAP attributes is represented by object identifier (OID). For example:

• Distinguished Name (1.3.6.1.4.1.1466.115.121.1.12)

• UTC time (1.3.6.1.4.1.1466.115.121.1.53)

RootDSE Object

Every LDAP v3-complaint server has an individual DSA-Specific Entry object — RootDSE — defined in RFC 2251. This object is the root of the Directory Information Tree (DIT), but is not a part of any naming context (partition). It defines a directory server's configuration and capabilities.

Note 

Directory System Agent (DSA) is the system process that provides clients with access to directory information physically stored on a hard disk of a domain controller, or directory server. In Active Directory servers running on Windows 2000 or Windows .NET, the DSA is a part of the Local System Authority (LSA) subsystem.

RootDSE has properties that can be retrieved programmatically (see Listing 17.2) or by using a query tool (such as Ldp.exe or the ADSI Edit snap-in). To query a RootDSE from Ldp.exe, specify the empty base DN, the base scope, and the filter objectClass=*. (Search operations will be considered a bit later.) It is possible to bind to a specific server, or to use a server-less query. In the latter case, the first available LDAP server (a Windows 2000-or Windows .NET-based domain controller) will respond. Here is an example of the RootDSE data:

     1> currentTime: 6/12/2002 9:29:2 Central Standard Time Central Standard Time;     1> subschemaSubentry: CN=Aggregate, CN=Schema, CN=Configuration, DC=net, DC=dom;     1> dsServiceName: CN=NTDS Settings, CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom;     5> namingContexts: CN=Configuration, DC=net, DC=dom; CN=Schema, CN=Configuration, DC=net, DC=dom; DC=subdom, DC=net, DC=dom; DC=DomainDnsZones, DC=net, DC=dom; DC=ForestDnsZones, DC=net, DC=dom;     1>defaultNamingContext: DC=subdom, DC=net, DC=dom;     1> schemaNamingContext: CN=Schema, CN=Configuration, DC=net, DC=dom;     1> configurationNamingContext: CN=Configuration, DC=net, DC=dom;     1> rootDomainNamingContext: DC=net, DC=dom;     20> supportedControl: 1.2.840.113556.1.4.319; 1.2.840.113556.1.4.801; 1.2.840.113556.1.4.473; 1.2.840.113556.1.4.528; 1.2.840.113556.1.4.417; 1.2.840.113556.1.4.619; 1.2.840.113556.1.4.841; 1.2.840.113556.1.4.529; 1.2.840.113556.1.4.805; 1.2.840.113556.1.4.521; 1.2.840.113556.1.4.970; 1.2.840.113556.1.4.1338; 1.2.840.113556.1.4.474; 1.2.840.113556.1.4.1339; 1.2.840.113556.1.4.1340; 1.2.840.113556.1.4.1413; 2.16.840.1.113730.3.4.9; 2.16.840.1.113730.3.4.10; 1.2.840.113556.1.4.1504; 1.2.840.113556.1.4.802;     2> supportedLDAPVersion: 3; 2;     11> supportedLDAPPolicies: MaxPoolThreads; MaxDatagramRecv; MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MaxNotificationPerConn;     1> highestComittedUSN: 124992;     4> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;     1> dnsHostName: netdc2.subdom.net.dom;     1> ldapServiceName: net.dom:netdc2$@SUBDOM.NET.DOM;     1> serverName: CN=NETDC2, CN=Servers, CN=NET-Site, CN=Sites, CN=Configuration, DC=net, DC=dom;     3> supportedCapabilities: 1.2.840.113556.1.4.800; 1.2.840.113556.1.4.1670; 1.2.840.113556.1.4.1791;     1> isSynchronized: TRUE;     1> isGlobalCatalogReady: TRUE;     1> domainFunctionality: 2;     1> forestFunctionality: 2;     1> domainControllerFunctionality: 2; 

(Notice the numbers at the beginning of the lines — they indicate the number of values within an attribute.)

RootDSE contains the following standard attributes (refer to RFC 2251 and 2252):

• altServer — references to other servers that can be used when this server becomes unavailable. By default, this attribute is absent on Active Directory servers.

• namingContexts — the list of naming contexts stored on the server. Notice that in our example, the domain naming context (directory partition) refers to the subdom.net.dom domain, but two other contexts, the Schema and Configuration, refer to the forest root domain — net.dom. These contexts should be used when searching the directory. Windows .NET-based domain controllers can also store application directory partitions, and this attribute lists their names, too. In the example, you can see the distinguished names of two application partitions: domainDnsZones.net.dom and forestDnsZones.net.dom.

• subschemaSubentry — the name of the subschema entry (or the abstract schema; see Chapter 16, "Active Directory Service Interfaces (ADSI)"). This object contains definitions of available attributes and classes.

• supportedControl — the object identifiers (OID) of the LDAP controls that the server supports. This attribute may be absent. In comparison with Windows 2000, Windows .NET-based domain controllers support four new controls.

• supportedExtension — the object identifiers (OIDs) of the extended LDAP operations that the server supports. By default, this attribute is absent on Active Directory servers.

• supportedLDAPVersion — the LDAP versions supported by the server.

• supportedSASLMechanisms — the Simple Authentication and Security Layer (SASL) mechanisms supported by the server. This attribute may be absent. In comparison with Windows 2000, Windows .NET-based domain controllers support two new controls.

In addition, Active Directory supports the following attributes:

• configurationNamingContext — the Configuration context.

• currentTime — the current time.

• defaultNamingContext — the default context for the server. By default, this is the distinguished name of the domain where the server is located.

• dnsHostName — the server's DNS name.

• dsServiceName — the name of the directory service (NTDS).

• highestCommittedUSN — the highest USN committed to the database on this server.

• ldapServiceName — the Service Principal Name (SPN) for the server; used for mutual authentication.

• rootDomainNamingContext — the name of the forest where the server is located.

• schemaNamingContext — the Schema context.

• serverName — the distinguished name of the server object.

• supportedCapabilities — the object identifiers (OID) of the capabilities that the server supports. In comparison with Windows 2000, Windows .NET-based domain controllers support two new capabilities.

• supportedLDAPPolicies — supported LDAP management policies.

There are also two important operational attributes:

• isSynchronized — TRUE, if initial synchronization of this Active Directory replica with its partners has been completed (i.e., a newly promoted server can advertise itself as a domain controller).

• isGlobalCatalogReady — TRUE, if the domain controller has not simply been promoted to be a Global Catalog (GC) server, but has already advertised itself as a GC server.

Windows .NET-based domain controllers support three additional operational attributes, which represent domain and forest functional levels (see the next chapter for details):

• domainFunctionality — either 0 (both Windows 2000 mixed and Windows 2000 native levels) or 2 (Windows .NET level).

• forestFunctionality — either 0 (Windows 2000 level) or 2 (Windows .NET level).

• domainControllerFunctionality — is equal to 2 for any Windows .NET-based domain controller.