Multiple-Forest Trusts

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.

   Previous  1  [2]  3  Next