Multiple-Forest Trusts

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.

Windows 2003's Forest Trust
A forest trust is one trust link between two forests' root domains. Figure 1 shows two-way internal trusts within Forest A and Forest B and a two-way forest trust between Forest A and Forest B. Forest trusts let you tie forests together in a federation or alliance of forests in a simple and easily supportable manner that scales far beyond what's practical with NTLM trusts. Because the forest trust favors Kerberos instead of NTLM, the trust is transitive between two forests. For example, if Forest A trusts Forest B, all the domains in Forest A trust all the domains in Forest B. However, the trust isn't transitive across forests. If Forest A trusts Forest B and Forest B trusts Forest C, Forest A doesn't automatically trust Forest C. The same rules you use for NTLM trusts between NT 4.0 domains apply but are scaled up to accommodate forests of domains. As with NTLM trusts, you can establish one- or two-way forest trusts.

Forest Trust Benefits
Two benefits of the forest trust are cross-forest authentication and authorization. Cross-forest authentication lets users who have an account in a trusted forest log on to computers in a trusting forest without needing to create duplicate accounts. Cross-forest authorization also lets you grant permission for users in a trusted forest to access resources in a trusting forest without duplicating accounts. These actions don't compromise the forest's security boundaries.

Although you can create external trusts between forests, using Kerberos-based forest trusts dramatically reduces the number of trusts necessary between forests. You can calculate the number of external trusts necessary to maintain trust relationships between all the domains of two forests by using the formula (Total number of external trusts) = (1- or 2-way trust) * (Number of domains in Forest A) * (Number of domains in Forest B).

For example, suppose you have a development forest (DEV) with three domains and a production forest (PROD) with four domains and you want a two-way trust relationship between all the domains across the forests. You would need to create and support 24 trusts (2 * 3 * 4). This number of trusts is inconvenient but not unsupportable. If, however, you decide to add an integration forest (INT) with four domains, the trust topology gets much more complicated. Instead of one trust relationship between two forests, you now have three trust relationships: DEV to PROD, DEV to INT, and PROD to INT. When you add the trust relationships between the two new combinations, your total number of trusts to maintain rises to 80.

An important strategy that a forest trust lets you implement is an account forest configuration. An account forest, which Figure 2, page 70, shows, is essentially a scaled-up version of the NT 4.0 account domain or resource domain configuration. To establish an account forest, ensure that all your nontest accounts are in the primary corporate forest. Then, create one-way forest trusts from your other (i.e., resource) forests to your primary forest. (For information about creating one-way trusts, see the sidebar "Easy 1-Way Trust Creation.") Users can use their primary user accounts to log on to any forest in the federation. You can even delegate the trust-creation administrative right to users who don't belong to the Enterprise Admins group.

You might wonder why Windows 2003's forest trust can comprehend another forest although Win2K's external trust can't. In Windows 2003, a trusted domain object (TDO) represents the basic trust information for external trusts and forest trusts. In a forest trust, the TDO contains an additional attribute called Forest Trust Information. This attribute has information about all the domains in the remote forest, the tree names, and any alternative name suffixes. This information is necessary for routing authentication and lookups to the remote forest when necessary. The Global Catalog (GC) stores the information, so any domain controller (DC) can look up the information.

Configuring a Forest Trust with Windows 2003
To construct a forest trust, you must first ensure that both forests are on Windows 2003's forest functional level. Every DC in both forests must be running Windows 2003, each domain must be upgraded to Windows 2003's domain functional level, and both forests must be upgraded to Windows 2003's forest functional level. For more information about these functional levels, see "What's New and What's Improved in Windows .NET Server?" http://www.winnetmag.com, InstantDoc ID 24316.

Next, both forests' root domains must be able to find each other through DNS. If you're in a corporate intranet and both forests are integrated into your company's DNS, the forests' root domains can probably already find each other. To check, open a command prompt from a server in one forest and run Nslookup. Enter

set type=ns

then enter the other forest's root domain's Fully Qualified Domain Name (FQDN—e.g., forestb.mycompany.com). If the server can resolve the FQDN, Nslookup will return a list of DCs that are authoritative for that domain.

If you can't resolve the other forest through your existing DNS configuration, you need to configure conditional DNS forwarding for all the DNS servers in each forest. Add one or more forwarders for one forest's root domain to the other forest, and vice versa. A forwarding server tells the local DNS server that when the DNS server receives a request for a certain domain, the DNS server should forward the request to a specific IP address. For example, suppose you want to join ForestA.com and ForestB.com with a forest trust. In the Microsoft Management Console (MMC) DNS snap-in, right-click a DNS server that's authoritative for Forest A and select Properties. Select the Forwarders tab and enter the IP addresses for the DNS servers to which you want to forward requests for Forest B, as Figure 3 shows. Repeat this process in Forest B to resolve requests for Forest A.

Remember that using forwarding servers to resolve requests for forests (and therefore the trusts between the forests) depends on the forwarders' IP addresses that you entered manually. If any of the addresses change and you don't update your forwarders table on all your DNS servers, your trusts might fail.

After you can resolve either forest, use the MMC Active Directory Domains and Trusts snap-in's New Trust Wizard to establish the type of trust you want. Let's step through setting up a two-way trust between forests.

Select Active Directory Domains and Trusts from the Administrative Tools menu, or enter

domain.msc

at the Run prompt or from a command line. Right-click the root domain, select Properties, and select the Trusts property sheet. Select New Trusts to launch the New Trust Wizard.

The New Trust Wizard is new in Windows 2003. This wizard leads you through the myriad types of trusts you can create, with four types of targets—a Windows 2003 or Win2K domain, an NT 4.0 domain, a Kerberos 5.0 realm, and another forest. The wizard's Help feature provides additional information about trusts, functional levels, and user principal names (UPNs).

Although you're using a wizard to set up the trust operation, pay close attention to how you're setting up the trust and review the confirmation screen before you establish the trust. Many possibilities exist for setting up trusts, and the wizard won't recommend one type of trust over another. If you make a mistake, you won't get a forest trust—and often the only way you can tell is that the resulting trust type is external rather than forest. For example, if you choose a child domain's properties rather than the root domain's properties, establishing a forest trust won't be an option—but its absence isn't obvious.

The first step in the New Trust Wizard is to enter the DNS or NetBIOS name for the forest you want to set up the trust with. If you've completed all the steps correctly so far, the next dialog box will ask you to select External trust or Forest trust, as Figure 4 shows. If the forest trust option doesn't appear, go back to the wizard's first page and use the Help button to determine what isn't set up correctly.

For our example, we'll set up a two-way trust. As Figure 5 shows, the New Trust Wizard lets you create the two one-way trusts that make up a two-way trust right from the wizard as long as you have administrative privileges in the other forest.

The next two dialog boxes let you choose whether you want all users in the target forest to automatically be authenticated when attempting to access a resource in the local forest, and vice versa. If you select Allow authentication only for selected resources in the local forest, as Figure 6 shows, Windows 2003 won't automatically add the trusting forest's Authenticated User SID to the trusted forest user's token; you must grant individual access to resources. This feature is called selective authentication. Selective authentication is more secure than allowing authentication for both forest's users, but using the feature creates more administrative overhead because you must explicitly grant access to each domain and server you want the other forest's users to be able to access.

The Trust Selections Complete dialog box lets you review your selections before you execute them. You'll see a Trust Creation Complete dialog box after you create the trust. The wizard's final steps offer another useful feature. Because you've already provided the other forest's remote credentials, you can confirm both sides of the trust without completing additional steps. After you successfully complete the forest trust and the wizard closes, the Trusts property sheet will show forest under trust type rather than just child or external.

Although implementing a forest trust is fairly straightforward, the consequences of making a mistake can be severe when you're working on a multiforest level. Be careful when implementing forest trusts. Before you start, study the best implementation practices.

Forest Trust Limitations
A forest trust isn't totally transparent to users. When a user logs on to a computer that's a member of a forest other than the forest that contains the user's user account, the user won't see his account domain listed in the logon dialog box. The user will need to enter his UPN (e.g., [email protected]). Microsoft made this design choice because multiple forests sometimes have NetBIOS name conflicts between their domains. For example, let's assume forest1.bigtex.net and forest2.bigtex.net cover the same geographic area. Although the FQDNs (namerica.forest1.bigtex.net and namerica.forest2.bigtex.net) are unique, if the forests don't use the same WINS namespace, they might both have domains with the NetBIOS name NAMERICA. Also, if your forest's users aren't logged on to a Windows 2003 server or a Windows XP Service Pack 2 (SP2) client, when the users want to add a cross-forest user or group to a resource in your forest, they won't be able to browse through a list of users and groups to find the resource. Instead, your forest's users must enter the resource's UPN. Figure 7 shows an ACL for a resource in Forest A to which a user from Forest B has been added. The access control entry (ACE) uses the UPN rather than the conventional domainaccount syntax.

Another important consideration related to UPNs is forest namespace collisions. By default, a user's UPN format is account@FQDN. For example, if Jim Bob has an account in the child domain lubbock.bigtex.net, his default UPN is [email protected]. You could also use the root domain to choose the UPN [email protected]. Many companies use the root domain's UPN so that the UPN matches their users' email addresses. This strategy works if you have only one forest with user accounts—but what if you have two or more forests that contain user accounts? Everyone in the company has a bigtex.net email address, but after one forest takes that UPN suffix, another forest can't use the suffix. Internally, you must choose unique, nonoverlapping UPN suffixes for your users (e.g., f1.bigtex.net, f2.bigtex.net). Externally, you can use bigtex.net for email.

See the Forest for the Trusts
The forest trust is a significant new feature in Windows 2003. The forest trust removes a Win2K restriction that makes supporting many tightly integrated forests impractical. For companies that need to tie separate forests together, the forest trust feature alone can justify the cost of upgrading from Win2K to Windows 2003.