Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Forest Trust

When an external trust is created between a Windows Server 2003 domain and another Windows Server 2003 domain in another forest, the trust relationship can be one-way or two-way, incoming or outgoing. Selective authentication can be used to limit the domains in the trusting forest that will participate in the trust. However, the trust relationship only exists between the two domains and is not a Kerberos-style trust. Authentication across the trust relationship will be NTLM. If you require trust between all domain controllers in each of two forests, you must create a forest trust. If you do so, the trust can be one-way or two-way and will be a Kerberos transitive trust. The following requirements must be met before the trust can be created:

Both forests must be Windows Server 2003 forests.

All DCs must be running Windows Server 2003.

Both forests must be at Windows Server 2003 level functionality. (The trust is created between the root forest domains of each forest.)

The DNS infrastructure must be configured correctly.

Transitivity exists between forests in a forest trust but does not extend to other forest trust relationships. Transitivity between forests means that the trust relationship extends to every domain in both forests. That is, if Forest A is trusted by Forest B, and Forest B is trusted by Forest C, there is no trust relationship between Forest A and Forest C. Users in Forest A may be granted access to resources in Forest B, and users in Forest B may be granted resource access in Forest A, but users in Forest A cannot be given access to resources in Forest C.

SID filtering is enabled automatically across a forest trust, thus helping to prevent elevation of privilege attacks.

Incoming and Outgoing Forest Trusts

Trust relationships between Windows Server 2003 forests are also defined using the incoming and outgoing convention. If a forest has an incoming forest trust, this indicates that the users in the internal or local forest can be granted access to resources and privileges in the external or specified forest. This is roughly equivalent to saying that the local forest is trusted and the specified forest is trusting. When a forest has an outgoing forest trust, it means that users in the specified forest can be granted access to resources and privileges in the local forest. This is roughly equivalent to saying that the local forest is trusting and the specified forest is trusted. Figure 8-32 displays these relationships. In the figure, the domain 1 forest has incoming and outgoing forest trusts with the domain B forest. John and Peter, who have accounts in domains 3 and 8, respectively, can be given permission to access resources in any domain in the domain A forest. Likewise, Francine, with an account in domain E, can be given access to any domain in the domain 1 forest.

Figure 8-32. Incoming and outgoing forest trusts.

The words "can be given access" mean just that. After the completion of a trust, no user in either forest, just like no user in an external trust, has privileges or permissions in the other forest, with the possible exception of authentication and access granted to the group Everyone. Windows Server 2003 trusts can also limit that possibility. Previously, the right to authenticate in the trusting domain was a default. This allowed users from the trusted domain to sit down at a workstation in the trusting domain and authenticate to their own domain. It allowed them to cross the security boundary. In Windows Server 2003, selective authentication, if specified, allows the boundary between external domains to remain intact unless authentication is specifically granted domain-by-domain (forest trust) or server-by-server (external trust). More information about selective authentication can be found in the earlier "External Trust Creation Procedures" section.

Reasons for creating forest trusts are as follows:

An organization with multiple forests establishes trust between the two forests to provide resource access and authentication between all domains in the forests.

Two separate organizations may want to create a forest trust to provide access to selected resources. Although external trusts can be used instead, the number of domains involved and thus the number of trusts is extensive. Creating a forest trust reduces the number of trusts to create and manage.

An organization with multiple forests establishes a granular level of transitive trust between its forests. While the goal may be full-transitive trust between all domains in both forests, specific domains are excluded from that transitivity.

Cross-Forest Authentication and Authorization

The process of obtaining ticket granting tickets (TGTs) during authentication and service tickets to enable resource access in a single forest was described in Chapter 2, "Authentication: Proof of Identity." When a forest trust exists and requests that resource access lie outside the forest, a special additional action is necessary. Figure 8-33 illustrates the process. In the figure, Peter, whose workstation and user account is in domain 8, wants to access a resource in domain F on its server 1 across a forest trust between the domain 1 forest and the domain A forest. The following steps match the numbers in the figure.

Peter''''''''''''''''s workstation contacts a local DC in its domain, domain 8, with a request for a TGT for access to server 8 in the F domain.

The DC queries its domain GC for a location, in this case on server 7. The GC recognizes that the Service Principal Name (SPN) of the request is not in its forest and returns the request to the workstation, telling it to send its request to the root domain of its forest, domain 1. The GC includes a "routing hint" or location of the forest root domain. The SPN is either a DNS name of a host, a DNS name of a domain, or the distinguished name of a service connection point object.

The workstation passes its request to a DC in its forest root domain, domain 1. The forest root domain of the workstation''''''''''''''''s forest (domain 1) provides a TGT to the forest root domain, domain A, of the other forest.

The workstation sends its request to the forest root domain, domain A. The forest root domain returns the location of and TGT for the DC for server 8, domain F.

The workstation requests a service ticket from the domain.

The workstation sends its request to a DC in domain F and receives a TGT for server 8.

The workstation sends its request for access and its TGT to server 1.

Figure 8-33. Obtaining tickets across a forest trust.

Creating a Forest Trust

By default, only a member of the Enterprise Admins group or a member of the forest root domain Domain Admins group can create a two-way forest trust. Members of the Incoming Forest Trust Builders group can create one-way incoming forest trusts. The right to create a forest trust can be delegated. To create the forest trust from one location, you must also have like credentials for the other forest.

Forest trust creation consists of three steps:

Prepare the forest for forest trust creation.

Create the trust.

Configure resource assignment.

Prepare the Forest

Two steps are necessary: providing name resolution via DNS and changing functional level to or verifying that functional level is Windows Server 2003. A third step, removing external trusts between the forests, may be necessary.

If name resolution is not working, the trust relationship will fail. There are several alternatives for ensuring name resolution between forests. Only one of them needs to be done.

Make one root DNS server authoritative for both forest DNS namespaces. (The root zone contains delegation for each of the DNS namespaces and updated root hints of all DNS servers with the root DNS server.) Zone delegation can be verified using nslookup.

If both forest root DNS servers are running Server 2003, configure conditional forwarders in each namespace to route queries for names in the other namespace.

Configure secondary zones in each DNS namespace to route queries for names in the other namespace.

If both forests are not at Windows Server 2003 functional level, the trust will fail.

If an external trust exists between domains in the two forests, the forest trust cannot be completed. Before starting the New Trust Wizard, remove any external trusts that may prevent it from completing. (External trusts with domains in forests other than the two forests between which a forest trust will be completed are okay.)

Create the Trust

To create a forest trust follow these steps:

Log on as a member of Domain Admins in the forest root domain or as a member of Enterprise Admins and click Start, Administrative Tool, Active Directory Domains and trusts. This domain is now identified as the "local" domain in the screenshots and documentation.

Right-click the domain node for the forest root domain and select Properties from the context menu.

Select the trust tab, click New TRust, and then click Next.

Enter the DNS name or NetBIOS name of the other forest. This forest is identified as the "specified" domain in the screenshots and documentation.

Select Forest Trust and then click Next.

On the Direction of Trust page, select the trust direction, as shown in Figure 8-34, and click Next. For this example, a two-way trust is selected.

Figure 8-34. Selecting direction of trust.

Select the Incoming Trust Authentication Level, as shown in Figure 8-35, and then click Next.

Figure 8-35. Selecting outgoing trust authentication level.

Select the Outgoing Trust Authentication Level and click Next.

Note the summary information and then click Next.

10.

Select Yes, confirm the outgoing trust and then click Next.

11.

Enter the user name and password from the other forest authorized to create a trust relationship and click OK.

12.

Select Yes, confirm the incoming trust and then click Next.

13.

Review Trust status and then click Next.

14.

In the trust properties page, note that the specified domain name is listed in the TRusted (outgoing trusts) and trusting (incoming) trust boxes, as shown in Figure 8-36.

Figure 8-36. Confirming trust.

Grant Permissions to Resources in Trusting Forests

Granting access to resources across forests is similar to granting access across domains. The trust must be in place, and if selective authentication is chosen, the Allowed to Authenticate permission must be granted to the groups of users that should have this permission. If users are granted access to resources before the Allowed to Authenticate permission is granted to them, the users will still not be able to access the resources.

To grant the Allowed to Authenticate permission, add the group to the security property page of the domain controller and then select the Allowed to Authentication permission, as shown in Figure 8-37. The property page of the domain controller can be accessed from the Domain Controller OU. To grant the permissions, use the Security tab of the resource and then the object picker to select the group. When you open the object picker, be sure to select the location. In the Locations box, the trusted forest will be shown at the same level as the entire local directory, as shown in Figure 8-38. You must select it and click OK to be able to search for groups to include. On computers that are not Windows XP SP2 or Windows Server 2003, you cannot browse user and group names to select and then assign access. Instead, you must enter User Principal Names (UPN, or user@domainname format) or Windows NT 4.0-style names (domainname\username). In addition, users wanting to use workstations in the trusting forest to log on to domains in the trusted forest (where their accounts are) must use the UPN or Windows NT 4.0 format. They will not be able to select the domain names from a drop-down list in the logon screen.

Figure 8-37. Grant user groups permission to authenticate to domains in the trusting forest.

Figure 8-38. Selecting the location of groups across aforest trust.

Cross-forest trusts include new challenges. Before you attempt to grant access to users from another forest, you should ensure that the time between the forests is synchronized. This might be done via a designated timeserver in the organization or via a public timeserver. If time is not synched, you cannot read the list of user and group accounts in the domain in the other forest.

Protecting Forests in a Cross-Forest Trust from an Elevation of Privileges Attack

Unless selective authentication is chosen during trust creation, it is possible for users to authenticate to their home domain across forest boundaries, and it may be possible for them to access resources in the trusting forest without having an account in any domain in that forest and before resources have been explicitly configured to allow their access. This is because the group Everyone is assigned access to some resources and because anonymous access may be available on one or more computers in the trusting forest. In other words, the security boundary of a forest is pierced when a forest trust relationship is created and the possibility of successful elevation of privilege attacks is increased. Three mechanisms exist that can help mitigate this effect:Piercing Security BoundariesThe Ultimate Forest Design Issue" and in the document "Planning and Implementing Federated Forests in Windows Server 2003," available at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/maintain/security/fedffin2.asp.