Windows 2000 Server introduced the concept of a forest as a logical and administrative grouping of several Windows domains linked together by trust relationships and a DNS namespace. A forest provides ease of use and ease of administration for resources that must be available to the users of different domains. A forest also facilitates the deployment, administration, and use of enterprise applications such as Microsoft Exchange Server.
In Win2K, the domain is no longer a true security boundary; the final border is the forest. As a consequence, the domains in a forest must have a certain amount of trust between them. Organizations that can't live with the domain trust requirements for political, legal, or purely administrative reasons deploy multiple Win2K forests. In smaller organizations, each forest might consist of one domain. Some larger organizations build multiple forests when they merge with or acquire another company. Some companies build two forests for perimeter-security reasons: one forest for the intranet and another one for the demilitarized zone (DMZ).
Defining trust relationships between forests is a major problem in Win2K. From a security-administration point of view, creating these trust relationships is an administrative nightmare that basically puts your Win2K environment back in the Windows NT 4.0 era. (Remember the spaghetti model of trust?) Also, trust definition in general in Win2K is the same as in Win2K's predecessors: very coarse-grained.
Clearly, Win2K doesn't easily support multiple forests. But in Windows Server 2003, Microsoft introduces a new trust type called forest trust that resolves most of the Win2K multiple forest and cross-forest trust problems and shortcomings. A forest trust is basically one trust link between the two root domains of two forests. Windows 2003 also includes a set of important enhancements that facilitate the setup and administration of trust relationships between forests.
Forest Trusts and Transitivity
In Windows 2003, forest trust relationships are transitive, which means that one trust between the two root domains of two forests enables authentication between all domains in the two forests. Figure 1 shows that because of the transitive forest trust between the Compaq.com and Hp.com forests, domain C in Compaq.com automatically has a transitive trust relationship with domains D, E, and F in Hp.com. The same is true for all the other domains in the two forests. Transitive trusts greatly simplify forest trust administration and provide transparent single sign-on (SSO) between all domains in the two forests. To achieve the same level of trust in Win2K, you must define a trust relationship between each domain in one forest and each domain in the other forest.
Forest trusts aren't transitive between multiple forests. If a forest trust exists between the Compaq.com forest and the Hp.com forest and between the Compaq.com forest and the Digital.com forest, a transitive trust doesn't automatically exist between Digital.com and Hp.com. If you required a transparent SSO experience between Hp.com and Digital.com, you would need to establish an explicit forest trust relationship between those two forests.
The Forest Object
The basic enabler behind forest trusts is a new Active Directory (AD) trusteddomain object type called forest. Trusteddomain objects of type forest contain a new attribute called msDS-TrustForestTrustInfo that stores information about the domains in the trusted forest. The stored information is basically security and naming information about the trusted forest's root domain and any top-level name (TLN) restrictions related to the trusted forest's other domains. Windows 2003 uses the information stored in the msDS-TrustForestTrustInfo attribute to route authentication requests and object lookups between forests.
Windows 2003 replicates the trusteddomain objects and their attributes to the Global Catalog (GC). Thus, any machine in the forest can look up those objects and attributes and use their content. To view a trusteddomain object's attributes, you can use the ADSI Edit tool in Windows 2003 Support Tools.
To establish a Windows 2003 forest trust relationship, both forests must be at Windows 2003 functionality level 2. The functionality level of a Windows 2003 domain or forest describes the state of its domain controllers (DCs) and the available feature set; functionality levels are an extension of the mixed mode or native mode concept that exists for domains in Win2K. Forest functionality level 2 is available only when all the forest's domains are at functionality level 2. A domain can be at functionality level 2 only when all its DCs are running Windows 2003. Windows 2003 functionality level 2 is the highest level—the level at which all new Windows 2003 features are available.
Forest Trust Features
In Win2K, trust definition is coarse-grained: When you set up a trust between forests, you either trust everyone or no one. In Windows 2003, you can define forest trust relationships in a granular way. Windows 2003 supports three ways to restrict forest trusts: TLN restrictions, selective authentication, and SID filtering.
Forest trust relationships enable the use of different authentication protocols and methods for cross-forest resource access. Windows 2003 supports Kerberos and NT LAN Manager (NTLM) for cross-forest network logons. For interactive cross-forest logons, users can use either a Kerberos PKINIT-based smart card logon or a user principal name (UPN)based logon (the latter supports both the Kerberos and the NTLM authentication protocols).
To ease the setup and configuration of trust relationships, Windows 2003 includes the New Trust Wizard, which you can access from the Microsoft Management Console (MMC) Active Directory Domains and Trusts snap-in. The wizard guides you through the different configuration options for a forest trust, as well as for the other trust types (i.e., shortcut, external, and realm). When the wizard detects that the trusted domain is a forest root domain, it lets you set up either a forest trust or an external trust. An external trust is an explicitly created trust link between two domains in two forests. Both Windows 2003 and Win2K support external trusts. The key difference between a forest trust and an external trust is that a forest trust contains information about all the domains in the remote forest. Thus, it can support Kerberos-based authentication, UPN-based logon, and object lookups between any of the domains in the two forests.
The easiest way to discover a trust relationship's type is to right-click a domain container in the Active Directory Domains and Trusts snap-in and select Properties. On the Properties dialog box's Trusts tab, you can find the domain name of the trusted and trusting domains, the trust type, and whether the trust is transitive.
When you set up a forest trust, the New Trust Wizard guides you through the following steps:
- Set the DNS or NetBIOS name of the target domain.
- Specify whether the trust is bidirectional, one-way incoming, or one-way outgoing. A one-way incoming trust lets users in your domain authenticate to and access objects in the foreign domain. A one-way outgoing trust lets users in the foreign domain authenticate to and access objects in your domain.
- Enable selective authentication, if you want to do so.
- Specify the DNS name suffixes that you want to enable for cross-forest routing.
- Confirm the creation of the trust.
Forest trust relationships also enable cross-forest object browsing. Figure 2 shows how the Windows 2003 object picker (which you use for specifying access-control settings) displays the cpqtest.net and digitaltest.net forests when you open it on a machine in the hewlettpackardtest.net domain after establishing forest trust relationships between hewlettpackardtest.net and cpqtest.net and between hewlettpackardtest.net and digitaltest.net.
Name-Suffix Routing and TLN Restrictions
Windows 2003 uses a mechanism called domain name suffix routing to provide name resolution between forests linked by a forest trust relationship. Name resolution is needed to route cross-forest authentication and object requests. The Windows 2003 cross-forest routing mechanism is rooted in a list of DNS domain-name suffixes stored in the trusteddomain object of a forest's root domain. You can disable, enable, or exclude suffixes to modify cross-forest routing behavior.
Consider the example of a forest trust between the hewlettpackardtest.net and the cpqtest.net forests. The hewlettpackardtest.net forest has a root domain of the same name and a second domain named Hp.com. The cpqtest.net forest has a root domain of the same name. The cpqtest.net domain administrator decides that she doesn't want to trust the authentication requests from or send object queries to the Hp.com domain, so she disables the Hp.com domain name suffix in the msDS-TrustForestTrustInfo attribute of the trusteddomain object for the hewlettpackardtest.net domain in the cpqtest.net AD.
The administrator can also use the New Trust Wizard dialog box that Figure 3 shows to disable a domain name suffix. The wizard displays all the name suffixes of the top-level domains (TLDs) in a forest (except for the name suffix of the root domain) and all the UPN suffixes that have been defined at the forest level. Forest UPN suffixes let administrators define additional suffixes that are different from the DNS domain names in an AD forest. (To add or delete UPN suffixes, right-click Active Directory Domains and Trusts in the Active Directory Domains and Trusts snap-in and select Properties.) In our sample forest trust, the hewlettpackardtest.net forest has the TLD name suffix Hp.com and one UPN suffix: hptest.net. In Figure 3, the cpqtest.net domain administrator has disabled in the cpqtest.net forest the routing of all requests with a *.hp.com suffix and has enabled routing for the *.hptest.net suffix.
Yet another way to disable a domain name suffix is to use the Name Suffix Routing tab of the Properties dialog box for a trust object (right-click the object in the Active Directory Domains and Trusts snap-in and select Properties). Figure 4 shows the Name Suffix Routing tab for the hewlettpackardtest.net trust object. Note that the tab shows a DNS suffix *.hewlettpackard.net that's disabled and marked as New. The administrator added this UPN suffix to the hewlettpackardtest.net forest after the New Trust Wizard was run. Windows 2003 disables newly added suffixes by default.
Disabling a domain-name suffix in the properties of a forest trust relationship fully disables the routing of requests to that DNS namespace and all its subordinate namespaces. For example, disabling the Hp.com domain-name suffix disables the routing to any subordinate namespaces, such as emea.hp.com, americas.hp.com, and asiapac.hp.com. TLN restrictions let you disable the routing of just selected subordinate namespaces. For example, you could enable routing to the Hp.com namespace (and its subordinate americas.hp.com and asiapac.hp.com namespaces) and disable just the routing to the emea.hp.com subordinate domain-name suffix.
You can also use TLN restrictions to avoid DNS namespace collisions during the routing of cross-forest authentication requests. A DNS namespace collision occurs when the Windows security software can follow two or more DNS paths to get to a target domain or forest.
Figure 5 shows three bidirectional cross-forest trust relationships between the cpqtest.net, hewlettpackardtest.net, and hr.hewlettpackardtest.net forests. By default, the forest trust between cpqtest.net and hewlettpackardtest.net routes all authentication traffic for the *.hewlettpackardtest.net domain-name suffix to the hewlettpackardtest.net forest. Because of the forest trust between hewlettpackardtest.net and hr.hewlettpackardtest.net, the *.hewlettpackardtest.net namespace includes both the hewlettpackardtest.net and hr.hewlettpackardtest.net namespaces. Because of the lack of trust transitivity between multiple forests, an authentication request coming from the cpqtest.net forest for a service in hr.hewlettpackardtest.net that's routed through hewlettpackardtest.net can't be forwarded by hewlettpackardtest.net's DCs to the hr.hewlettpackardtest.net forest. To avoid this DNS namespace collision, you should set a TLN restriction in the cpqtest.net domain to exclude the hr.hewlettpackardtest.net domain-name suffix from cpqtest.net's forest trust with hewlettpackardtest.net.
You can use the Name Suffix Routing tab of a trust object's Properties dialog box to define TLN restrictions that exclude domain-name suffixes. Select the suffix that you want to work with—in this case, hewlettpackardtest.net. Click Edit to open the dialog box that Figure 6 shows, click Add, and select *.hr.hewlettpackardtest.net to exclude that suffix from routing to hewlettpackardtest.net. You can't set TLN restrictions from the Windows 2003 New Trust Wizard.
Selective Authentication
When you enable the selective authentication feature of a forest trust relationship, users in one forest accessing resources in the other forest can't authenticate to a DC or resource server (e.g., file server, print server) in the other forest unless you explicitly let them do so. Microsoft added the selective authentication feature to allow for a more granular forest trust definition. If you disable selective authentication, all forest A users become almost perfect peers of forest B users from an access-control point of view because the Windows 2003 security subsystem adds them to the Authenticated Users group of forest B when they cross the trust. When you enable selective authentication, forest A users are still members of the Authenticated Users group, but they can authenticate to forest B only after they pass an additional access-control check.
You can enable a forest trust relationship's selective authentication function by using the New Trust Wizard or the trust relationship's Properties dialog box. To enable selective authentication from the trust's Properties dialog box, go to the Authentication tab and select Allow authentication only for selected resources in the local forest. When you try to access a resource in a forest for which the authentication firewall has been enabled from a machine in that forest, you'll see the error Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.
After you enable a forest trust's selective authentication feature, you must enable access to the machines in the forest that you want users to be able to reach. For example, to enable users to authenticate to DCs in forests that have selective authentication enabled, the forest administrator must change the access-control settings of the AD DC objects. To do so, you use the Advanced Features view of the MMC Active Directory Users and Computers snap-in, open the Properties dialog boxes of the appropriate DCs, go to the Security tab, and give the user Allowed to Authenticate permission, as Figure 7 shows. If users wanted to access resources on a file server, you'd change the access-control settings of the file server's machine account object.
The additional access-control check for the Allowed to Authenticate permission is triggered by a special SID that Windows 2003 adds to a user's access token when the user tries to access a resource in the other forest of a forest trust, if that forest has selective authentication enabled. This SID is called This Organization and has the value S-1-5-15. You can easily check for its presence in a user's access token by using the Whoami command-line tool and the /groups switch.
SID Filtering
The idea behind SID filtering is that SIDs for which the DCs in a forest aren't authoritative shouldn't be included in the authorization data that those DCs send to the other forest in a forest trust scenario. When a user tries to authenticate to the DC of another forest, the Windows 2003 security subsystem sends the user's authorization data (e.g., group memberships) along with the authentication request. The DC of the remote forest validating the authentication request filters out all SIDs stored in the user's security token that aren't associated with the user's local forest.
SID filtering protects against attempts to add foreign SIDs to authorization data in order to elevate a user's privileges. (These threats are also known as elevation of privilege attacks.) For example, if a user succeeded in adding the SID of the Enterprise Administrators group of another forest to his access-control data, he could gain enterprise administratorlevel access to that other forest.
Figure 8 shows the effect of using SID filtering between two forests: the Microsoft forest and the HP forest. In this example, a user who's defined in and logged on to the Microsoft forest wants to access a resource in the HP forest. In the first step, a DC in the Microsoft forest sends the user's authorization data along with her authentication request to a DC in the HP forest. In the second step, the DC in the HP forest filters out all SIDs that aren't linked to the user's definition forest (i.e., the Microsoft forest). In the example, the DC automatically removes all SIDs referring to the HP forest and another forest called the Sun forest.
SID filtering is enabled automatically when you set up a Windows 2003 forest trust relationship. You can't apply it to trust relationships between domains in the same forest. Doing so breaks AD and GC replication. Microsoft introduced SID filtering in Win2K Service Pack 2 (SP2). The Microsoft article "MS02-001: Forged SID Could Result in Elevated Privileges in Windows 2000" (http://support.microsoft.com/?kbid=289243) explains how to set up SID filtering in Win2K.
Federation Building Blocks
Windows 2003 forest trust relationships let administrators securely federate two AD forests by using one trust relationship. The forest trust features provide a seamless user-authentication and access-control experience between two forests. You must carefully plan the security for a forest relationship, and Windows 2003 offers powerful new tools to define fine-grained forest-trust security policies.
The forest trust features are a fundamental building block of Microsoft's federation strategy. Windows 2003 forest trusts are primarily intended for internal federation—to link together company forests or company partner or subsidiary forests. This year or next, Microsoft will introduce a product (currently code-named TrustBridge) that's designed for external federation—between Windows forests and other organizations, or Trusted Third Parties (TTPs), that aren't necessarily rooted on Microsoft technology.