Windows 2000 lets companies integrate their various business units into an overall structure—the Active Directory (AD) forest—that wasn't possible with Windows NT 4.0. Many business units that couldn't coexist in an NT 4.0 domain can get along in their AD organizational units (OUs) or domains. But as anyone who has tried to implement a single-forest architecture can tell you, many situations exist in which business units can't get along. Sometimes business requirements or politics demand that you implement a separate forest. In many cases, users in separate forests still need access to the resources in your central forest. Thus, you need to establish a trust relationship between your central forest's domains and other forests' domains. Win2K uses essentially the same process as NT 4.0 uses to establish trusts between domains in different forests. But Windows Server 2003's new forest trust feature makes this task easy.
The Case for Multiple Forests
From an information security perspective, a domain is more a replication or administrative boundary than a security boundary. With a little work, a member of the root domain's Administrators, Domain Admins, or Enterprise Admins group can gain access to any computer in the forest. The only way to truly isolate resources is to place them in a separate forest.
We shouldn't abandon the goal of having just one forest, but we need to rephrase the goal: Keep the number of forests to an absolute minimum; allow additional forests only if they comply with strict criteria and meet a management-review committee's approval. For information about standards to use in deciding when to create forests, see the Microsoft white paper "Design Considerations for Delegation of Administration in Active Directory" (http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/addeladmin.asp). This white paper clearly explains the security boundaries between OUs, domains, and forests and provides a process for determining whether a business unit should be in its own OU, domain, or forest separate from the central forest.
When might you justify a separate forest? The requirements fall into several categories. The best-known requirement for establishing a separate forest is the need to ensure administrative autonomy (aka "I don't trust you"). Another is when a major business unit implements a Win2K forest on it own, most likely on a more aggressive schedule than the company's IT production forest. Because this forest will be around for a while, you need to find a way to live with it. Yet another situation relates to the forest schema. Remember that the schema (i.e., the definition of AD's structure) is shared across the entire forest. If you need to change the schema frequently (e.g., for AD-enabled software testing), you should do so in a separate forest so that you modify your production schema only when necessary.
Asset isolation is another important reason for having a separate forest. For example, law-enforcement agencies must keep information separate from other agencies. Likewise, defense contractors that have contracts available only on a need-to-know basis must show total isolation from outside influences. And industries such as banking can receive harsh penalties for sharing information.
Win2K Trusts Inside a Forest
The Kerberos security protocol automatically establishes trusts between domains in a Win2K forest. An important Kerberos feature is that it supports transitive trusts. If Domain A trusts Domain B and Domain B trusts Domain C, then Domain A automatically trusts Domain C. A simple way to remember transitive trusts is, "Any friend of yours is a friend of mine." This feature enables the concept of domain trees, whereby Kerberos ticket referral forwarding lets a domain automatically trust another domain in the forest. Kerberos two-way trusts within a forest are also called internal trusts. For more information about Win2K's Kerberos implementation, see the Microsoft white paper "Windows 2000 Kerberos Authentication" (http://www.microsoft.com/windows2000/techinfo/howitworks/security/kerberos.asp).
Win2K Trusts Between Forests
Outside the forest, trust relationships are more primitive. In Win2K, Kerberos isn't available to establish trusts between forests. NT LAN Manager (NTLM) establishes trusts between NT 4.0 domains and between Win2K domains in other forests. These trusts are called external trusts. (A third kind of trust, the shortcut trust, uses Kerberos to directly link two of a domain tree's child domains to improve performance.)
External trusts have the same limitations as any NT 4.0 trust: An external trust isn't as secure as a Kerberos trust and isn't transitive. As a result, you can quickly run into a situation, such as in NT 4.0, in which you must maintain a web of trusts to and from every domain in every forest.
Previous
Register
