Active Directory Data Storage
Active Directory Data Storage |
|
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
| API Name | Description |
|---|---|
| LDAP C API | As described in RFC 1823 for LDAPv3, LDAP API is a C language API to the LDAP network protocol. |
| ADSI | COM interface to Active Directory that abstracts the details of LDAP communications. ADSI provides services and Active Directory information to directory-aware applications. ADSI supports multiple programming languages, including Microsoft® Visual Basic®, C, and Microsoft® Visual C++®. ADSI also can be accessed by using Windows Script Host (WSH). |
| MAPI | Messaging API that is supported for compatibility with Microsoft® Exchange Client and Outlook Address Book client applications. |
| Windows NT 4.0 | Windows NT 4.0 networking APIs (Net APIs) that are used by Windows NT 4.0 clients to gain access to Active Directory through SAM. |
| SAM | APIs that communicate with the DSA 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
| Access Method | Description |
|---|---|
| LDAP | Core protocol that is supported by Active Directory, as described in RFC 2251 (LDAPv3) and RFC 1777 (LDAPv2). |
| MAPI RPC | RPC interfaces used by MAPI Address Book provider |
| Replication RPC | RPC interfaces used by Active Directory replication over IP transport for replication within sites and between sites. |
| Replication Simple Mail Transfer Protocol (SMTP) | Replication protocol used by Active Directory replication over IP transport for message-based replication between sites only. |
For more information about RPC, see "Windows 2000 Network Architecture" in the TCP/IP Core Networking Guide.
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 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.
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.
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:
For more information about the LDAPv3 protocol, see the Request for Comments (RFC) link on the Web Resources page at http://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 ("
LDAPv3 supports the following implementations that were not supported in LDAPv2:
LDAPv3 is backward compatible with LDAPv2. A requirement of an LDAPv3 server is that an LDAPv2 client be able to connect to it.
Unlike most other Internet protocols, the LDAP protocol has an associated API that simplifies writing Internet directory service applications. LDAP API is
Microsoft implements the LDAP API in Wldap32.dll — also referred to as "LDAP C" or
For more information about the LDAP API and about programming in LDAP, see the Microsoft Platform SDK link on the Web Resources page at http://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.
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.
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:
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 http://windows.microsoft.com/windows2000/reskit/webresources.
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:
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.
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 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.
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.
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
