Designing the Active Directory Structure

Determining the Number of Forests for Your Network

When you begin to plan your forest model, start with a single forest. A single forest is sufficient in many situations; however, if you decide to create additional forests, ensure that you have valid, technical justification.

Creating a Single Forest Environment

A single forest environment is simple to create and maintain. All users see a single directory through the global catalog, and do not need to be aware of any directory structure. When adding a new domain to the forest, no additional trust configuration is required. Configuration changes only need to be applied once to affect all domains.

Creating a Multiple-Forest Environment

If administration of your network is distributed among many autonomous divisions, it might be necessary to create more than one forest.

Because forests have shared elements, such as schema, it is necessary for all the participants in a forest to agree on the content and administration of those shared elements. Organizations such as partnerships and conglomerates might not have a central body that can drive this process. In short-lived organizations like joint ventures, it might not be realistic to expect administrators from each organization to collaborate on forest administration.

It might be necessary to create more than one forest if individual organizations:

Do not trust each other's administrators. A representation of every object in the forest resides in the global catalog. It is possible for an administrator who has been delegated the ability to create objects to intentionally or unintentionally create a "denial of service" condition. You can create this condition by rapidly creating or deleting objects, thus causing a large amount of replication to the global catalog. Excessive replication can waste network bandwidth and slow down global catalog servers as they spend time to process replication.

Cannot agree on a forest change policy. Schema changes, configuration changes, and the addition of new domains to a forest have forest-wide impact. Each of the organizations in a forest must agree on a process for implementing these changes, and on the membership of the schema administrators and enterprise administrators groups. If organizations cannot agree on a common policy, they cannot share the same forest. Creating a forest change policy is discussed later in this chapter.

Want to limit the scope of a trust relationship. Every domain in a forest trusts every other domain in the forest. Every user in the forest can be included in a group membership or appear on an access control list on any computer in the forest. If you want to prevent certain users from ever being granted permissions to certain resources, then those users must reside in a different forest than the resources. If necessary, you can use explicit trust relationships to allow those users to be granted access to resources in specific domains.

Incremental Costs for an Additional Forest

Each forest you create incurs a fixed management overhead as follows:

Each additional forest must contain at least one domain. This might require you to have more domains than you had originally planned. There are fixed costs associated with creating and maintaining a domain. These costs are detailed later in this chapter.
You must manage the forest-wide components of each forest separately (for example, the Schema and Configuration container elements and their associated administration group memberships), even if they are essentially the same.

In order for a user in one forest to use a resource in a different forest, you need to perform additional configuration as follows:

For users in one forest to access resources in another forest, you must create and maintain an explicit trust relationship between the two domains. An explicit trust relationship between domains in different forests is one-way and not transitive. Without an established trust relationship, users in one forest cannot be granted access to objects in another forest.
By default, users in one forest are only aware of objects in the global catalog of their own forest. To discover objects in a different forest, users must explicitly query domains that are outside their forest. Alternatively, administrators can import data from other domains into the forest where the user resides. This can add cost because:
- Users must be trained to understand the directory structure so that they know where to direct queries when global catalog queries fail.
- When you import data from a domain in a separate forest, you must put a process into place to keep the imported data up-to-date when it changes in the source domain.

Figure 9.2 is an example of an interforest configuration where a user in one forest needs to access a published resource in a different forest. An explicit, one-way trust relationship is created so the user can be granted access to the resource. The representation of the resource in the directory is imported into the user's forest, where it appears in the global catalog.

Enlarge figure

Figure 9.2 Additional Configuration for Interforest Resource Access

Some features that are available within a forest are not available between forests, such as the following:

You can only use default UPNs if a user account is in a different forest than the computer being used for logging on. Default UPNs are required because a domain controller in the computer's forest will not find a user account with a matching UPN in the global catalog. The user account appears in the global catalog of a different forest. The domain controller handling the logon must then use the <DNS-domain-name> portion of the UPN to try to find a domain controller to verify the user's identity.
Logging on using a smart card relies on a user principal name. Default UPNs must be used for a cross-forest logon process that uses smart cards to work.
You can move security principals between domains in the same forest, but they must be cloned between domains in separate forests. Cloning is not as transparent to an end user as moving a user between domains. For more information about cloning, see "Determining Domain Migration Strategies" in this book.

When deciding on the number of forests that you will need, keep in mind that what is important to users is not necessarily the same as what is important to administrators. However, users stand to lose the most from a multiple forest scenario. For example, some organizations outsource their network administration to several different contractors. Generally, the contractor is paid based on network performance, and the number one responsibility is to maintain a stable network. One contractor might not want another contractor being able to influence computers under their control, and having separate forests can solve that challenge. However, separate forests can be a disadvantage for the users who no longer have a single, consistent view of the directory. In these situations, try not to create separate forests to solve the boundary of administration problem.

In cases where it is not important for all users to have a consistent view of the directory, it might be appropriate to have multiple forests. For example, consider a company such as an Internet service provider (ISP) that hosts Active Directory on behalf of several companies. The users in the different client companies have no reason to share a consistent view of the directory. Additionally, there is no reason to have a transitive trust relationship between the companies. In this case, maintaining separate forests is useful and appropriate.