Lesson 1: Designing Your Forest Structure | MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)

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

Determine the number of forests required for your organization based on security and business requirements

Estimated lesson time: 30 minutes

Active Directory Design Basics

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

Forest. A forest is a collection of domains that share a common schema, configuration, and global catalog. All domains in a forest are connected using transitive trust relationships.
Domain Tree. A domain tree is a collection of domains that share a contiguous name space. For example, Figure 2.1 shows a forest with three domain trees.

Figure 2.1 A forest with three domain trees

The 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.
Domain. A domain represents a unit of replication within Active Directory. You can break up your forest for replication and account policy purposes by creating multiple domains within a forest.
Organizational Unit (OU). An OU is a container that's used to organize security principals for the purpose of deploying Group Policy and delegating administrative authority. OUs can exist within domains or other OUs.
NOTE
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.
Sites. Sites are used within Active Directory to represent the physical network that exists for an organization. A site is defined as a section of the network with high network speeds. For example, if you had an office with two locations, one in Seattle and the other in San Francisco, you should define two sites based on the geographical location. Sites are used within Active Directory to find network services that are in the same network location as the client attempting to connect to the network service.

Deploying a Single Forest

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

Schema. A schema defines all classes and attributes that can be used within the forest. The write-enabled copy of the schema is maintained on the schema operations master. By default, the first DC installed on the forest is designated as the schema operations master.
Configuration. The configuration naming context maintains a listing of all domains and sites within a forest, thus ensuring that no duplicate names are created.
Global catalog. The global catalog maintains a partial set of attributes for all objects that exist within a forest.

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

NOTE
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.

Making the Decision

Consider implementing a single forest for your enterprise if your organization meets the following criteria:

The same software is used across the organization. If the software is Active Directory–aware, the installation of the software might make changes to the schema. If the same software is used across the organization, the chance of objection to a schema modification is lessened.
You want to minimize forest-wide configuration. Maintaining a single forest reduces the number of administration tasks that globally affect a forest. For example, if an Active Directory–integrated application such as Exchange Server is deployed for an organization, the schema modifications have to be applied only once for the entire organization, not once for each forest.
You want to manage forest-wide administrative groups with minimal complications. Several enterprise administrative groups, including the Enterprise Admins and Schema Admins groups, are located in the forest root domain. If multiple forests are maintained, multiple sets of these groups also must be maintained to ensure forest security.
You want to be able to carry out single, enterprise-wide searches. You can query the global catalog server to perform a forest-wide search for an object only within a single forest. If there are multiple forests, you have to implement additional software or multiple searches to do an enterprise search in a single command.
You want to reduce management of trust relationships. Within a forest all domains are connected using transitive trust relationships. This allows a security principal in any domain in the forest to access any resource in the forest, subject to the security defined for the resource. You don't have to manually define trust relationships between domains in a single-forest deployment.

NOTE
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.

Applying the Decision

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.

Deploying Multiple Forests

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:

A more complicated and expensive domain structure. Every forest must have at least one domain. Within each domain there must be at least one domain controller. To ensure redundancy in the case of server failure, at least two DCs will be needed. Creating additional forests can lead to additional hardware costs for domain DCs.
Additional management costs for forest-wide components such as the schema and configuration naming contexts. Even if the two forests have identical schemas, the work effort is doubled if additional attributes or classes are added to the schema. The schema modifications must now be performed in two separate processes (one for each forest). In addition, group memberships in groups such as schema administrators and enterprise administrators must be managed in two separate forests.
Additional management costs for trust relationships. If you deploy multiple forests, you have to establish explicit one-way trust relationships between domains in the forests where resources must be accessed. Users from one forest can't access resources in another forest without these relationships. In addition, you can't create trust relationships between forests, only between domains. If the users in one forest are spread among multiple domains, individual explicit trust relationships must be established between each domain and the domain in the other forest (see Figure 2.3).

Figure 2.3 Establishing trust relationships between multiple forests
Limited use of universal principal names. User principal names are normally resolved by querying the global catalog to determine the account that's associated with the user principal name. If multiple forests exist, only default user principal names can be used if users are going to authenticate by using user principal names. If the default user principal name is used, the user has to log on using the user principal name of account@DNSDomainName. For example, if the user account neilsmith existed in the north.nwtraders.tld domain, users would have to authenticate using the default user principal name neilsmith@north.nwtraders.tld. Even if alternative user principal name suffixes were defined for the account, like neilsmith@microsoft.com, these wouldn't be accessible, because the global catalogs aren't shared between forests.
Limiting smart cards to using default user principal names. If a cross-forest logon process must take place, the user principal name associated with a smart card must be based on the default user principal name, not on an alternative user principal name. Again, this is because forests don't share a global catalog service.

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.

Making the Decision

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:

Short-lived joint ventures. In cases were organizations are paired together for short-term projects, it's often unnecessary to merge the two organizations into a single forest. Other than work performed on the joint project, the organizations will remain autonomous during and after the joint venture.
Mergers between two companies running separate Active Directories. Initially, you can achieve coexistence by maintaining separate Active Directory forests. If the merger is to be permanent, the next task is to merge the two forests into a single forest using directory migration tools such as the Active Directory Migration Tool (ADMT) from Microsoft. These tools allow you to migrate security principals between forests and to reapply security to resources once the resources are merged into a single forest.
Disagreement on change policies. A forest shares a common schema and configuration. Any modifications to the schema or configuration affect all domains in the forest. If the participants in a forest can't agree on a business process for schema change or on membership of enterprise-level groups such as the Enterprise Admins or Schema Admins groups, the organization should consider separate forests.
Differing schema requirements. A forest shares a single schema. If two divisions within a forest can't agree to schema modifications required by Active Directory–aware applications, you need separate forests. You can't limit schema modifications to a single domain within a forest.
CAUTION
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.
Distrust among administrators. Within a forest the Enterprise Admins group is assigned privileges that allow the group to manage all domains within a forest. Some departments within an organization don't trust other departments' administrators to have administrative rights within their domain. You can prevent this by changing the default group memberships to remove the Enterprise Admins group from the Administrators group in each domain.
Scope of transitive trust relationships. In many Windows NT 4.0 deployments trust relationships were established to allow a master domain's users to access resources in a resource domain. The trust relationships were established in a single direction to prevent users in the resource domain from accessing resources in the master domain. Within a forest, users in a domain can access resources in all other domains in the forest due to the transitive trust relationships that exist between domains in a forest. If you want to restrict the ability to grant access to resources using trust relationships, you must establish separate forests.
NOTE
Trust relationships must be established between domains in the two forests. You can't simply establish a trust relationship between forests.
Limited replication of the global catalog. All objects in the forest will have a partial set of attributes replicated to the global catalog. If several objects are added to a domain or deleted from it, this affects all domains in terms of replication of the global catalog. In addition, if you configure additional attributes to be replicated to the global catalog, this will result in the entire global catalog being replicated to all global catalog servers in the forest.
If user accounts need to be prevented from appearing in the global catalog. In highly secure environments it may be necessary to prevent users from knowing the existence of specific user accounts in the organization. For example, within a government office, there may be undercover agents. These agents aren't known to be government employees. Therefore, you wouldn't want their user information to appear in the global catalog. If you put these user objects in a separate forest, you can prevent their user accounts from appearing in the global catalog. Another scenario would be the case of an ISP that wants to prevent accounts from one client from being viewed by another company's clients.

Applying the Decision

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.

Lesson Summary

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.