Protocols and Interfaces to Active Directory

The diagram of the Active Directory architecture (Figure 2.3) illustrates four avenues of entry to Active Directory: LDAP/ADSI, REPL (replication), SAM, and MAPI. Each of these access routes uses a different set of protocols and APIs that enable communication with the directory service. Table 2.1 shows the APIs that Active Directory supports and that can be used by developers to integrate with Active Directory or use resources in Active Directory.

Table   2.1 Active Directory APIs

These APIs communicate with Active Directory by using various access methods, as described in Table 2.2.

Table   2.2 Active Directory Access Methods

For more information about RPC, see "Windows 2000 Network Architecture" in the TCP/IP Core Networking Guide .

LDAP

LDAP is both a protocol and an API. It is also associated with both a directory service model that defines client/server mechanisms and an information model that defines the nature of objects stored in an LDAP directory service.

The LDAP protocol is the Active Directory core protocol, which means that LDAP is the only wire protocol that is supported by Active Directory. LDAP is the preferred and most common way of interacting with Active Directory. The LDAP API provides access to the LDAP protocol, and ADSI is the COM interface to Active Directory that uses LDAP as the protocol.

Note

LDAP is a wire protocol , which means that it manages the encapsulation and sending of requests between a client and server.

LDAP Protocol

LDAP is a directory service protocol that specifies directory communications. It runs directly over Transmission Control Protocol/Internet Protocol (TCP/IP) and can also run over user datagram protocol (UDP) connectionless transports. LDAP enables clients to query, create, update, and delete information stored in a directory service over a TCP connection through the TCP default port 389. LDAP was used initially as a front end to X.500 directories. LDAPv3 is an industry standard that can be used with any directory service, such as Active Directory, that implements the LDAP protocol. Active Directory supports LDAPv2 (RFC 1777) and LDAPv3 (RFC 2251).

Note

Windows 2000 Active Directory does not implement the X.500 protocols (which include Directory Access Protocol [DAP], Directory System Protocol [DSP], Directory Information Shadowing Protocol [DISP], and Directory Operational Binding Management Protocol [DOP]). LDAP provides the most important functions offered by DAP, and is designed to work over TCP/IP without the overhead of "enveloping" OSI protocols over TCP/IP.

For more information about TCP/IP, see the TCP/IP Core Networking Guide .

LDAP Directory Service Model

The LDAP directory service is based on a client/server model. One or more LDAP servers contain the data making up the directory tree An LDAP client connects to an LDAP server and requests information or performs an operation. The server performs the operation or provides the information, or it refers the client to another LDAP server that might be able to do so. When connecting to a specific LDAP directory tree, it does not matter what LDAP server a client connects to; a name presented to one LDAP server references the same object (referred to as an entry in LDAP) that it would reference at another LDAP server. This is an important feature of a global directory service.

LDAP Information Model

The LDAP information model is based on the entry, which contains information about some object (for example, a person or computer). In Active Directory, an LDAP entry is referred to as an object. Entries are composed of attributes, which have a type and one or more values. Each attribute has a syntax that determines what kind of values are allowed in the attribute. Examples of attribute syntaxes are Unicode string, binary, and integer.

The following key aspects characterize the LDAP protocol:

• The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and UDP for connectionless transport (no acknowledgment on sending or receiving data).

• Most protocol data elements can be encoded as ordinary strings (for example, distinguished names).

• Referrals to other servers can be returned to the client.

• Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP to provide associated security services.

• Attribute values and distinguished names can be internationalized through the use of the International Standards Organization (ISO) 10646 character set.

• The protocol can be extended to support new operations, and controls can be used to extend existing operations.

• The schema is published through an attribute on the root object (rootDSE) for use by clients. (For more information about the schema, see "Active Directory Schema" in this book. For more information about rootDSE, see "RootDSE" later in this chapter.)

For more information about the LDAPv3 protocol, see the Request for Comments (RFC) link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources . Follow the links to RFC 2251 ("Lightweight Directory Access Protocol (v3)," the original LDAPv3 description), RFC 2252 ("Attribute Syntax Definitions"), RFC 2253 ("UTF-8 String Representation of Distinguished Names"), RFC 2254 ("The String Representation of LDAP Search Filters"), RFC 2255 ("The LDAP URL Format"), RFC 2256 ("A Summary of the X.500[96] User Schema for Use with LDAPv3"), and RFC 2247 ("Using Domains in LDAP/X.500 Distinguished Names"). For more information about the LDAP RFCs, see "LDAP Requests for Comments" in this book.

Differences Between LDAPv2 and LDAPv3

LDAPv3 supports the following implementations that were not supported in LDAPv2:

• The use of UTF-8 for all text string attributes to support extended character sets. Active Directory sends all responses in UTF-8 encoded form.

• Operational attributes that the directory maintains for its own use (for example, to log the date and time when another attribute is modified).

• Referrals, which allow a server to direct a client to another server that might have the information the client is requesting. An LDAP server can return a referral to an LDAP client when the operation presented by the client cannot be serviced locally and the LDAP server has knowledge of other LDAP servers that can handle the operation.

• Schema publishing with the directory, which allows a client to discover what object classes and attributes a server supports.

• Extended searching operations that allow paging and sorting of results and client-defined searching and sorting controls.

• Stronger security through an SASL-based authentication mechanism.

• Extended operations, which provide additional functionality without changing the protocol version.

LDAPv3 is backward compatible with LDAPv2. A requirement of an LDAPv3 server is that an LDAPv2 client be able to connect to it.

LDAP API

Unlike most other Internet protocols, the LDAP protocol has an associated API that simplifies writing Internet directory service applications. LDAP API is a C-language API to the LDAP protocol. RFC 1823 specifies the LDAP APIs that are required for a client to gain access to a directory service that supports the LDAP protocol. This API set is relatively simple and supports both synchronous and asynchronous calls to the server.

Microsoft implements the LDAP API in Wldap32.dll — also referred to as "LDAP C" or "C-binding LDAP." Applications that are written in LDAP are compatible only with LDAP directory services. ADSI, which provides a COM interface to Active Directory, is layered on top of LDAP and provides the easiest access to Active Directory through LDAP. However, Active Directory also fully supports the LDAP APIs for directory access.

For more information about the LDAP API and about programming in LDAP, see the Microsoft Platform SDK link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources . For more information about LDAP referrals, see "Name Resolution in Active Directory" in this book. For more information about the schema, see "Active Directory Schema" in this book.

ADSI

The primary and recommended API for Active Directory is ADSI. ADSI enables access to Active Directory by exposing objects stored in the directory as COM objects. A directory object is manipulated using the methods on one or more COM interfaces. ADSI providers contain the implementation of ADSI objects for a particular namespace. By implementing the required interfaces, ADSI providers translate these interfaces to the API calls of a particular directory service.

ADSI LDAP Provider

The ADSI LDAP provider operates on the ADSI client to provide access to Active Directory or to other LDAP directory services. The ADSI LDAP provider works with any LDAP server that supports at least LDAPv2. In addition to Windows 2000 Active Directory, directory services that are accessible through the LDAP provider include the following:

• Netscape Directory Server.

• Exchange Server 5. x .

• Microsoft Commercial Internet System (MCIS) Address Book Server.

• University of Michigan Stand-alone LDAP Directory (SLAPD) Server.

• Other Internet directory servers (for example, Ldap.yahoo.com).

Note

The WinNT ADSI provider enables access to Microsoft® Windows NT® version 3. x and Windows NT 4.0 directories, providing for communication with Windows NT 4.0 primary domain controllers and backup domain controllers. Other providers include NDS for access to Novell Directory Services directories, NWCOMPAT for access to Novell NetWare 3. x and Novell NetWare 4. x directories, and IIS for access to HTTP data directories used by Internet Information Services (IIS).

For more information about ADSI, see the Microsoft Platform SDK link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

Active Directory Replication

Active Directory replication is performed over replication transport protocols, which are represented in the Active Directory architecture diagram (Figure 2.3) as REPL. For replication within a site Active Directory replication uses RPC-over-IP transport protocols. For replication between sites, Active Directory replication uses two replication transport protocols: IP (RPC over IP) and Simple Mail Transfer Protocol (SMTP over IP).

Note

The user interface that is associated with connection properties in Active Directory Sites and Services displays RPC for all connections within a site, and displays either IP (for RPC over IP) or SMTP (for SMTP over IP) for connections between sites. This convention is used to distinguish between RPC over IP for connections that are between sites and those that are within a site.

RPC replication between sites can be scheduled and is compressed. For replication within a site, RPC is always used. RPC replication within a site is not compressed. Thus, Windows 2000 directory replication recognizes three degrees of connectivity:

• Uniform, high-speed connectivity (RPC over IP for replication of all directory partitions within a site).

• Point-to-point, synchronous, low-speed connectivity (RPC over IP for replication of all directory partitions between sites).

• Mail-only, asynchronous connectivity (SMTP over IP for replication of only non-domain directory partitions between sites).

On each DSA, replication uses a single thread to receive changes from other servers and applies them locally by using either RPC synchronous transport or asynchronous transport for messaging between sites. The choice of transport is determined by the corresponding connection object (class nTDSConnection ). Connection objects are created automatically by the Knowledge Consistency Checker (KCC) You can also create connection objects manually by using Active Directory Sites and Services. Both synchronous and asynchronous transports operate on a request-response basis.

For more information about Active Directory replication, see "Active Directory Replication" in this book.

MAPI

Messaging clients gain access to the Exchange Server directory service by using MAPI address book providers. For compatibility with existing messaging clients, Active Directory supports the MAPI-RPC address book provider, which allows access to Active Directory (for example, to find the telephone number of a user).

Note

In Windows 2000, the MAPI address book provider is provided solely for backward compatibility with MAPI clients, such as Outlook.

SAM

SAM is a protected subsystem that manages user and group account information. In Windows 2000, workstation security accounts are stored by SAM in the local computer registry, and domain controller security accounts are stored in Active Directory. In Windows NT 4.0, both local and domain security accounts are stored in the registry.

Using SAM in Mixed Mode and Native Mode

Windows 2000 supports Win32 security APIs in both mixed mode and native mode.

In mixed-mode domains, where Windows NT 4.0–based backup domain controllers are still in use, SAM clients that run Microsoft® Windows NT® version 3.51 or Windows NT 4.0 communicate with the SAM server through SAM APIs, which are required for replication and for authentication against the SAM database.

In native-mode domains, there are no Windows NT 4.0 domain controllers, but there can be clients that run Windows 95, Windows 98, Windows NT 3. x , or Windows NT 4.0. These clients continue to authenticate by using the same SAM APIs.

SAM Client and Server Operations

Most SAM operations are structured as reads and writes of properties. For workstation accounts, operations are reads from and writes to the registry. Domain-account operations are performed on Active Directory objects and their corresponding properties, which are stored as column values in the directory database. The SAM client calls public SAM routines, which in turn call internal routines that encapsulate the RPC. On the server side, the internal SAM routines do the bulk of the work.

In Windows NT 4.0, all access to account information is accomplished through internal SAM routine calls to the accounts database that is stored in the registry. In Windows 2000, the SAM server effectively splits off the domain controller account information from the workstation account information and places it in Active Directory instead of in the registry. The logic in Samsrv.dll manages the security principal database differently, depending on the role of the computer. On a domain controller, Samsrv.dll uses Active Directory for security principal storage. On all other Windows 2000–based computers, Samsrv.dll uses the SAM database in the registry for storage.

Gaining access to Windows 2000 domain controller account information is accomplished by routines that are implemented as part of the DSA process on the server. These routines are called in-process on the server and offer the ability to search for, read, and write directory service objects.

Figure 2.4 illustrates the interactions between the SAM client and server processes and the storage of domain and local accounts. The SAM server depicts the logic applied by Samsrv.dll in the domain controller case (Directory API), where the accounts are domain accounts, and in all other cases (Registry API), where the accounts are local to the computer.

Figure 2.4 SAM Client and Server Interactions and Account Storage