Technologies for Federating Multiple Forests
Applies To: Windows 7, Windows 8, Windows 8.1, Windows Server 2003 with SP1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Vista, Windows XP
This section describes the technologies that are included in Windows Server (beginning with Windows Server 2003) that address the problems that are associated with multiple forest deployments.
Forest Trust
A forest trust makes federated forests possible in Windows Server. A forest trust enables a transitive trust between all of the domains in two forests. Microsoft recommends a forest trust be created between forests rather than an external trust. A forest trust ensures that Kerberos is used whenever possible. Kerberos provides better security and scalability over NTLM.
A forest trust is established between the root domain of both forests. Forest trusts can be one-way or two-way trusts. In Figure 4, Forest A and Forest B have a bidirectional trust between each other. Because of this, users in Forest A can authenticate to resources in Forest B and users in Forest B can authenticate to resources in Forest A. In addition to authentication, the trust enables authorization so that the resource owners in each forest can add principals from the other forest to discretionary access control lists (DACLs) and groups.
.gif "Art Image")
Figure 4: Forest Trust
Forest Trust Requirements
Before you can create a forest trust, you need to verify that all domain controllers in both forests are running Windows Server 2003. You also need to verify that you have the correct Domain Name System (DNS) infrastructure in place and that you have established the appropriate functionality level for Active Directory. This means that the forest has to be raised to the Windows Server 2003 functional level and you cannot add any more Windows 2000 or Windows NT Server 4.0 domain controllers to the forest.
To create a forest trust, the person who will create the trust in Fabrikam and Contoso must have Enterprise Admin privileges in the corresponding forest. Each trust is assigned a password that the administrators in both forests must know. An administrator who has Enterprise Admin privileges in both forests can create the trusts in both Fabrikam and Contoso at one time and, in this scenario, a password that is cryptographically random is automatically generated and written for both forests.
Both Windows NT Server 4.0 and Windows 2000 clients can use the forest trust for authentication. However, Windows NT Server 4.0 clients support only NTLM and they do not support user principal names (UPNs) for logging on to the network.
External Trusts vs. Forest Trusts
External trusts are used to enable trusts between two domains that are in different forests. A forest trust is similar to an external trust between the root domains of both forests, but it takes the trust one step further to encompass all of the domains. The basic trust information (for both external trust and forest trust) is represented by a trusted domain object (TDO). The TDO for an external trust contains the name of the other domain with which the trust is established, its domain security identifier (SID), the trust direction, the type of trust, and some other attributes.
When there is a forest trust, the trust is marked as "Forest." The TDO also contains an additional Forest Trust Information attribute. The Forest Trust Information attribute contains information about all of the domains in the remote forest, the tree names, and any alternate name suffixes. This information is used to route authentication and lookups to the remote forest when needed. This information is propagated to the global catalogs so that any domain controller can look it up. The TDOs are stored in the Domain container that is in Active Directory.
The tree names and alternate name suffixes are stored in TopLevelName (or TLN) records. The DNS name, network basic input/output system (NetBIOS) name, and SID for every domain is stored in DomainInfo records. Because of this, the forest trust contains enough information to reasonably determine which services or users can reside in the other forest.
The following table shows the key differences between both external and forest trusts.
Table 1 External vs. Forest Trusts
| External trust | Forest trust | |||
|---|---|---|---|---|
TDO |
Yes |
Yes |
||
Top level names |
No |
Yes |
||
DomainInfo (for every domain) |
No |
Yes |
||
Kerberos V5 support |
The following prerequisites must be in place to allow Kerberos to function over an external trust:
|
Yes |
||
Object picker browsing |
Yes |
Yes |
||
NTLM support |
Yes
|
Yes |
||
UPN logons |
Implicit and explicit UPNs where the suffix matches the AD DS DNS domain name. Note Certificate logons may fail if the UPN suffix in the certificate does not match the AD DS domain name. |
Implicit and explicit UPNs |
.gif "note")
NoteRouting of Kerberos Authentication
After you establish the forest trust, Kerberos and NTLM authentication are routed accordingly to the other forest so that they can validate user credentials.
With Kerberos, users receive a Ticket Granting Ticket (TGT) when they log on to the computer. When users need to be authenticated to a resource, the TGT is presented to their domain controller, and then the domain controller returns a service ticket to authenticate. This is accomplished through a Kerberos ticket granting service (TGS) request. If the resource is in another domain, the users’ domain controller cannot issue the service ticket. Instead, the domain controller issues a referral for the user to contact the resource domain controller if it has a direct trust to it. If there is no direct trust, the domain controller issues a referral to the next domain controller that is in the trust chain. The final resource domain controller then issues the service ticket to the user. If the resource is in the same forest, the user's domain controller can determine if the resource is in the same forest by querying the global catalog.
If a resource is in another forest that is connected by a forest trust, the global catalog does not have information about all of the resources that are in the other forest. However, the global catalog can determine which forest contains this resource by searching the forest trust information for all of the forest TDOs. After the information is determined, the referrals are issued so that the user reaches the local forest root. The local forest root then refers the user to the root of the trusting forest. After the referrals reach the trusting forest, the user is then authoritatively referred to the resource domain controller to obtain the service ticket.
If a user from a trusted forest is logging onto a computer in the trusting forest, the Kerberos Authentication Service (AS) requests are routed in a similar manner. However, when this occurs, the user does not have to traverse all of the domains that are in the trust path; the user is instead directly referred to the root domains and then to a domain controller that contains the users account that is in the other forest.
.gif "Art Image")
Figure 5: Authentication Process to Another Forest
Figure 5 shows how the client uses Kerberos to authenticate to a service in the other forest:
Clients contacts the domain controller (DC1) to request a service ticket to use the service.
The domain controller cannot find the service in its domain, so the domain controller queries a global catalog. After examining the forest trust information, the global catalog sends a hint that the service is probably in the other forest, and the domain controller issues a referral to its parent.
The client then contacts the parent root domain controller (DC2) to request a service ticket to use the service. The root domain controller (DC2) sends the client a referral to the root domain controller (DC3) for the other forest.
The client then contacts the root domain controller (DC3) that is in the other forest to request a service ticket to use the service. In this example, the root domain controller (DC3) determines that the service is in its own forest after querying the global catalog in its forest, and then the root domain controller (DC3) refers the client to the next domain controller (DC4) in the trust path.
The client then contacts the next domain controller (DC4) to which it is referred (the service domain controller) to request a service ticket. Because this domain controller determines that the service is in its domains, it issues a service ticket to the client.
The client then presents this service ticket to the server in a Kerberos KERB_AP_REQ message. The server responds, which establishes a secure communication channel.
How the Object Picker Tool Works
You can use the Object Picker command-line tool to add users or groups to DACLs on resources and as members of other groups. For example, if the administrator in the trusting forest needs to add a user from the trusted forest to a group in the trusting forest, the administrator opens the Active Directory Users and Computers Microsoft Management Console (MMC) Snap-in, clicks the desired group, and then clicks Add members. The Object Picker tool then prompts the administrator to type the name of the remote forest user. First, Object Picker tries to locate the domain in which the user is located. Because the user is from another forest, the local global catalog cannot find the user name in its forest. The global catalog then examines the forest trust information to determine if the requested object might be in a different forest. If it is possible that the object might be in a different forest, a referral is sent to Object Picker to contact a global catalog in the other forest. The Object Picker tool then contacts the global catalog in the remote forest to authoritatively determine which remote forest domain holds the queried object. After this is determined, Object Picker connects to a domain controller in that domain, and then performs a Lightweight Directory Access Protocol (LDAP) search to retrieve certain attributes of the object, such as its security identifier (SID). After this information is obtained, you can set the DACL or modify group membership.
Object Picker support for selecting objects from a trusted forest is available on computers that are running the Microsoft Windows XP operating system or an operating system that was released later than Windows XP. Note that you have to type the full UPN of the user or group when you use Object Picker to select objects from a trusted forest. Object Picker browsing, which allows you to use wildcard characters in searches, is available on computers that are running Windows Server 2003.
Note that you must have credentials in the remote forest if you want to look up a user from a remote forest. If there is a two-way trust, then the remote forest also trusts the local forest and the default local forest credentials are used. If the local forest trusts only the remote forest, the user in the local forest is prompted for credentials in the remote forest by the Object Picker tool.
Note
Group membership rules prevent both Universal and Global groups from containing members from another forest.
A best practice for Active Directory is to have a global group in each domain that contains users in that domain and to add these global groups to a domain local group that is in the resource domain.
SID Filtering
When authentication requests come from a trusted forest, you trust that forest to have properly validated the users’ credentials. However, you also receive authorization information in the form of a list of security identifiers (SIDs), along with the authentication request. If any of the SIDs correspond to the Enterprise Administrator's SID (or to a similar privileged group or user SID) of the trusting forest, then the user from the trusted forest receives elevated rights to resources. To protect against the possibility of the trusted forest assigning counterfeit SIDs, the operating system always filters the SIDs to verify that they are relative to one of the domain SIDs in the trusted forest. This procedure ensures that the trusted forest issues authorization information only for domains for which it is authoritative. For example, when the domain controller of the root domain of the fabrikam.com forest receives the request from the client, it filters the SIDs in the request to verify that the client is not passing any unauthorized SIDs (see step 4 in Figure 5). SID filtering is automatically enabled across all trust relationships.
SID filtering on forest trusts breaks SID history across forests. If a user from the fabrikam.com forest migrates to the contoso.com forest, the SID history of the users contoso.com account contains the SID of the user's user account in the fabrikam.com forest. When the user tries to gain access to resources that are in the fabrikam.com forest by using the user's contoso.com account, the fabrikam.com account SID is presented with the SIDs from contoso.com. The fabrikam.com root domain domain controller determines that the fabrikam.com account SID that is presented by the user is not authorized to be presented by a user account in the contoso.com forest and filters it out. This breaks SID history because the user does not have access to the user's previous resources.
If the trusted forest administrator can be trusted not to spoof unauthorized SIDs, you can allow SID History to traverse the forest trust. To do this, use the netdom command-line tool (Netdom.exe) with the /enablesidhistory:yes option. To allow users to access shared resources in their original domain over an external trust, ensure that SID filter quarantining is disabled. To do this, use the netdom tool with the /quarantine:no option. The Netdom tool is included with the Windows Server 2003 support tools. You can install Windows Server 2003 support tools from the Support\Tools folder on the Windows Server 2003 CD. To do this, right-click the Suptools.msi file in the Support\Tools folder, and then click Install. As an alternative, you can install support tools from the Microsoft Download Center. To download the support tools, see Windows Server 2003 Service Pack 2 32-bit Support Tools (https://go.microsoft.com/fwlink/?LinkId=100114).
For more information about SID filtering and SID spoofing, see Microsoft Help and Support (https://go.microsoft.com/fwlink/?LinkID=69288).
Selective Authentication
The Selective Authentication option is conceptually similar to the network firewall in the way that it works. In the same way that a network firewall allows only certain network access requests through the firewall, the Selective Authentication option allows only specific authentication requests. For more information about how to enable the Selective Authentication option, see the "Walkthroughs" section in this document.
The Problem of Authenticating Users from a Trusted Forest
When users authenticate from a trusted forest, they receive the Authenticated Users SID in their token. Many of the default rights for users in a forest are granted through the Authenticated Users SID. Because the Authenticated Users group is a computed group and its SID is added on the server to which the user authenticates, you cannot change the membership of the group. Because of this, the users from the other forest receive some default rights to all of the resources that are in the trusting forest that are accessible by the Authenticated Users group after you set up a forest trust. You may not want to do this if the trust is set up only to allow access to a small subset of users who are in the trusted forest.
The Solution
The Selective Authentication option provides a method that you can use to grant limited rights for authentication requests that come across a trust. When you enable the Selective Authentication option, all authentication is examined on the service domain controller. The service domain controller verifies that the user is explicitly allowed to authenticate to the resource before allowing the authentication request through. Because of this, you need to specify which users who come across the trust can authenticate to which resources in the domain when you enable the Selective Authentication option across a trust. You can do this if you set up the "Allowed to Authenticate" control access right on an object for that particular user or group from the other forest or domain. When a user authenticates across a trust with the Selective Authentication option enabled, a special "Other Organization" SID is added to the users authorization data. The presence of this SID triggers a verification on the service domain to ensure that the user is allowed to authenticate to the particular service. After the user is authenticated, the server to which the user authenticates adds another SID, the "This Organization" SID. (The "This Organization" SID is added if the "Other Organization" SID is not already present.) For example, if the user did not authenticate across a trust with the Selective Authentication option enabled, only then is the "This Organization" token present. Because of this, only one of these special SIDs can be present in an authenticated user's context.
Trust Port Configurations
Trusts need to be deployed across various network boundaries. Because of this, the trusts may have to span one or more firewalls. When this is required, you can either tunnel the traffic across a firewall or open specific ports in the firewall to allow the trust traffic to pass through. In Windows Server 2003, this procedure is simplified through configurable remote procedure call (RPC) ports for the main trust services. The two main configurable RPC ports are:
The Local Security Authority (LSA) RPC port. This port is used for trust creation and other access to the LSA policy database: TCP/IPPort entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry key.
-and-
The Netlogon RPC port. This port is used for NTLM and secure channel: DCTcpipPort entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry key.
To view a full description of the ports that you can open for different scenarios, see the "List of Ports" section in Appendix A in this document.