Active Directory in Windows 2000

Windows 2000's (Win2K's) most anticipated new feature is the Active Directory—AD. (For information about other new features in Win2K and a glossary of Win2K terms, see Mark Minasi, "Windows 2000 Overview," page 60.) AD takes enterprise Windows NT resource management out of the dark ages: The service eliminates master domains and resource domains, all-or-nothing administrator accounts that wreak havoc on a domain, and the numerous (i.e., N x [N - 1]) trust relationships that you must establish every time you add a domain. To use AD effectively, you need to understand why a directory service is important, how AD works, which features the service provides, and how to troubleshoot migration problems.

Directory Services
A directory service is a distributed repository of information or pointers to information (e.g., users, groups, resources). After you establish such a repository, you can build various applications against it. For example, you can build simple applications such as a White Pages directory of people and their associated properties, or complex applications to manage a network operating system (NOS). Like Novell Directory Services (NDS) and Banyan's StreetTalk directory services, AD provides a directory of NOS-specific objects that lets you manage not only users and their properties but also many kinds of NT-specific features such as Dfs volumes, Group Policy Objects (GPOs), and public key infrastructure (PKI). The types of objects a directory can contain are virtually limitless. However, you must consider performance and replication implications.

The International Organization for Standardization (ISO)-based X.500 protocol is probably the most well-known directory services standard. X.500 specifies a default schema that describes classes of objects and their associated attributes. X.500-based directories have several features in common. The most important feature of X.500-based directories is the organizational unit (OU). The OU is referred to as a container object in the directory because the OU can contain other objects—either leaf objects or other container objects. Because X.500-based directories let you create objects that contain other objects, these directories can support hierarchical relationships. Thus, you can create trees of OUs, with each tree subordinate to the previous one. This powerful AD feature lets you delegate administrative duties to subsets of users in a Win2K domain. The OU provides granular delegation control of domain resources. In Win2K, the OU is the unit of delegation, whereas in NT 4.0, the domain is the unit of delegation.

Another key part of a directory service is the schema, which is the directory's internal structure. The schema defines the relationships between classes of objects. Each class of objects has an associated set of attributes. For example, the class called Person might have an attribute called First Name, which specifies that objects in the Person class contain First Name information. As in an object-oriented model, classes inherit from other classes, forming a hierarchy of classes. AD's schema is extensible. Thus, you can modify the schema to create new classes and new attributes within existing classes.

AD Infrastructure
When Microsoft developed AD, the company had to provide backward compatibility with NT 4.0 environments. Therefore, many AD concepts will seem familiar to you.

Domains. In Win2K, security policies are still bounded by the domain, and Domain Admins groups still exist. However, AD domains no longer use the 15-character NetBIOS naming standard. Although AD domains have NetBIOS names for backward compatibility, Win2K devices recognize AD domains by their DNS names. Win2K's default name service is DNS, and all AD domains have a DNS domain to identify them (e.g., mycompany.com).

In NT 4.0, you can have only two levels of hierarchy between domains because trust relationships aren't transitive. For example, suppose you have three NT 4.0 domains—A, B, and C— and you want domains B and C to trust domain A, and domain C to trust domain B. You can build a trust between domains B and A and between domains C and A, but you must build an explicit trust from domain C to domain B. Win2K eliminates this restriction. Microsoft's use of Kerberos 5 as Win2K's default authentication protocol means that trust relationships can be two-way and transitive. Thus, you can have many levels of domain hierarchy. For example, domain A can trust domain B, which trusts domain C, and so on.

Domain trees and forests. A domain tree is a set of domains that trust one another and that belong to one contiguous namespace (i.e., a directory tree in which each domain is a subdomain of its parent domain). An example of a contiguous namespace is a domain tree with the domain mycompany.com at the root, a child domain under mycompany.com called east.mycompany .com, and a child domain under east.mycompany.com called finance .east.mycompany.com. In the example, the three domains form a contiguous namespace and therefore a domain tree.

A forest is one domain tree or a set of domain trees that have separate contiguous namespaces. At the root of each domain tree, Kerberos trusts link the trees. Figure 1 shows the relationship between domains and domain trees in an AD forest. When you install the first domain controller to the first domain in the first domain tree in your environment, you must specify whether the domain controller is part of a new or existing forest. In AD, all the domains in a forest must share one schema. Win2K doesn't let you merge multiple forests or schemas. Thus, if you need to create multiple forests (e.g., if your company merges with a company that already has an AD forest), you must use explicit downlevel, nontransitive trust relationships to link the forests. Alternatively, you can use tools to move objects from one forest to another. Until Microsoft or a third-party vendor develops a tool to manage multiple forests in the enterprise, you'll want to maintain as few forests as possible.

Directory Information Tree (DIT). In NT 4.0, the Security Accounts Manager (SAM) database holds all the user, computer, and group information for a domain. Because the SAM is a Registry hive, the Registry's scalability limits the SAM. On Win2K domain controllers, the DIT replaces the SAM. The DIT is based on Microsoft's Jet database engine and is similar to the Jet engine that Microsoft Exchange Server uses. The file ntds.dit, in the \%systemroot%\ntds directory, is the Win2K equivalent of the SAM file. This file stores the bulk of the directory database. In general, the DIT is larger than the SAM because AD holds more information and types of objects than NT 4.0's directory service holds. Within a domain, the contents of the ntds.dit file replicate to all the domain controllers. You might think that you'll see more replication traffic between domain controllers when you migrate from NT 4.0 to Win2K. However, Win2K uses a completely different model for replicating directory changes than NT 4.0 uses.

   Previous  [1]  2  Next