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%tds 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.

AD Features

AD gives Win2K several features that differentiate the OS from NT 4.0 and make Win2K easy to use in managing large enterprises. These features include the Global Catalog, OUs, expanded groups, directory replication, and a new domain controller structure.

Global Catalog. The Global Catalog is a new concept in Win2K. The catalog is a separate index of objects in an AD forest. By default, this index contains all the objects in the full AD database but only a subset of the objects' attributes. The Global Catalog lets users quickly find directory objects across an enterprise forest, without going to the domain controller in the domain in which the object resides. The Global Catalog is most valuable if you have multiple domains and domain trees spread across a diverse network. You need at least one Global Catalog server on your network for clients to authenticate to your AD domains.

By default, the first domain controller in the first domain in your first domain tree becomes a Global Catalog server. You can use the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in to manually specify other domain controllers as Global Catalog servers. Although most domain information (e.g., users, groups) replicates only to domain controllers within the domain, AD replicates the Global Catalog across domain boundaries to all your domain controllers that are Global Catalog servers.

As you deploy Win2K, you need to place your Global Catalog servers carefully. Each client computer needs easy access to a Global Catalog to optimize the computer's ability to search the directory. In addition, the Global Catalog replaces the Global Address List (GAL) in Exchange 2000 Server (formerly code-named Platinum).

OUs. OUs let you delegate control of your Win2K domain resources. When you create an OU in your AD domain, you set up an administrative boundary within which you can delegate to a subset of users the management of objects contained in that OU. As I mentioned previously, OUs can contain other OUs or leaf objects such as users, computers, or printers. You can nest any number of OUs within other OUs, but to be practical, you'll want to limit your domain to 10 or fewer nested OUs. You can use the MMC Active Directory Users and Computers snap-in to create nested OUs.

Screen 1, page 66, shows a domain with three nested OUs. The OU called US contains the California OU, which in turn contains the Finance OU. In the Finance OU is a user object called Joe User. Suppose Joe User is the local administrator for the Finance department in California. You could use the Active Directory Users and Computers snap-in's Delegation of Control Wizard to delegate control of the Finance OU for all objects within that OU to Joe User. To start this wizard, you simply right-click the OU and select Delegate Control. Then, you select the user or group you're delegating OU control to and specify the rights the user or group will have over the objects in the OU.

Screen 2 shows the predefined delegation tasks you can assign via the wizard. Alternatively, you can select Custom task to assign rights from a comprehensive list. The rights you can assign correspond to security ACLs on the OU objects to which you've delegated control. You can manually edit the ACLs on an OU, user, or group to assign security rights on a per-object basis, but the Delegation of Control Wizard gives you a simple GUI for delegating control.

Win2K groups. NT 4.0 has only two groups: global and local. These groups exist solely for security purposes (i.e., to assign security to resources), and the groups can contain only user objects. Win2K has global and domain local groups, as well as a new security group called the universal group. Universal groups are available when you switch your AD domains from mixed mode to native mode. In mixed-mode operation, a Win2K domain can contain Win2K domain controllers and NT 4.0 BDCs. In native mode, your domains can't contain NT 4.0 BDCs. Switching to native mode is a one-way function: You can't switch back. Universal groups can contain global groups and other universal groups from any domain in your forest. Conversely, global groups are domain-specific—a global group contains users, computers, or other global groups only from within the same domain. Of course, global groups from one domain can be members of local groups in another domain. Universal groups also let you nest global and universal groups from other domains in your forest. You can create security groups that contain machine objects in Win2K. Thus, you can set permissions on resources, using groups based on machines rather than just users.

Win2K lets you create nonsecurity groups called distribution groups, which have similar scope (i.e., local, global, and universal) to security groups. These groups function like distribution lists (DLs): The groups have no security context but let you group users for purposes such as email.

Directory replication. Win2K uses a new replication model to ensure that all domain controllers in a forest have up-to-date information. This model is based on the concept of multimaster replication. In NT 4.0, only the PDC keeps a read-write copy of the SAM. In Win2K, every domain controller in a domain contains a read-write copy of the DIT. Users can make changes at any domain controller, and those changes replicate to the other domain controllers. Win2K uses a feature called the update sequence number (USN) to determine whether changes need to replicate from one domain controller to another. Every object and object property in the AD contains a USN, and the domain controllers use this number to determine when changes occur on a replication partner. During a replication cycle, changes (not the whole object) replicate on a per-property basis. For example, if a user object's phone number changes on domain controller 1, only the new phone number—not the whole user object—replicates to domain controller 2. If a change to one property occurs on two domain controllers, the timestamp helps ensure that the last change takes effect.

Domain controllers in a forest use three replication naming contexts to replicate domain and AD information. You can think of naming contexts as paths that replicated information takes. Each naming context can take a different path between domain controllers in a forest, and each naming context replicates different information, depending on the information's role. The domain naming context replicates DIT changes to domain controllers within one domain, the schema naming context replicates schema information to all domain controllers within a forest, and the configuration naming context replicates configuration information such as replication topology to all domain controllers in a forest.

AD uses sites to let you control replication traffic between locations with slow WAN links (i.e., slower than T1). AD sites, like Exchange Server sites, are areas of high network bandwidth. Within a site, the Knowledge Consistency Checker (KCC) process running on each domain controller automatically generates domain controller replication topology for each of the naming contexts. The KCC creates a ring topology between the domain controllers in the site. As the number of domain controllers increases, the KCC adds connection objects between domain controllers to prevent excessive hops between any two domain controllers. You can manually schedule replication frequency across sites depending on your network needs.

You must use the MMC Active Directory Sites and Services snap-in to define sites manually. You also need to create subnet objects that correspond to all the TCP/IP subnets on your network and associate these subnets with the appropriate sites. Workstations use this information to locate the closest domain controller for authentication purposes because they prefer to use a domain controller within the site before randomly querying DNS for other available domain controllers.

Domain controller structure. In NT 4.0, the PDC is a single point of change for the SAM, as well as a single point of failure. As I mentioned previously, Win2K doesn't require the PDC for SAM changes because the OS supports AD multimaster replication. However, the PDC role still exists. Win2K forests require the following five Operations Master roles on domain controllers: PDC, Relative Identifier (RID) Pool, Infrastructure, Domain Naming, and Schema. (Microsoft previously referred to Operations Master roles as flexible—or floating—single-master operations—FSMO.)

The PDC, RID Pool, and Infrastructure Operations Master roles must reside on at least one domain controller per domain. If the server holding a particular role goes down, you need to manually promote another domain controller to the role. The PDC role is intuitive: When you have downlevel NT 4.0 BDCs and clients, the Win2K domain controller serving in the PDC role is the PDC for the domain. The RID Pool role refers to the RID value in a user's SID. Because Win2K lets any domain controller make changes to the directory, the OS needs a method for coordinating RID assignment to new objects. The RID Pool Operations Master performs this role. The Infrastructure role is a process that maintains interdomain consistency between objects that replicate across domain boundaries (e.g., the Global Catalog, site configuration, replication connections).

The Domain Naming and Schema Operations Master roles reside on at least one domain controller in a forest. The Domain Naming role guarantees domain name uniqueness within a forest as you add new domains. The Schema role defines which domain controller can make directory schema changes, because letting multiple domain controllers make schema changes to the directory can cause problems.

AD Migration

The simplest AD migration method is to upgrade your NT 4.0 domains in place, meaning that you upgrade the PDC in your first master domain. After you upgrade that PDC, the first domain operates in mixed mode: Your Win2K domain controllers host the AD but look like NT 4.0 domain controllers to your remaining NT 4.0 devices. As soon as you upgrade the first PDC to Win2K, all your Win2K workstations and servers can take advantage of certain AD features (e.g., OUs, Group Policies) without affecting your remaining NT 4.0 devices. Each subsequent NT 4.0 domain that you upgrade becomes part of the forest you created when you upgraded the first domain. If you have resource domains, you need to upgrade those domains; then you can move the resources into OUs in another existing domain—thereby reducing your total domains. (With OUs, you no longer need resource domains.) After you migrate all your domains to Win2K, you can use third-party tools or Microsoft Windows NT Server 4.0 Resource Kit utilities to consolidate your domains to meet your administrative and organizational needs.

Another AD migration method is to build your Win2K infrastructure from scratch and use third-party tools (e.g., FastLane Technologies' DM/Manager, Entevo's DirectMigrate 2000, Mission Critical Software's OnePoint Domain Administrator) or resource kit utilities (e.g., SID history cloning scripts) to migrate groups of users at once. This conservative approach gives you an organized method for upgrading users and computers to Win2K without resorting to the in-place all-or-nothing approach. Starting from scratch avoids the problem of dealing with the legacy of your existing NT infrastructure as you try to move forward. In addition, this alternative strategy provides a back-out option because the third-party tools and resource kit utilities can recreate or clone NT 4.0 objects into a Win2K forest while leaving the existing NT 4.0 objects intact.

AD to the Rescue

Microsoft is finally giving NT a directory service to rival the services Novell and Banyan have been providing for years. AD's features such as the Global Catalog, OUs, new user and computer groups, directory replication, and a new domain controller structure make managing your NT resources easier than ever. Although AD still has some kinks, I think the final product will be a comprehensive directory implementation. In addition, I see AD eventually becoming a true directory service, with vendors writing line-of-business applications to take advantage of the service. Exchange 2000 is one of the first large applications to leverage AD's extensible nature—using AD as its sole directory service for messaging. In addition, Microsoft's recent acquisition of ZOOMIT will likely provide momentum to make AD a player in the metadirectory marketplace. Perhaps Microsoft's overwhelming presence in the IT marketplace will finally provide the momentum necessary to legitimize directory services as a true applications platform.