Enabling Multiple Forest Scenarios in Windows Server 2003

Applies To: Windows Server 2003 with SP1

The Windows Server 2003 technologies that are discussed in the previous section each help to enable a specific functionality across multiple forests. Note that these technologies are limited to trust management, authentication, and authorization problems.

You must use other technologies and tools to address other parts of the problem, such as synchronization of address books, user migration, DNS configuration, and so on. The following section describes how you can use each of the technologies that are discussed in this paper to enable the scenarios for multiple forests that were discussed earlier in this document. It also provides pointers to the other tools that you must use to solve the other parts of the problem.

Multiple Forests That Are in the Same Corporation

The first step that you should use when you want to deploy multiple forests in the same corporation is to ensure that you can perform DNS lookups from one forest to look up the domain controllers that are in the other forest. If the forests already use the same DNS infrastructure, then you do not need to perform any of the additional work. If the forests do not use the same DNS infrastructure, you can either merge the DNS infrastructures or you can use conditional forwarding.

After you configure DNS, set up a bidirectional forest trust between the contoso.com and hr.contoso.com forests. Because plant.contoso.com does not contain any user accounts that need to gain access to resources that are in the other forest, a trust that is one way is set up by the administrator to each of the other forests. You should not enable the Selective Authentication option in this scenario because there are a considerable number of users in each of the forests who need to gain access to resources that are in the other forests, and because the administrators for each forest feel more comfortable treating the users who are in the other forest as authenticated users. In addition, the users who are in the contoso.com forest should be able to look up users who are in the hr.contoso.com forest when they use the Exchange Server address books for sending e-mail messages. You can do this by using Microsoft Metadirectory Services (MMS) to synchronize the address books for both forests.

Because the hr.contoso.com forest trusts the plant.contoso.com forest for the plant.contoso.com TopLevelName and because the hr.contoso.com forest also trusts the contoso.com forest for the contoso.com TopLevelName, there is a namespace collision because the TopLevelName record for contoso.com also includes plant.contoso.com. To remove this collision, you must exclude the plant.contoso.com namespace from the contoso.com forest trust. You can do this by setting a TopLevelName exclusion record in the FTInfo record for the hr.contoso.com forest for its trust to contoso.com. Similarly, you must set up another exclusion record in the plant.contoso.com forest to exclude the hr.contoso.com namespace from the trust to the contoso.com forest. However, you do not need to set up an exclusion record in contoso.com because the plant.contoso.com and hr.contoso.com namespaces do not overlap.

In addition, the administrator for the contoso.com forest also does not want to trust the test.hr.contoso.com domain, which is a test domain in the hr.contoso.com forest. Because of this, the administrator can disable the DomainInfo record for the test.hr.contoso.com domain that is in the trust record for hr.contoso.com. When you do this, you ensure that the authentication that is performed by the test.hr.contoso.com domain is not accepted by contoso.com. Note that it is easier for you to use the Explicit Deny option that is in the forest trust, instead of the Selective Authentication option that is in this scenario because you want to prevent authentication for all principals that are in a specific domain that is in a trusted forest to any resource that is in the trusting forest. Note also that you disable authentication requests that are from users in a domain when you disable the DomainInfo record for a particular domain that is in a trusted forest. When you do this, authentication to resources that are in that domain are not disabled.

Figure 6: Multiple Forests That Are in the Same Corporation Deployment

Multiple Forests That Are in Different Corporations

Unique challenges are presented when you want to deploy multiple forests that are in different corporations. Not only do the trusts have to traverse firewalls, but you have to ensure that all of the resources are well managed so that users from another forest do not accidentally gain access to resources that they are not supposed to see.

In this scenario, Fabrikam and Contoso establish a forest trust. Each company also enables the Selective Authentication option. When the administrators enable the Selective Authentication option, the authentications that occur across the trust do not work automatically. The administrators must explicitly enable authentications across the trust. The administrator for the Contoso forest then sets a DACL on the marketing group's file server computer account so that members of the marketing group who are in the Fabrikam forest can authenticate to it. After this procedure, the administrator sets another DACL on the service account for the Web server so that all users who have the Authenticated Users SID can authenticate to it. The administrator of the Contoso forest configures the contoso.com forest in the same way that the Fabrikam administrator configured fabrikam.com. Note that one of these forests may be an extranet forest.

The administrators for both Contoso and Fabrikam create the trust independently by using the Netdom tool (Netdom.exe). After the administrators create the trusts, they try to validate the trust so that the Netlogon fixed port and the RPC Endpointmapper port can be opened (between the domain controllers in each domain) for this operation. The administrators can close the ports after the trust is validated. The administrators for both Contoso and Fabrikam then create the following firewall rules.

Firewall rules enable authentication and lookups to work between both the corporations. Note that the administrators can also choose to have an Internet Protocol Security (IPSec) tunnel for the traffic that is described in the previous table by opening only the ports for IPSec. Most of the default Windows services use the negotiate package which first uses Kerberos for authentication and then uses NTLM when certain authentications do not work. If you also need NTLM authentication, you need to open the appropriate ports. These ports are specified in the "List of Ports" section in Appendix A in this document.

Figure 7: Multiple Forests That Are in Different CorporationsDeployment

Perimeter Network Scenario

In a perimeter network (also known as a DMZ, demilitarized zone, and screened subnet) forest, a trust that is one way from the perimeter network forest to the contoso.com corporate forest is established. This allows the users in the internal forest to be able to gain access to the resources in the perimeter network forest with their internal forest accounts. In this scenario, a two-way trust is not recommended, because compromise of the perimeter network forest will then provide a malicious user with an entry point into the corporate forest. Because of this, the administrator creates the following firewall rules.

In this table:

• The "trust creation" rule needs to be applied by the administrator only when the trust is initially created. This rule allows trust creation for both domains from the internal forest and is immediately disabled after you create the trust.

• The "Kerberos authentication outbound rule" is always applied by the administrator to allow internal users to authenticate to the perimeter network forest.

• The "inbound DACL lookups" rule is applied by the administrator only when there needs to a change to the domain local groups in the perimeter network to add either global or universal groups from the internal forest. These changes should be minimal.

Figure 8: Perimeter Network ScenarioDeployment