A Dedicated Forest Root

[Editor's Note: This article is based on a white paper published by Lucent Technologies NetworkCare Professional Services at http://www.ins.com/knowledge/whitepapers/win2kad.asp.]

Windows 2000 offers a significant amount of new functionality and design flexibility. However, these benefits come at a price: Network design complexity has increased considerably.

Most users were content to let Windows NT grow somewhat organically in their organizations, creating domains for various reasons. If a department or group of users needed the resources of an NT domain, administrators created one for them. During this early time of NT adoption, users didn't really need to share domain resources across the enterprise. As time went on, however, the NT structure grew, and users started to require access to resources in other domains. Microsoft answered this need by giving domains the ability to trust one another. A user in marketing could access resources in a human resources (HR) domain without needing to have an account in that domain.

The new model worked well for a time, but creating manual trusts between domains can get fairly cumbersome. In addition, the pendulum began to swing back from a more distributed IT function toward a centralized IT department. Microsoft decided to address this shift in Win2K with Active Directory (AD). Domains in an organization are part of a larger unit called a forest. Within a forest, AD automatically creates and maintains bidirectional transitive trusts between domains, and a centralized administration group controls all domains.

Creating an optimal AD design is a challenging task. During the planning process, AD architects must balance business and technical considerations to develop a design that reflects an organization's unique requirements. Architects can choose from many design techniques in an effort to provide additional levels of security, administrative access control, and architectural flexibility. One useful technique is the dedicated forest root.

The Dedicated Forest Root
The root domain is the first domain installed in a forest. Because it's the foundation of an AD structure, the root domain has certain functions and abilities that set it apart from all the other domains in the forest. For example, the root domain contains two security groups, the Schema Administrators group and the Enterprise Administrators group, that don't exist in any other domains in the AD forest. Both of these groups can make forestwide changes, such as adding new domains to the forest or changing the forest schema.

A dedicated forest root is a root domain that contains only the default, built-in administrative accounts and groups; it doesn't contain user or computer accounts. A dedicated forest root and a root domain are the same except that with a dedicated forest root, the administrator has chosen not to place user and computer accounts in the root. Instead, the administrator places user, group, and computer accounts in other domains in the AD forest.

A dedicated forest root is intended to enhance the security and flexibility of an AD design, as well as alleviate some potential political problems. However, you shouldn't expect it to completely solve the most significant political challenge: the fact that previously autonomous IT organizations must cede the Enterprise Administrators role to the centralized IT organization. The benefits of a dedicated forest root are

Improved Schema Security
As we mentioned earlier, the root domain houses two unique security groups that can modify several important forestwide settings. One of these groups is the Schema Administrators group, which controls the AD schema.

The AD schema is a data store that contains definitions of object classes and their attributes. An object class defines all the properties that you can associate with a particular object. For example, the user jsmith is an object. The logon name, full name, description, and password are all attributes of the jsmith user object. The object class user contains the listing of all the possible attributes that you can associate with a user object.

AD has an extensible schema, which means that organizations can modify the schema to suit their requirements. For example, you can add new attributes to an object class. Many companies, for instance, assign an identification number to their employees. A company could extend the existing schema to add an HR ID attribute to the user object class.

By default, Win2K installs AD with approximately 120 object classes and about 800 attributes. However, many directory-enabled applications add new object classes and attributes to the schema. For example, Microsoft Exchange 2000 Server adds approximately 150 object classes and more than 800 additional attributes. As attributes become populated, the amount of replication traffic traversing the network grows. In addition, if you change the schema, you can deactivate the alteration, but you can't remove it. For these reasons, you must plan and execute schema changes with the utmost care.

Organizations, especially large multidivisional companies, will want to maintain tight control over schema changes. The dedicated forest root provides a mechanism to help you achieve such control. To modify the schema, a user must be a member of the Schema Administrators group, which resides in the root domain. By default, only members of the Enterprise Administrators group and members of the root domain's Domain Administrators group can add users to the Schema Administrators group. Separating these three administrative groups into their own domain restricts access to the Schema Administrators group. Although other methods (e.g., Group Policy) let you restrict users' ability to modify the membership of groups in Win2K, the root domain's Domain Administrators group can override any restriction.

Improved Administrative Access Control
Another powerful administrative group in the root domain is the Enterprise Administrators group. Members of the Enterprise Administrators group have full administrative control over all domains in the forest. By default, AD makes the Enterprise Administrators group a member of the Domain Administrators group for each domain in the forest. More important, only the Enterprise Administrators group can make changes that affect the forest as a whole, such as adding or removing new domains, subnets, sites, and site links.

A third important administrative group is the root domain's Domain Administrators group. As in any domain, members of the Domain Administrators group have rights to administer all functions within their domain. Because the root domain contains both the Schema Administrators and Enterprise Administrators groups, members of the root domain's Domain Administrators group can modify the membership of these two groups. Although members of the Domain Administrators group don't inherently have the ability to manipulate the schema or administer any other domains, Domain Administrators can simply add themselves to the Schema Administrators and Enterprise Administrators group and gain full rights to the forest. Obviously, you must carefully restrict membership to the Domain Administrators group in the forest root domain. A dedicated forest root helps you maintain tight control over the Domain Administrators group's membership.

Improved Design Flexibility
Designing an AD structure that you can easily maintain through acquisitions, mergers, and divestitures is important. A dedicated forest root permits more flexibility for future reconfiguration. For example, suppose XYZ Corporation currently has an NT 4.0 domain structure. Management asks you to assist XYZ in upgrading to Win2K. The first step is to design an AD structure. XYZ currently has two divisions, one of which (Division2) it will likely sell sometime in the next 2 years. The corporation is also negotiating to acquire two new companies during the next year.

Figure 1 shows the current NT 4.0 domain structure. One possible AD design would be to create a single domain and use organizational units (OUs) and administrative delegation to organize resources and permissions. However, this approach would provide little flexibility. A single domain would mandate that all users in both divisions have the same domain-level security settings, such as the same password-aging time frames and the same password lengths. The single domain would also limit the possible support models. Situations such as mergers and acquisitions would be difficult to handle from a political standpoint. For example, Domain Administrators from an acquired company would lose control over domainwide settings if their entire division became an OU within a giant corporate domain.

Alternatively, XYZ can use a dedicated forest root design. Figure 2 shows an AD design in which the root domain, XYZRoot.XYZ.COM, is unpopulated and in which XYZ has upgraded the two divisions to Win2K domains. XYZ has incorporated the resource domains into the domain structure as OUs. One benefit of Win2K is that you no longer have to set up trust relationships. In XYZ's NT 4.0 structure, the administrator had to establish a separate trust from each resource domain to each master domain. In Win2K, you can place the OUs in either domain and they're automatically reachable from anywhere in the forest, provided the proper permissions exist.

In this model, Division1 and Division2 are peers of the root. They each represent a separate tree in the forest, using separate, noncontiguous namespaces. Figure 3 shows an alternative design—a dedicated forest root that contains subdomains. In this environment, a contiguous namespace exists; each of the subdomains incorporates the names of the upper-level domains. The decision to create the domains as separate trees or as two branches of one tree is really up to the designers. A single tree gives a fully contiguous namespace across the organization, but the fully qualified names for objects can get a bit long. With separate trees, the fully qualified names are shorter, but the connection between domains is less intuitive.

The dedicated forest root domain XYZRoot.XYZ.COM houses both the Schema Administrators and Enterprise Administrators groups. The Domain Administrators in Division1 and Division2 have authority only in their respective domains. They don't have any rights to the root domain unless you give them that access. The dedicated root serves the dual purpose of improving security and limiting access to the schema to those whom you specifically select to maintain it. You can delegate administrative access to the root domain to a centralized IT group or to a panel of trusted individuals from each division. And you can develop a good change control process, administered by the centralized IT group or the panel, for schema changes.

When XYZ divests itself of Division2 and acquires the two new companies, the corporation's AD can easily evolve without changing its administrative model, as Figure 4 shows. The new companies can continue to administer themselves, and XYZ can simply remove Division2 from the forest. (This example assumes that the companies XYZ acquires are running NT rather than Win2K. If these companies were already running Win2K, incorporating the new domains into the XYZ.COM forest would be more difficult because you can't rename domains or migrate domains from one Win2K forest to another. Note also that XYZ has removed Division2 from its forest structure, but Division2 can't exist as an autonomous domain. The company that acquires Division2 will need to manually add the users and other objects from this domain into the acquiring company's domain structure.)

You might wonder why, in our original design for XYZ, we didn't just create one domain and make Division1 and Division2 OUs in that domain. After all, deleting an OU is just as easy as deleting a domain. Remember that we had reasons for the suggested domain structure beyond just simplifying Division2's future removal. We didn't want to give the Division1 and Division2 Domain Administrators access to the Schema Administrators and Enterprise Administrators groups, and revoking their Domain Administrator authority would have been politically difficult. We might also have wanted different security settings for the two domains. Finally, a domain is a replication boundary, so we might have wanted to keep the replication traffic between these two divisions segregated. Therefore, administrative requirements rather than anticipated ease of divestiture drove the decision to create two domains rather than two OUs.

Cautionary Notes
Each domain installed in a forest requires at least one domain controller (DC). For redundancy and performance purposes, Microsoft recommends multiple DCs per domain. The dedicated forest root's most obvious disadvantage is the cost of buying additional servers to act as DCs. For example, if a company's AD design calls for two active domains and the company wants to use a dedicated forest root, it would actually need to purchase equipment for three domains (the two active domains plus the dedicated forest root). In addition to the hardware cost, the extra domain adds administrative and maintenance costs. For this reason, many smaller companies might conclude that the dedicated forest root benefits don't outweigh the costs.

Also, regardless of whether your root domain is dedicated, it should have DC redundancy. The root domain houses crucial forest functions and serves as the base upon which you build the rest of your forest. If the root domain resides solely on a single DC and that DC fails, you must restore from backup media, making recovery operations complex and time-consuming. Relying on backups alone for such a crucial forest function isn't wise. In addition, geographically dispersed companies can improve performance when accessing resources in other domains by placing additional root domain controllers in key network hub sites. This technique speeds the Kerberos referral process necessary for resource access as well as for several DNS operations.

The dedicated forest root design affords tight schema control, better delegation of administrative access, and significant design flexibility. These benefits come at the cost of additional hardware and administrative overhead. AD designers must weigh the costs and benefits of employing the dedicated forest root and determine whether it's appropriate for their organization.