Functional Model

The functional model describes the operations that can be conducted with information stored in a directory using the LDAP protocol. You need to be able to access information, and read and update it as well. These operations are implemented in somewhat different ways for various system tools that use the LDAP protocol, but the main concepts and parameters remain the same.

Authentication

Authentication operations allow a user to establish a connection with a Directory System Agent (DSA) and to get the right to access the stored information.

• Open — this command creates and initializes a connection block, and then opens a connection to the DSA.

• Bind — this command initiates a protocol session to the DSA and authenticates the client to the DSA.

• Unbind — this command terminates a session, frees all resources associated with the session, and closes a connection.

Interrogation

Interrogation methods describe ways of retrieving information.

Search

The widely used search operations retrieve information based on user criteria. Search operations have the following parameters:

• Search base — the distinguished name of a directory object (called the base object) from which the search begins (e.g., DC=net, DC=dom or OU=Stuff, DC=net, DC=dom).

  Note 

  All search parameters are mandatory. Many LDAP-compatible tools and utilities, such as DsQuery, LDIFDE, Search.vbs, and so on, do not require that users specify some parameters. However, this only means that these tools themselves substitute some default values instead of the missed parameters.

  Note 

  The search base can also have the "<GUID=…>" format (the angle brackets are included!) (e.g., "<GUID=0855ae368790cb4b8726cf37cb2222a5>").

• Search scope — defines the depth of searching relative to the search base (Fig. 1.1 shows various scopes for the domain object). There are three options:

• Base. Only the base object is searched (i.e., you will work with properties of the base object only).

• One level. The children of the base object are searched; the base object itself and grandchildren are excluded.

• Subtree. The entire subtree is searched, beginning with and including the base object (i.e., all "visible" objects in the subtree).

• Filter. A rule (see RFC 2254) for selecting objects from a subtree (e.g., (cn=*) or & (objectCategory=Person) (cn=d*) ).

• Selection. A list of attributes returned from the selected objects that match the filter.

• Optional controls. LDAP functions that extend or modify a LDAP operation; for example, you may ask the LDAP server to sort the results or return a large result set in small pages. (See examples of using some LDAP controls in Chapter 12, "Manipulating Active Directory Objects.")

Figure 1.1: Search scopes for a domain object (which is the search base)

Types of Filters

The following table shows a few examples of search filters:

Condition	Filter
Equality match	(sAMAccountName=jsmith)
Partial match	(name=s*) or (name=*s*)
Comparing with a value	(uSNChanged>=10000) or (CN<=Sales)
Presence of object	(objectClass=*)
Logical AND of two conditions (users with names that begin with "H")	(& (objectClass=user) (cn>=h))
Logical OR of two conditions (objects with names that begin with "A" OR "H")	(|(cn=a*) (cn=h*))
Logical NOT (all users with name that begin with "A" except "Administrators")	(& (objectClass=user) (cn=a*) (! (cn=adm*)))
Binary (attributes with syntax 2.5.4.1)	(attributeSyntax=\32\2e\35\2e\34\2e\31)

Selection Options

Usually, you provide the list of object attributes returned by a query. There are, however, a few special cases:

• If you only need the objects' DNs rather than their attributes, specify OID 1.1 as the selection.

• It is possible to specify the attribute OID instead of its name; for example, you can replace objectClass with 2.5.4.0.

Example. Listing Attributes replicated to Global Catalog

As an example of a search operation, let us consider how to view all attributes replicated to Global Catalog. You may use any search tool, such as the Search.vbs script or the Ldp.exe utility. (For more information, see Chapter 12.) Here is a sample command:

     search "LDAP: //CN=Schema, CN=Configuration, DC=net, DC=dom"      /C:" (& (objectClass=attributeSchema)      (isMemberOfPartialAttributeSet=*))"      /P: ADsPath, attributeID, attributeSyntax, isSingleValued,      lDAPDisplayName, oMSyntax 

The query produces a result similar to the following (only one entry from the list is shown):

     ...     ADsPAth 140 = LDAP://CN=User-Principal-Name,CN=Schema,      CN=Configuration, DC=net, DC=dom     attributeID 140 = 1.2.840.113556.1.4.656     attributeSyntax 140 = 2.5.5.12     isSingleValued 140 = True     lDAPDisplayName 140 = userPrincipalName     oMSyntax 140 = 64     ... 

The same results can be obtained with the DsQuery utility:

     C:\>dsquery * "CN=Schema, CN=Configuration, DC=net, DC=dom"      -filter      "(&(objectClass=attributeSchema) (isMemberOfPartialAttributeSet=*))"      -attr ADsPath attributeID attributeSyntax isSingleValued      lDAPDisplayName oMSyntax -1 -limit 1000 | more 

Compare

The compare operation returns a Boolean result (TRUE or FALSE) based on the comparison of an attribute value with a specified value.

Administrative Limits and Query Policy

The LDAP server resources, which are available to clients that make LDAP queries and request paged or sorted result sets, are limited by the Default Query Policy. Administrative limits constitute the query policy objects which are stored in the container CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services in the Configuration partition.

If there are no assigned policies, all domain controllers use the default query policy. A site policy can also be assigned. However, if a specific policy has been assigned to a domain controller, this policy overrides all others. There is no UI for assigning a policy to a site. You can do this by manually editing the queryPolicyObject attribute of the NTDS Site Settings object of the nTDSSiteSettings class object. Use the ADSI Edit snap-in. It is also possible to use the ModifyLDAP.vbs script (see below).

Query policy applies to the following LDAP query-related operations:

• Search. By default, you cannot obtain a result set whose size exceeds 1000 rows. You need to use a paged search to perform operations that generate a significant amount of information. Also, you may exceed the default timeout set for search operations.

• Paged search. The client may ask the server to hold the result set and return it in pages. In this case, the query policy defines the page size. (See also comments to Listing 16.1.)

• Search with Sorted Results. The requested result set can be sorted in a particular order. This operation can significantly overload the LDAP server.

• Search with Replication. The client can specify the maximum number of attribute values that can be returned per request.

• Change Notify. The client can request change notification in an asynchronous LDAP query. The query policy can limit the number of simultaneous asynchronous requests.

Tools for Manipulating LDAP Query Policies

There are two standard tools that allow you to work with LDAP query policies (see Chapter 10, "Diagnosing and Maintaining Domain Controllers"):

• The NTDSutil.exe tool. This tool can only be used with the Default Query Policy object. It allows you to view or modify the query policy of a domain controller.

• The ModifyLDAP.vbs script from the Windows 2000 Server Resource Kit. This script can create, delete, assign, or modify the query policy objects.

Update

The update operations perform modifications of the stored information.

• Add allows user to create an object, which must meet the schema requirements for the object class.

• Modify creates, modifies, and deletes attributes of an object.

• Modify RDN is actually an operation of renaming or moving an object to another location.

• Delete deletes an object (if it is possible and the user has the appropriate rights to the object).