Accessing resources across forests

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Accessing resources across forests

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests. For more information about routing authentication requests across forests, see Routing name suffixes across forests.

Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other forest. An SPN can be one of the following:

• Domain Name System (DNS) name of a host

• DNS name of a domain

• Distinguished name of a service connection point object

When a workstation in one forest attempts to access data on the resource computer in another forest, Kerberos contacts the domain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global catalog and identifies that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and follows the referral chain until it gets to the domain where the resource is located.

The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when computers running Windows 2000 Professional, Windows XP Professional, Windows 2000 Server, or a member of the Windows Server 2003 family attempt to access resources from a computer located in another forest.

1. User1 logs on to Workstation1 using credentials from the child.microsoft.com domain. The user then attempts to access a shared resource on FileServer1 located in the msn.com forest.

2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 SPN.

3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the microsoft.com forest contain this SPN. Since a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found, the global catalog provides a routing hint back to ChildDC1.

4. ChildDC1 sends a referral for its parent domain back to Workstation1.

5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the msn.com forest.

6. Workstation1 contacts ForestRootDC2 in the msn.com forest for a service ticket to the requested service.

7. ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.

8. ForestRootDC2 then sends the referral to child.msn.com back to Workstation1.

9. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.

10. Now that workstation1 has a service ticket, it sends the server service ticket to FileServer1, which reads User1's security credentials and constructs an access token accordingly.

When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a TDO. Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are replicated to the global catalog. For more information about TDOs, see Trusts.

Routing hints

Routing hints are only used when all traditional authentication channels (local domain controller and then global catalog) have failed to produce a location of a SPN. Routing hints help direct authentication requests toward the destination forest.

When an SPN cannot be located in the domain from where the network logon request originated or from the global catalog database, the global catalog checks the forest trust TDO for trusted name suffixes located in the other forest that might match the suffix in the SPN. If a match is found, the forest root domain returns a routing hint back to the original source computer so that it can continue the SPN location process in the other forest.

Notes

• Routing hints can only reference trusted name suffixes that are listed in the TDO for its forest trust. They do not verify the name suffix before sending the hint back to the original source computer.

• Accessing NetBIOS names and Kerberos delegation across forest trusts is not supported. NTLM is fully supported and cannot be disabled.

Planning your access control strategy for multiple forests

It is recommended that you carefully plan the most efficient access control strategy for your organization's resource needs. Your design and implementation of security groups throughout each forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple domains, see Accessing resources across domains.

It is important to understand the following security group concepts before you begin the planning process:

• Security groups. User rights can be applied to groups in Active Directory while permissions can be assigned to security groups on member servers hosting a resource. For more information, see Group types.

• Group nesting. The ability to nest security groups is dependent on groups scopes and domain functionality. For more information, see Nesting groups.

• Group scope. Group scope helps determine the domain-wide and forest-wide access boundaries of security groups. For more information, see Group scope.

• Domain functionality. The domain functional level of the trusting and trusted domains can affect group functionality such as group nesting. For more information, see Domain and forest functionality.

Once you have gained a thorough understanding of security group concepts, determine the resource needs of each department and geographical division to assist you with the planning effort.

Best practices for using security groups across forests

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other forests. Consider the following best practices:

• To represent the sets of users who need access to the same types of resources, create role-based global groups in every domain and forest that contains these users. For example, users in the Sales Department in ForestA require access to an order-entry application that is a resource in ForestB. Account Department users in ForestA require access to the same application, but these users are in a different domain. In ForestA, create the global group SalesOrder and add users in the Sales Department to the group. Create the global group AccountsOrder and add users in the Accounting Department to that group.

• To group the users from one forest who require similar access to the same resources in a different forest, create universal groups that correspond to the global group roles. For example, in ForestA, create a universal group called SalesAccountsOrders and add the global groups SalesOrder and AccountsOrder to the group.

  Note

  Universal groups are not available as security groups in Windows 2000 Server mixed-mode domains or in Windows Server 2003 domains that have a domain functional level of Windows 2000 mixed. They are available as distribution groups.

• To assign permissions to resources that are to be accessed by users from a different forest, create resource-based domain local groups in every domain and use these groups to assign permissions on the resources in that domain. For example, in ForestB, create a domain local group called OrderEntryApp. Add this group to the access control list (ACL) that allows access to the order entry application, and assign appropriate permissions.

• To implement access to a resource across a forest, add universal groups from trusted forests to the domain local groups in the trusting forests. For example, add the SalesAccountsOrders universal group from ForestA to the OrderEntryApp domain local group in ForestB.

When a new user account needs access to a resource in a different forest, add the account to the respective global group in the domain of the user. When a new resource needs to be shared across forests, add the appropriate domain local group to the ACL for that resource. In this way, access is enabled across forests for resources on the basis of group membership.

For more information, see Set permissions on a shared resource.

Selective authentication between forests

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two forests that are joined by a forest trust. You can set selective authentication differently for outgoing and incoming forest trusts. With selective trusts, administrators can make flexible forest-wide access control decisions. For more information about how to set selective authentication, see Select the scope of authentication for users.

If you use forest-wide authentication on an incoming forest trust, users from the outside forest have the same level of access to resources in the local forest as users who belong to the local forest. For example, if ForestA has an incoming forest trust from ForestB and forest-wide authentication is used, users from ForestB would be able to access any resource in ForestA (assuming they have the required permissions).

If you decide to set selective authentication on an incoming forest trust, you need to manually assign permissions on each computer in the domain as well as the resources to which you want users in the second forest to have access. To do this, set a control access right Allowed to authenticate on the computer object that hosts the resource in Active Directory Users and Computers in the second forest. Then, allow user or group access to the particular resources you want to share.

When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user's authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, then the server to which he authenticates adds the This Organization SID if the Other Organization SID is not already present. Only one of these special SIDs can be present in an authenticated user's context. For more detailed information about how selective authentication works, see Security Considerations for Trusts.

Administrators in each forest can add objects from one forest to access control lists (ACLs) on shared resources in the other forest. You can use the ACL editor to add or remove objects residing in one forest to ACLs on resources in another forest. For more information about how to set permissions on resources, see Set permissions on a shared resource.

For information about setting authentication restrictions for external domains, see Accessing resources across domains.