One of the most important decisions that you need to make when designing Active Directory for your organization is whether to implement a single forest or multiple forests. This decision has a major effect on how the administration of your Active Directory is performed and whether you have to duplicate any effort to ensure that consistent security is deployed across the enterprise network.
After this lesson, you will be able to
Estimated lesson time: 30 minutes
Anyone who designs an Active Directory for an organization needs to know common terms used in Active Directory design. These common terms and concepts include
Figure 2.1 A forest with three domain treesThe microsoft.com tree includes the microsoft.com, east.microsoft.com, and west.microsoft.com domains. Each of the three domains contains microsoft.com as part of the domain name. The msn.com tree includes the msn.com domain, the usa.msn.com domain, and the ca.msn.com domain. Finally, there's the hotmail.com domain.
An OU that exists within another OU is commonly referred to as a child OU. The OU that contains the child OU is referred to as a parent OU.
The most common configuration for deploying an Active Directory in an organization is a single forest. The main reason to deploy a single forest is that it will share common information across each of its component domains. The information that is shared includes
The domains within a forest are joined together by Kerberos v5 transitive trust relationships. These differ from Windows NT 4.0 trust relationships in that if a domain trusts another domain, it also trusts all other domains trusted by that domain. For example, in Figure 2.2 a user in the asia.microsoft.com domain can access resources in the namerica.microsoft.com domain, even though an explicit trust relationship isn't defined between the two domains. Due to the transitive nature of Kerberos v5 trusts, the transitive trust relationships between namerica.microsoft.com and microsoft.com and between asia.microsoft.com and microsoft.com provide access as required.
It's always recommended to begin your Active Directory design with the intention of deploying a single forest. You should change your Active Directory design to include multiple forests only if your business circumstances require them.
Figure 2.2 Default transitive trust relationships
The only exception to this is when you are testing schema modification changes. Because any change made to the schema is permanent and can't be deleted in Windows 2000, you should maintain a DC in a separate forest to test all schema modifications before deploying them in a production environment.
Consider implementing a single forest for your enterprise if your organization meets the following criteria:
Sometimes you might want to define shortcut or cross-link trust relationships within a forest. These shortcut trusts will speed authentication when a resource is accessed in a domain other than where the security principal accessing the account resides.
The description of Wide World Importers hasn't included any business case that would require the deployment of multiple forests. Even though Wide World Importers has distribution and service centers spread across national boundaries, this isn't a sound business reason for creating separate forests.
With a standardized set of applications and the need to centrally manage user account creation from the head office, these circumstances lead you to decide on a single forest for the Wide World Importers network.
There are limited scenarios in which you have to implement multiple forests. These scenarios generally involve decentralized organizations that perform much of their network operations within each individual sector. Another common scenario is an Internet Service Provider (ISP) that doesn't want to have a common directory for all their clients. It's preferable in this case to create separate forests for each client to prevent clients from browsing the directory of another client of the ISP.
You face some additional difficulties when you deploy multiple forests, so don't make this decision hastily. These disadvantages range from actual monetary costs to a loss of functionality or flexibility in your network design. Possible problems include:
Figure 2.3 Establishing trust relationships between multiple forests
In conclusion, the decision to implement multiple forests most affects the users within your network. Only in a single-forest environment does the global catalog contain a partial replica of all objects in the organization. Deploying multiple forests can result in loss of functionality for the users within an organization.
That said, there are several cases where an organization might want to deploy multiple forests. When the following situations exist within your organization, you can consider implementing multiple forests instead of a single forest:
Any modifications to the schema are permanent. You can never remove any classes or attributes that are added to the schema. They can only be marked as defunct.
Trust relationships must be established between domains in the two forests. You can't simply establish a trust relationship between forests.
Because you have decided to deploy a single forest for Wide World Importers, this section examines scenarios that would make Wide World Importers consider deploying additional forests due to altered circumstances.
If Wide World Importers merged with another company through either a takeover or acquisition, the other organization might already have a Windows 2000 Active Directory. For the initial merger period, you can maintain separate forests to allow connectivity between the two forests.
The existence of separate forests requires more management for the corporate network. Explicit trust relationships must be defined between domains where resource access must take place. In addition, if the long-term goal is to merge the two organizations into a single forest, you have to analyze details such as the schema modifications that might have occurred to ensure a smooth transition to a single forest.
You must consider the decision to implement more than one forest in an organization carefully. Most often the advantages of a single forest far outweigh the factors that would lead you to implement multiple forests on anything other than a temporary basis.