|
|
One of the strengths of the Active Directory is its conformity to several important industry standards and conventions, permitting greater interoperability within a heterogeneous environment. While the interplay of the Active Directory with other directory services is far from seamless, open industry standards do provide the potential for greater information exchange among multiple operating systems. The Active Directory embraces the Domain Name System and supports the Lightweight Directory Access Protocol (LDAP). DNS resolves domain names to IP addresses in the Internet and within intranets. LDAP extends directory service interoperability by providing directory access across heterogeneous networks. One LDAP control called DirSync is used to retrieve changed information from the directory. This feature provides a method to imbue the DirSync control with the ability to perform access checks like those performed on normal LDAP searches. In addition to its support for these protocols, Active Directory uses industry-standard naming conventions, which are listed in Table 5.2.
NOTE
Active Directory also supports HTTP, which defines the methods of displaying information on a Web browser. Objects in Active Directory can be displayed as HTTP pages.
|
Standard |
Reference |
Description |
|---|---|---|
|
DNS Dynamic Update |
RFCs 2052, 2163 |
Service location (SRV) and dynamic updates |
|
Dynamic Host Configuration Protocol (DHCP) |
RFC 2131 |
Network IP address management |
|
Kerberos, v5 |
RFC 1510 |
Authentication |
|
Lightweight Directory Access Protocol (LDAP) v3 |
RFC 2251 |
Directory access |
|
LDAP 'C' |
RFC 1823 |
Directory API |
|
LDAP Schema |
RFCs 2247, 2252, 2256 |
Directory schema |
|
Simple Network Time Protocol (SNTP) |
RFC 2030 |
Distributed time services for networks (formerly 1769) |
|
Simple Mail Transfer Protocol (SMTP) |
RFC 2821 |
Message transfer (formerly 821) |
|
Transfer Control Protocol/Internet Protocol (TCP/IP) |
RFCs 791, 793 |
Network transport protocols |
|
X.509 v3 certificates |
ISO X.509 |
Authentication |
The DNS resolves names within a TCP/IP network; it translates a domain name such as EntCert.com into an IP address and vice versa. All Active Directory domain names follow the DNS naming convention, allowing easy access to the IP address of Active Directory objects that use DNS names. Windows Server 2003 DNS is a Microsoft-developed implementation and not a port of public domain software, but does follow the RFC and BIND (Berkeley Internet Name Domain) standards.
In spite of its long-time use in UNIX and other operating systems, DNS is a long way from being an automated or self-managed service. Maintenance of DNS is often viewed as a system administration burden. In most legacy environments, the system administrator labors with manual manipulation of flat text files. Most recently, the advent of the Dynamic DNS protocol has emerged to streamline the use and maintenance of this popular name locator. Windows Server 2003 bundles its own version of Dynamic DNS that tests and updates DNS registration across defined intranets and the Internet.
While Microsoft bundles its version of Dynamic DNS, other third-party versions with base-level functionality are also supported by Active Directory. By "base-level functionality," we refer to the requirement for the third-party DNS to support both Dynamic DNS and Service Resource Records (SRV RR) technology as defined by RFCs 2052 and 2136 and BIND 8.1.2. Active Directory with Dynamic DNS installed will check TCP/IP addresses across the network to make data correction and appropriate deletions. Local services are published through the SRV RR in DNS with the following structure: <service>.<protocol>.<domain>. For example, if a commercial version of sendmail were used to support the EntCert.com domain, the SRV RR would then look like this: <sendmail>.<tcp>.<EntCert.com>. Since Active Directory can support other third-party DNS programs, the actual infrastructure can take one of three basic forms:
Microsoft's own Dynamic DNS is installed and used by Active Directory.
A third-party Dynamic DNS that supports SRV RR is used by Active Directory.
Microsoft's Dynamic DNS installed as a backend via a delegated zone from the older server, thereby providing new support for SRV RR and Dynamic DNS technology features.
In addition to interoperability with DNS servers in other operating systems, Active Directory's Dynamic DNS reduces other administrative burdens. With the release of Windows NT 4.0, Microsoft integrated DNS with its Windows Internet Naming Service (WINS). In a Windows NT environment, clients may have fixed IP addresses or can be assigned an address at startup that employs the Dynamic Host Configuration Protocol (DHCP).
In many cases, UNIX-based DNS servers exist within an enterprise. A desire to maintain DNS on UNIX often prevails due to established investment and maintenance of these servers. While Windows Server 2003 supports this approach, Microsoft contends that there are a number of compelling reasons for use of the Windows OS DNS server in heterogeneous environments. The basis of the argument is the support of the latest RFC standards that may not be available with older versions of UNIX. The UNIX system can meet Active Directory DNS requirements by upgrading the BIND DNS server to version 8.1.2 or later. Support for SRV resource records is also required. Dynamic updates are desirable but not compulsory.
Where DNS servers that are not running Windows Server 2003 are to be used for the root zone, Windows DNS services should be employed to support Active Directory registration and updates. This may require modification of the other DNS namespace design. Under one scenario, you can establish a new subdomain to root the first Active Directory domain. For example, if the established root domain name is EntCert.com, the Active Directory subdomain might become win2k.EntCert.com. Another approach is to create multiple subdomains based on the second-level domain that support Active Directory registration. Both scenarios involve the delegation of the DNS namespace into additional zones.
The Active Directory's naming conventions serve a number of important purposes. First, all directories are based on the concept of a namespace, that is, a name is used to resolve the location of an object; when name resolution occurs, it converts the namespace locator to the specific object, such as a printer on the third floor. Everything hangs off the Active Directory's using the namespace to identify and locate persons, places, and things in an enterprise.
In keeping with the namespace concept, the Active Directory uses four name types to recognize every object:
The distinguished name (DN) defines the domain and related container(s) in which an object resides. It matches several defined attributes to the description—the basic attributes are Domain-Component (DC), Organizational-Unit (OU), and Common-Name (CN). For example, a representation of a printer in the EntCert.com domain and sales organizational unit, physically located on the third floor, would have the distinguished name DC=COM, DC=EntCert, OU=sales, CN=printer, CN=3rdFloorPrinter.
The relative distinguished name (RDN) is really an attribute of the object itself. In the preceding example, CN=3rdFloorPrinter is relative to its parent, CN=printer. The RDN is compared to the DN in Figure 5.13.
The globally unique identifier (GUID) avoids duplication of objects and ensures uniqueness. It is a 128-bit number assigned to an object at the time of creation and stored with it. This permits applications—for example, a word processor file with embedded graphical objects—to retrieve an updated version of a drawing by use of the GUID that is stored within the document.
The user principal name (UPN) is considered a "friendly" naming convention. It combines the user account name with the DNS domain name where the account exists. The name bob@EntCert.com is the UPN for user account bob in the EntCert.com domain tree.
Active Directory supports a number of industry standard formats to facilitate interoperability with other directory services. Microsoft's Universal Naming Convention (UNC), which takes the form \\EntCert.com\Administration\budget.doc, is the base naming convention. The Active Directory also incorporates RFC 822, which defines the common Internet e-mail naming structure of user@domainname.com. It supports the familiar HTTP URL, which takes the form http://EntCert.com/specificpage, as well. Finally, borrowing from the X.500 communication protocol, the Active Directory incorporates the LDAP URL as defined in the draft of RFC 1779, which breaks the name into very specific subunits that might look like the following: //EntCert.com/CN=myname, OU=mybranch, OU=myproduct, DN=divisionarea. The initials provide greater object specification. CN is the user's first and last names. The two hierarchical OUs distinguish the branch of the company and the specific product area. Finally, DN defines the work area, such as engineering or accounting. Under Windows Server 2003, all LDAP traffic between domain controllers and the administrative tools is now signed and encrypted by default.
The Lightweight Directory Access Protocol, defined by the Internet Engineering Task Force (IETF) RFC 2251, is a simplified version of the X.500 DAP. Microsoft's Windows Server 2003 utilizes LDAP versions 2 and 3. LDAP permits the exchange of directory data between services. For example, since Novell Directory Services data is LDAP compliant, it can be passed to and from the Active Directory.
LDAP is used to access information from compliant directory services such as the Active Directory. LDAP searches the Active Directory for information about stored objects and their attributes. It uses both distinguished names and relative distinguished names to locate the object and works closely with DNS throughout this process (Figure 5.14). DNS provides resolution to locate the appropriate Active Directory domain controller; LDAP resolves the object itself. The process follows these basic steps:
A client queries DNS for an LDAP server (Active Directory domain controller).
The client queries the domain controller for information about the object.
If the requested object is not in the domain but the domain controller knows there are child domains or a forest domain, it issues a referral to contact the other domain controllers until object resolution is achieved.
The object information is sent to the client.
LDAP's C language API (RFC 1823) permits the development of application enhancements and the building of related applications. Developing interfaces using the LDAP C API is perhaps the easiest way to provide interoperability of LDAP directory-compliant services. Existing LDAP directory service auxiliary applications that migrated to communicate with Windows Server 2003 Active Directory may not need modification. If API code changes are required as well, they are typically for the identification of objects unique to Active Directory.
In addition to the aforementioned conventions introduced in Windows 2000, the Windows Server 2003 Active Directory implementation adds a number of facilities to its LDAP support:
Active Directory now has support for dynamic store entries as defined by the Internet Engineering Task Force standard protocol RFC 2589. Entries in the directory can additionally be assigned Time-to-Live (TTL) values that determine when the entries will be automatically deleted.
Transport Layer Security (TLS) connections to Active Directory over LDAP are now protected using the IETF standard TLS security protocol (RFC 2830).
The Digest Authentication mechanism (DIGEST-MD5 SASL authentication) over an LDAP connection to Active Directory is supported (RFC 2829).
Virtual List Views (VLV) LDAP extensions as defined by the Working Group of IETF is supported.
Support for Dynamic Auxiliary classes and instances are supported.
NOTE
An extension of LDAP is its replication technology protocol LDUP (LDAP Duplication/Update Protocol), an open standards specification that is not embraced by Active Directory services. LDUP does a complete real-time replication of directory elements that requires that compliant directory services adhere to very specific rules and data structures. Violation of any rules such that a directory entry is not understood can lead to cascading errors throughout the directory. Rather than LDUP, Active Directory uses a synchronization methodology to populate and update directories.
NOTE
Microsoft did not include major portions of the X.500 protocol in the Active Directory primarily because of its dependence on an OSI networking layer and a lack of interest. The excluded elements are the Directory Access Protocol, the Directory System Protocol, the Directory Information Shadowing Protocol, and the Directory Operational Binding Management Protocol. LDAP is the most significant element of X.500 incorporated in Windows 2000 and Windows Server 2003.
 |
|
|
| Top |