Multiple Forest Deployment Scenarios

Applies To: Windows Server 2003 with SP1

You may need multiple forests for various reasons. You may need to have different schemas, political divisions between resource owners, lack of trust in another organization's administrative infrastructure, mergers and acquisitions, geographically distributed business units, and so on.

There are two generic reasons why you may need to deploy multiple forests.

• You may need to deploy multiple forests for administrative autonomy. Separate departments do not trust each others administrators (for political or security reasons) or cannot agree on a common change control policy (for directory schema and configuration).

  -and-

• You may need to deploy multiple forests for asset isolation. Governmental agencies and business units that have become conglomerated through mergers and acquisitions sometimes maintain completely separate computing infrastructures for security or budgetary reasons; application service providers create separate infrastructures for outsourcing large business customers. The "Design Considerations for Delegation of Administration in Active Directory" white paper provides the following reason for why you may want to use multiple forests:

  Because data stored in Active Directory and on computers joined to Active Directory cannot be isolated from the service administrators of the directory, the only way for an organization to achieve complete data isolation is to create a separate forest.

  You can view the Microsoft TechNet "Design Considerations for Delegation of Administration in Active Directory" white paper at https://go.microsoft.com/fwlink/?LinkID=91034.

Multiple Forests in the Same Corporation

In a single corporation, the preferred approach is to deploy a single forest. However, for the reasons that are listed in the previous section, you may need to deploy multiple forests. In most scenarios, the forests should be connected by using dedicated leased lines or virtual private networks (VPNs), which allow the necessary data traffic to flow between the forests. If there are packet filters or firewalls, they usually have an "allow all, deny explicit" approach. The administrators for the two forests may be the same people, or they may be different people, but they may want to treat users from the other forest in the same way that they treat users from their own forests.

Consider the following example. There are three forests in the Contoso, Inc. Corporation: contoso.com, plant.contoso.com, and hr.contoso.com. The Human Resources (HR) department has its own forest because it has a program that requires schema changes. The IT department of the HR organization wants to retain control over these changes without going through the central IT department. In addition, the hr.contoso.com forest has a test domain that the contoso.com forest wants to exclude from the trust relationships.

The Fabrikam manufacturing plant also needs to run a program that uses Active Directory. In this scenario, they needed a separate forest because the domain controllers have to be placed on the floor at the manufacturing plant; everyone in the plant will have physical access to the domain controllers.

Figure 1: Multiple Forests in the Same Corporation

Multiple Forests in Different Corporations

Each organization will have its own forests. However, in a business-to-business (B2B) scenario, collaboration between a forest in one organization and a forest in another organization is necessary. In this scenario, trust also needs to be established between these two forests. However, the administrators in the each forest want only the users in the other forest to have access to a limited set of resources. The two forests might be connected through dedicated leased lines or through VPN connections, but only limited traffic is allowed between the two forests. Because of this, the firewalls typically have rules that deny all traffic and allow only the traffic that is explicitly allowed.

In this scenario, Contoso.com and Fabrikam.com have partnered together to jointly market their toothpaste and toothbrush combination product. However, they would like to restrict access to each others project files to the marketing teams from the other side because much of the collaboration is related to marketing. To keep employees aware of the general progress, both companies want to open their internal news Web site to all of the employees in the other corporation.

Figure 2: Multiple Forests in Different Corporations

Perimeter Network Scenario

An organization might need to publish resources in the perimeter network (also known as DMZ, demilitarized zone, and screened subnet) and run programs that need Active Directory. However, deploying a separate domain of the internal forest on the perimeter network is not recommended, because it becomes an easy staging point from which to compromise the entire internal forest if the external domain is compromised. Because of this, you must deploy a separate forest in the perimeter network if someone wants all of the administrative and security benefits of managing the perimeter network servers in a domain.

In this scenario, the administrators of contoso.com want to have a separate forest, called dmz.contoso.com. They have a Web application that is running in the perimeter network that uses Windows Live ID authentication so that users can gain access to a portal. The administrators also want to allow users in the internal forest to publish resources to the perimeter network forest. Because of this, the users in the internal forest need to be able to gain access to the resources that are in the perimeter network by using their internal forest accounts.

Figure 3: Perimeter Network Scenario