Classes and attributes are defined in the schema by classSchema objects (object classes) and attributeSchema objects (object attributes), as follows:

• Object classes are categories of objects that can be created in the directory. For example, users, computers, and printers are classes of objects. Every object in the directory is created as an instance of some class according to the definition that is stored in the classSchema object for the respective class.
  
  
• Object attributes are the characteristics of the object. (These characteristics are also called properties). An attribute can hold a value or values that represent some property of the object. For example, given name, surname, and e-mail address are attributes of every object of the user class, and their values can be created only as character strings. The schema specifies the attributes that are required to have values and the attributes that can have values as an option. In Active Directory, only attributes that have values assigned to them actually use storage space in the database.
  
  
• Each attribute has a syntax that is specified in the schema that determines the kind of values that are allowed in the attribute. Examples of attribute syntaxes are Unicode string, binary, and integer.
  
  

New object classes and attributes can be added to the schema, and existing objects can be modified by adding or modifying classSchema and attributeSchema objects.

Child classes inherit attributes from their parent classes. Therefore, each class builds on the attribute set of its parent class. The position in the directory tree of one object relative to another is also defined in the schema.

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
  
  

Structural classes

Abstract classes

Auxiliary classes

Object identifiers (also known as OIDs) are hierarchical, dotted-decimal numeric values that uniquely identify entries in a data model. Object identifiers are found in OSI applications, X.500 directories, Simple Network Management Protocol (SNMP), and other applications in which uniqueness is required. Object identifiers are based on a tree structure in which a designated issuing authority (such as the ISO) allocates a branch of the tree to a subauthority, which in turn can allocate subbranches. The Active Directory schema identifies the object identifier for each class, attribute, and syntax.

The schema directory partition has an attribute called objectVersion that stores the schema version number for a forest. To facilitate upgrading your forest from Windows 2000 Server to Windows Server 2003, Windows Server 2003 includes a tool (Adprep.exe) that automatically upgrades the schema to the version that is required by Windows Server 2003. Before you upgrade the first domain controller, you must use this tool to prepare the domain and the forest so that the schema is upgraded before the operating system is upgraded. Running Adprep.exe prepares the forest and the domain for the Active Directory upgrade by making certain data changes, including an extension of the schema. This schema extension merges existing schema information with new schema information that is supplied by Adprep.exe. This merging of schema information does not affect any schema modifications that you may have already made in your existing environment.

Objects in Active Directory are either leaf objects or container objects. A leaf object is an object that has no child objects. The term “container” refers to one of two things:

• An object of the container structural class
  
  
• An object that has child objects
  
  

In the schema, a structural class defines objects that can be created as instances of the class in Active Directory. To have child objects, an object must be an instance of a class that is defined by the schema as being a possible superior of those child objects.

Note

• A new attribute in the Windows Server 2003 schema, msDsApproxImmedSubordinates, stores the approximate count of immediate children of a container. You can use the ADSI Edit snap-in in Microsoft Management Console (MMC) to view the value of this attribute for any container object. Windows 2000 Server containers do not have this attribute.
  
  

The directory tree represents the hierarchy of Active Directory objects for a given forest. The structure of the hierarchy is derived from the schema, and the directory service implements the hierarchy. The hierarchy provides the basis both for using names for navigation and for defining the scope of search requests.

Every object in Active Directory has exactly one parent, and a reference to the parent object is stored with the object. By virtue of these parent references, the hierarchy of objects that are managed by Active Directory forms a tree structure. The objects that populate the directory create this tree structure according to the rules of the schema. For example, the schema might dictate that a given class of object can be the child of one class but not the child of another class.

The following are architectural restrictions and requirements in the directory tree:

• Domain objects, which are containers, can be children only of other domain objects. For example, a domain cannot be the child of an organizational unit (OU).
  
  
• The root of the directory tree is a DSA-Specific Entry (DSE) called the rootDSE, or the directory root. The rootDSE is an object that has no hierarchical name or schema class, but it does have a set of attributes that identify the contents of a given domain controller. Therefore, the rootDSE constitutes the root of the directory tree from the perspective of the domain controller to which you are connected.
  
  
• Below the rootDSE, every directory has a root domain, which is the first domain that is created in a forest. This domain always has a child container called the Configuration container, which contains configuration data for the forest.
  
  

An LDAP directory service is also referred to as a DSA. In Active Directory, servers that host DSAs are domain controllers.

At the root of an LDAP directory tree is a DSE (the rootDSE), which is not part of any directory partition. TherootDSE represents the top of the logical namespace for one domain controller. The rootDSE attributes contain information about the directory server, including its capabilities and configuration.

There is only one root for a given DSA, but the information that is stored in the root is specific to the domain controller to which you are connected. Among other things, the attributes of the rootDSE identify the following key information:

• The directory partitions (the domain, schema, and configuration directory partitions) that are specific to one domain controller
  
  
• The forest root domain directory partition
  
  

In this way, the rootDSE provides a “table of contents” for a given domain controller. For more information about rootDSE attributes, see “Data Store Technical Reference.”

Every object in Active Directory has a distinguished name (also known as DN). A distinguished name uniquely identifies an object by using the name of the object, plus the names of the container objects and domains that contain the object. Therefore, the distinguished name identifies the object as well as its location in a tree. The distinguished name is unambiguous (that is, it identifies one object only) and unique (that is, no other object in the directory has this name). It contains enough information for an LDAP client to retrieve the object’s information from the directory.

For example, a user named Jeff Smith works in the marketing department of a company as a promotions coordinator. His user account is created in an OU that stores the accounts for marketing department employees who are engaged in promotion activities. The root domain of the company is proseware.com, and the local domain is noam.proseware.com. The distinguished name for this user object is:

cn=Jeff Smith,ou=promotions,ou=marketing,dc=noam,dc=proseware,dc=com

The relative distinguished name (also known as the RDN) of an object is the part of the distinguished name that is an attribute of the object itself — the part of the object name that identifies this object as unique within a container. For the example in the previous paragraph, the relative distinguished name of the user object:

cn=Jeff Smith,ou=promotions,ou=marketing,dc=noam,dc=proseware,dc=com

is cn=Jeff Smith.

The following figure illustrates the relative distinguished names that make up the distinguished name of the user object Jeff Smith.

Relative Distinguished Names That Make Up a Distinguished Name

The maximum length that is allowed for a relative distinguished name is 255 characters, but attributes have specific limits that are imposed by the directory schema. For example, in the case of the common name (cn), which is the attribute type that is often used for naming the relative distinguished name, the maximum number of characters that is allowed is 64.

Active Directory relative distinguished names are unique within a container; that is, Active Directory does not permit two objects with the same relative distinguished name under the same parent container. However, two objects can have identical relative distinguished names but still be unique in the directory because, within their respective parent containers, their distinguished names are not the same. For example, the object cn=Jeff Smith,cn=users,dc=noam,dc=proseware,dc=com is recognized by LDAP as being different from cn=Jeff Smith,ou=marketing,dc=noam,dc=proseware,dc=com.

The relative distinguished name for each object is stored in the Active Directory database. Each object in the directory contains a reference to the parent of the object. An LDAP operation can construct the entire distinguished name by following these references to the root.

Each portion of the distinguished name is expressed as attribute_type=value. The attribute type that is used to describe the object’s relative distinguished name (in the Jeff Smith example, cn) is called the naming attribute. In Active Directory, instances of classes have a default mandatory naming attribute that is defined in the schema. For example, part of the definition of the class user is the attribute cn (Common-Name) as the naming attribute. Therefore, the relative distinguished name for user Jeff Smith is expressed as cn=Jeff Smith.

Classes that do not define a naming attribute inherit the naming attribute from their parent class. If you create a new class in the Active Directory schema (that is, if you create a new classSchemaobject), you can use the optional rDNAttID attribute to specify the naming attribute for the class.

The following table shows the naming attributes that are used in Active Directory.

Default Active Directory Naming Attributes

Other naming attributes that are described in RFC 2253, “Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names,” such as o= for organization name and c= for country/region name, are not used in Active Directory.

The use of distinguished names, relative distinguished names, and naming attributes is required when you are programming for LDAP and using ADSI or other scripting or programming languages. Active Directory tools, such as Active Directory Users and Computers, do not require you to enter such values, nor do they display these values. However, LDAP editors, such as ADSI Edit in Support Tools, require input and display output in the LDAP distinguished name format.

Using different naming attributes for users to avoid naming collisions

Object identity

In addition to distinguished names, other formats for providing object names are supported by Active Directory. These formats accommodate the different forms that a name can take, depending on its application of origin.

The LDAP distinguished name in the example earlier in this section can be used to illustrate the other Active Directory name formats. This example distinguished name identifies the account of user Jeff Smith in the OU Promotions, in the OU Marketing, in the domain noam.proseware.com:

cn=Jeff Smith,ou=promotions,ou=marketing,dc=noam,dc=proseware,dc=com

The following formats are supported by Active Directory, and the format examples are based on the LDAP distinguished name of Jeff Smith:

• LDAP Uniform Resource Locator (URL). Active Directory supports access through the LDAP protocol from any LDAP-enabled client. LDAP URLs are used in scripting. An LDAP URL names the server that holds Active Directory and the attributed name of the object (the distinguished name), for example:
  
  ldap://server1.proseware.com/cn=Jeff Smith,ou=promotions,ou=marketing,dc=noam,dc=proseware,dc=com
  
  
• Active Directory canonical name. By default, the user interface (UI) for certain Active Directory administrative tools displays object names as canonical names. When you view the properties of objects in Active Directory Users and Computers and Active Directory Sites and Services, the Object tab shows the canonical name of the selected object. The canonical name lists the relative distinguished names from the root downward, without the naming attribute descriptors, and it uses the Domain Name System (DNS) domain name, as follows:
  
  noam.proseware.com/marketing/promotions/Jeff Smith
  
  

Note

• If the name of a container includes a forward slash character (/), the system requires an escape character in the form of a backslash (\) to distinguish between forward slashes that separate elements of the canonical name and the forward slash that is part of the container name. For example, if the name of an OU is Promotions/Northeast and the name of the domain is proseware.com, the canonical name is displayed as proseware.com/Promotions\/Northeast.
  
  

Although DNS domain names match Active Directory domain names, they are not the same thing. Active Directory names have a different format, which is required by LDAP to identify directory objects. Therefore, DNS domain names are mapped to Active Directory domain names (and back again) as described in RFC 2247.

All access to Active Directory is carried out through LDAP, and every object in Active Directory has an LDAP distinguished name. An algorithm automatically provides an LDAP distinguished name for each DNS domain name.

The algorithm provides a domain component (dc) attribute-type label for each DNS label in the DNS domain name. Each DNS label corresponds to the relative distinguished name of a DNS domain. For example, the DNS domain noam.proseware.com is translated to the LDAP distinguished name that has the form dc=noam,dc=proseware,dc=com.

LDAP authentication consists of the following operations:

• Bind. Initiates a protocol session to the DSA. After a session is established, a method of authentication is negotiated between the DSA and the client. When the client is authenticated by the DSA, the DSA returns a bind response to the client.
  
  
• Unbind. Terminates an LDAP session between the client and the DSA.
  
  
• Abandon. Issued by the client to stop obtaining the results of a previously initiated operation.
  
  

LDAP interrogation consists of the following operations:

• Search. Used to select entries from a specific region of the directory information tree based on customized criteria called a search filter. The search operation includes several arguments, which are described in “Performing an LDAP Search” later in this section.
  
  
• Compare. Returns a Boolean response based on a comparison of an entry’s attribute value with a user-supplied value.
  
  

LDAP update consists of the following operations:

• Add. Creates an object in the directory information tree based on information that is provided by the client to the DSA. The information that is passed to the DSA must meet the conditions that are imposed on entry creation through the classes that are defined in the schema.
  
  
• Modify. Allows the client to modify an entry’s attributes. Modification of attributes includes creating, modifying, and deleting the attributes.
  
  
• Modify RDN. Provides a mechanism for an entry to be moved in the directory. Modifying the relative distinguished name components of an entry effectively moves the entry to a new container in the directory.
  
  
• Delete. Provides a method for a client to remove an entry from the directory. The success of an entry modification depends on the schema’s constraints and the access permission of the client.
  
  

Active Directory supports several LDAP controls that extend the functionality of LDAP v3 beyond the standard set of nine LDAP operations. Microsoft has defined these LDAP controls to provide functionality in Active Directory that is not provided by current IETF RFCs. The rootDSE indicates all controls that are in effect for the contacted server through the object identifier values in the supportedControl attribute.

Extended LDAP control functionality is useful to programmers who are using LDAP to perform directory operations. Some of the operations that can be implemented by using extended controls are deleting trees, paging and sorting search results, and showing deleted objects. For more information about these operations, see “Optimizing Searches” later in this section.

In accordance with RFC 2251, LDAP protocol elements are encoded on the wire using the Basic Encoding Rules (BER) of Abstract Syntax Notation One (ASN.1).

The first step that a directory client must take in conducting an Active Directory search is to find an LDAP directory server (in other words, a domain controller) to search against. To find a domain controller, directory clients rely on DNS. When a domain controller starts up, it registers service (SRV) records in DNS that indicate that the domain controller provides LDAP directory services. To locate a domain controller, a directory client performs a DNS query for SRV records of hosts that provide LDAP directory services. For more information about how DNS is used to locate domain controllers, see “DNS Support for Active Directory Technical Reference.”

After it finds a directory server, a directory client must next connect to the server. A directory client can connect to an LDAP directory server by opening a session on a TCP port number on which the LDAP directory server is listening. The string that is used to establish the connection includes the fully qualified domain name (FQDN) of the LDAP directory server, along with the TCP port number of the directory server. For standard LDAP searches, directory clients connect to TCP port 389. To search the Active Directory global catalog, directory clients must instead connect to TCP port 3268.

For more information about the global catalog, see “Global Catalog Searches” later in this section. For information about TCP ports that are used by LDAP directory servers and clients, see “Network Ports Used by Active Directory Searches” later in this section.

After a directory client establishes a communications path to the domain controller, it must bind to the domain controller to establish the logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. (A client can also attempt to bind to a domain controller without first establishing a connection.) The bind operation identifies the connecting person, device, or application to the server by providing a distinguished name and some type of authentication credential, such as a password. The exact credentials depend on the authentication method that is being used.

LDAP v3 enables the client to negotiate with the LDAP server to determine the best available security package. If no security package is available, the bind is a simple bind that uses a plaintext password. The Microsoft implementation of the LDAP API uses the NEGOTIATE flag so that the client can discover the best security package that is available. For example, a SASL mechanism, such as Kerberos V5 or NTLM, might be used. A domain controller can be also be configured to accept anonymous connections.

LDAP bind request

LDAP: ProtocolOp: BindRequest (0)
  LDAP: MessageID = 11 (0xB)
  LDAP: ProtocolOp = BindRequest
    LDAP: Version = 3 (0x3)
    LDAP: Name = 
    LDAP: Authentication Type = Sasl
      LDAP: Sasl Mechanism = GSS-SPNEGO
      LDAP: Sasl Credentials

LDAP authentication methods

LDAP bind response

LDAP: ProtocolOp: BindResponse (1)
  LDAP: MessageID = 18 (0x12)
  LDAP: ProtocolOp = BindResponse
    LDAP: Result Code = Success
    LDAP: Matched DN = 
    LDAP: Error Message = 
    LDAP: Sasl Mechanism = GSSAPI
    LDAP: Sasl Credentials

  LDAP: ProtocolOp: BindResponse (1)
  LDAP: MessageID = 8 (0x8)
  LDAP: ProtocolOp = BindResponse
    LDAP: Result Code = Invalid Credentials
    LDAP: Matched DN = 
    LDAP: Error Message = 

SPNEGO

Concurrent bind for Web site logons

Anonymous queries

LDAP searches are the most common LDAP operations that are performed against an Active Directory domain controller. An LDAP search retrieves information about all objects within a specific scope that have certain characteristics, for example, the telephone number of every person in a department.

The following parameters are used in LDAP to accomplish an LDAP search:

• Search base (the distinguished name of the search base object). Defines the location in the directory from which the LDAP search begins.
  
  
• Search scope. Defines how deep to search within the search base:
  
  
  • Base (or zero level). Indicates a search of the base object only.
    
    
  • One level. Indicates a search of objects immediately subordinate to the base object but not the base object itself.
    
    
  • Subtree. Indicates a search of the base object and the entire subtree of which the base-object distinguished name is the topmost object.
    
    
• Filter. Allows certain entries in the subtree and excludes others.
  
  
• Selection. Indicates what attributes to return from objects that match the filter criteria.
  
  
• Optional controls that affect how the search is processed.
  
  

The following figure shows the base distinguished name and the possible search scopes of an LDAP search.

LDAP Search Base and Three Search Scopes

The following figure shows the base distinguished name for a container object that is the search base for a search of an OU structure in Active Directory. The entire distinguished name is constructed from the relative distinguished name of an OU named Sales.

Base Distinguished Name for an LDAP Search

Search filters

Active Directory stores information about the existence and location of directory partitions in a forest, including the names of the directory partitions and the names of domain controllers that hold replicas of those directory partitions. Active Directory uses this information (known as knowledge references) to generate referrals to other domain controllers.

Active Directory uses three kinds of knowledge references to generate referrals to other domain controllers:

• A subordinate reference, which is knowledge of a directory partition (or partitions) directly adjacent in the naming hierarchy to a directory partition that is held by the domain controller.
  
  
• A cross-reference, which is knowledge of one directory partition and which is stored in a cross-reference object in the Partitions container. On a specific domain controller, the combination of all cross-references provides knowledge of all directory partitions in the forest, regardless of the locations of those directory partitions in the directory tree.
  
  Note
  
  
  • The state of cross-reference knowledge at any specific time is subject to the effects of directory replication latency.
    
    
• A superior reference, which is knowledge of a specifically designated location that is used whenever the domain controller has no knowledge of the search base that is used in a search.
  
  

Knowledge references are the glue that holds the pieces of the distributed directory together. Because Active Directory is logically partitioned and directory partitions are the discrete components of the directory that replicate between domain controllers, either all objects in a directory partition are present on a particular domain controller or no objects in the directory partition are present on the domain controller. References have the effect of linking directory partitions together, which enables operations such as searches to span multiple domain directory partitions.

In Active Directory, referrals are generated when a client requests that the directory locate an object where, based on the position at which the search begins, no copy exists in a local directory partition. When Active Directory can determine definitively from the information it holds that no such object exists in the directory — rather than that it might exist somewhere else, even though no copy exists locally — instead of sending a referral, the directory returns an error message to the client that no such object exists in the forest.

For information about replication of directory partitions, see “Active Directory Replication Model Technical Reference.”

When a client requests a search, the domain controller searches all objects at or below the search base in the directory partition that the domain controller holds. If a subtree search has a search base that includes child partitions, the domain controller uses information that is provided by subordinate references to return referrals (called subordinate referrals) to these partitions on other domain controllers.

Subordinate referrals are returned as part of the data that is returned from the distinguished name of the directory partition that is named in the search base. The referral contains the distinguished name of the subordinate directory partition and the access point to which queries can be referred. An access point consists of a DNS name and a port number, which is the information that is required to contact a specific LDAP server. Access points are generated from information that is contained in the cross-reference object.

Cross-references are stored as directory objects of the class crossRef that identify the existence and location of all directory partitions, irrespective of their location in the directory tree. Cross-reference objects are used to generate referrals to other directory partitions in the forest and to external directories.

Cross-references enable every domain controller to be aware of all directory partitions in a forest, rather than only the directory partitions that a particular domain controller holds. Because cross-reference objects are stored in the Configuration container, they are replicated to every domain controller in the forest.

Cross-reference objects store the following information:

• nCName . The distinguished name of the directory partition that the crossRef object references. (“nC” stands for “naming context,” which is a synonym for “directory partition.”) The combination of all of the nCName properties in the forest defines the entire directory tree, including the subordinate and superior relationships between directory partitions.
  
  
• dNSRoot. The DNS name of the domain where servers that store the particular directory partition can be reached. This value can also be a DNS host name.
  
  

Cross-reference objects are created in two ways:

• Internally, by the system, to refer to known locations that are within the forest.
  
  
• Externally, by administrators, to refer to locations that are external to the forest.
  
  

Internal cross-references

External cross-references

The only time that you have to create a cross-reference object is when you want to extend a search to a directory outside the forest that is a non-Windows LDAP directory service. In this case, you can use an LDAP editor such as ADSI Edit to create objects of the class crossRef (in the Partitions container) that reference external directories.

When you create a cross-reference object, you must provide the values for three attributes:

Creating an external cross-reference for an external location

Creating an external cross-reference for an internal location

A superior reference is the fully qualified DNS name of a directory partition that is stored in the superiorDNSRoot attribute on the crossRef object for the forest root domain (the first domain that is created in the forest). A domain controller uses its superior reference to construct a referral only when a search base does not match any directory partition that is defined by the cross-reference objects. A superior reference contains no directory tree information; it consists of only an access point to which otherwise unanswerable queries can be referred.

By default, superiorDNSRoot does not store a value, but the directory uses the dc= components of the search base distinguished name to construct the equivalent of a superior referral. You can use the superiorDNSRoot attribute to define a location to which all queries that cannot be resolved are sent.

You can improve search behavior by indexing the attributes that are most likely to be searched. The searchFlags attribute of an attributeSchema object indicates whether the attribute is indexed and the nature of the indexing.

The searchFlags attribute is an integer value whose least significant bits indicate whether the attribute is indexed and in what way. Use the OR operator to combine the bit values to achieve the appropriate indexing behavior.

Values in the searchFlags attribute have the following effects:

• 1 = Index over attribute only. Bit 0 must be set (0001). You can use the Active Directory Schema MMC snap-in to set this flag.
  
  
• 2 = Index the attribute in each container (this value is used in conjunction with 1). Bit 0 and bit 1 must be set (0011). You can use Active Directory Schema to set this flag.
  
  
• 4 = Add this attribute to the ANR set (this value is used in conjunction with 1). Bit 0 and bit 2 must be set (0101).
  
  
• 8 = Preserve this attribute on logical deletion (that is, make this attribute available on tombstones). Bit 3 must be set (1000).
  
  
• 16 = Copy the value for this attribute when the user object is copied. You can use this value to set up a user object template so that you can create multiple users by making copies of an original and providing values for only those attributes that are unique to each user. Bit 4 must be set (10000). For example, set this flag for attributes, such as company and department, that you want to copy, but do not set attributes that must be unique, such as objectSid and sAMAccountName.
  
  
• 32 = Index this attribute for medial-string search (this value is used in conjunction with 1). Bit 5 and bit 0 must be set (100001). This indexing capability is provided on domain controllers running Windows Server 2003 when the schema has been updated for Windows Server 2003 functionality.
  
  

Optimizing container searches

ANR

(| (displayName=xxx yyy*)
(givenName=xxx yyy*)
(physicalDeliveryOfficeName=xxx yyy*)
(proxyAddresses=xxx yyy*)...
(sn=xxx yyy*)
(& (givenName=xxx*)(sn=yyy*))
(& (givenName=yyy*)(sn=xxx*)))

Searching for deleted objects

Medial-string searches

Efficient listing of large search results in Windows Server 2003

LDAP v3 supports the definition of client query policy. By default, limits are placed on the server resources that are available to clients requesting LDAP queries, paged result sets, and sorted result sets. These limits constitute the LDAP query policy.

The query policy is stored as a multivalue attribute (lDAPAdminLimits) of the Default Query Policy object in the configuration directory partition (cn=Default Query Policy,cn=Query-Policies,cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=Forest RootDomain).

Note

• LDAP query policy is not related to, and is not a subset of, Group Policy.
  
  

Because the workload and resources of a given server can vary, the LDAP query policy is configurable at the server level.

LDAP query policy applies to the following LDAP query–related operations:

• Search. The basic query operation. An LDAP search might cover a small part of a single domain, or it might span every directory partition in the forest. A search can generate a significant amount of disk activity, take a long time, and return a large volume of data.
  
  
• Search with Paged Results. Because a search can return a large volume of data, the client can ask the server to hold the result set and return it in “pages” of a specified length. The server must hold the result set until the client releases it or unbinds.
  
  
• Search with Sorted Results. A client can request a result set in a particular order. Sorting requires storage and CPU cycles at the server. The resources consumed are directly proportional to the size of the result set.
  
  
• Search with Replication. The administrator can specify the maximum number of attribute values that can be returned per request.
  
  
• Change Notify. A client can request change notification on particular objects in the directory. The mechanism that is used to post a Change Notify request is the asynchronous LDAP query.
  
  

In the absence of any other assigned policy, all domain controllers use the default query policy. If a site policy is assigned, the domain controller uses the site policy. If a specific policy has been assigned to a domain controller, this policy takes precedence over any site policy.

Administrative query policies: attribute values

To improve the query response time for searches for Active Directory objects, searches are limited to 1,000 objects by default. However, you may want to increase this limit as your organization grows. You can control the buffer size that is allocated for storing the number of objects that are returned by a query search. To control the buffer size, you can either modify the registry on the search client or use Group Policy to set the buffer size on all computers in a domain, site, or OU.

Modifying the registry to change the maximum query limit

Using Group Policy to change the maximum query limit

When an LDAP client is accessing a server across a slow connection or if the result set from a given query may be very large, the client can retrieve a result set in small pieces. The Simple Paged Result extended control provides for this type of retrieval. Options for this control enable the client to set the initial page size and reset the page size with each subsequent request to the server.

The Simple Paged Result control is also used to access all of a large results set when there is a server-side administrative limit to the number of items that are returned from a query. For example, domain controllers running Active Directory have a default server-side limit of 1,000 entries as the maximum number of results that are returned in a single request. If the results of a query exceed this limit, the Paged Results control is used, with a page size equal to or less than the server-side limit, to retrieve all of the results of the query.

For more information about paging, see “Paging Search Results” in the Microsoft Platform SDK on MSDN.

Attributes can be single value or multivalue. Single-value and multivalue attributes are defined by the singleValued attribute being set to TRUE or FALSE. A multivalue attribute can contain multiple values, all of uniform syntax. Note that multivalue attributes hold a set of values with no particular order. There is no guarantee that multivalue properties are ever going to be returned in the order in which they were stored (or in any other order).

Retrieving the contents of a multivalue attribute, such as a distribution list, can often result in a large number of returned values. LDAP servers often place limits on the maximum number of attribute values that can be retrieved in a single query. If an attribute has more members than can be returned by the server in a single call, the only way to enumerate all of the attribute values is through the use of the range option.

Range retrieval involves requesting a limited number of attribute values in a single query. The number of values that are requested must be less than, or equal to, the maximum number of values that are supported by the server. To reduce the number of times that the query must contact the server, the number of requested values should be as close to this maximum as possible.

Active Directory servers set a limit on the maximum number of attribute values that are returned. The version of the operating system for the server that supplies the requested data determines the maximum number of values that can be retrieved in a single query. The following table lists the operating system version and the maximum number of values that can be retrieved in a single query.

Maximum Query Size for Multivalue Attribute Searches

Note

• In the Windows Server 2003 family, a server running Windows Server 2003, Web Edition cannot be a domain controller.
  
  

Attribute range option

Linked-value attributes

The global catalog enables searches for Active Directory objects in any domain in the forest, without the need for subordinate referrals. Users can find an object of interest quickly without having to know which domain holds the object.

Global catalog servers

Searching the domain vs. searching the global catalog