Multiple-Forest Trusts

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., jimbob@bigtex.net). 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 domain\account 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 jimbob@lubbock.bigtex.net. You could also use the root domain to choose the UPN jimbob@bigtex.net. 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.

End of Article

   Previous  1  2  [3]  Next