Forest planning involves developing a plan for the namespace and administration needs of the organization as a whole. As part of this planning, you should decide who are the owners of the forest or forests implemented. From an administration standpoint, the owners of a forest are the users who are the members of the Schema Admins and Enterprise Admins groups of the forest as well as users who are members of the Domains Admins group in the root domain of the forest. Although these users have direct control over the forest structure, they typically don't make the final decisions when it comes to implementing forest-wide changes. Typically, the final authority for making forest-wide changes is an IT or business manager who is requesting changes based on a specific business need or requirement and acting after coordinating with business managers from other groups as necessary.
The top structure in any Active Directory implementation is the forest root domain. The forest root domain is established when you install Active Directory on the first domain controller in a new forest. Any time you add a new domain that is part of a different namespace to an existing forest, you establish a root domain for a new tree. The name given to a root domain—either the forest root domain itself or the root domain of a new tree in a forest— acts as the base name for all domains later created in that tree. As you add subsequent domains, the domains are added below an established root domain. This makes the domains child domains of a root domain (see Figure 34-1).
Regardless of whether your forest uses a single namespace or multiple namespaces, additional domains in the same forest have the following characteristics:
Share a common schema All domain controllers in the forest have the same schema and a single schema master is designated for the forest.
Share a common configuration directory partition All domain controllers share the same configuration container, and it stores the default configuration and policy information.
Share a common trust configuration All domains in the forest are configured to trust all the other domains in the forest, and the trust is two-way and transitive.
Share a common global catalog All domains in the forest have the same global catalog, and it stores a partial replica of all objects in the forest.
Share common forest-wide administrators All domains in the forest have the same top-level administrators: Enterprise Admins and Schema Admins, who have the following roles.
Enterprise Admins are the only administrators with forest-level privileges, which let them add or remove domains. The Enterprise Admins group is also a member of the local Administrators group of each domain, so, by default, these users can manage any domain in the forest.
Schema Admins are the only administrators who have the right to modify the schema.
Part of creating a forest plan is deciding how many forests you will need or whether you need additional forests. This isn't an easy decision or a decision that should be made lightly. With a single forest, you have a single top-level unit for sharing and managing resources. You can share information across all domains in the forest. However, this requires a great deal of trust and cooperation among all the groups in the organization.
With multiple forests you change the dynamic considerably. You no longer have a single toplevel unit for sharing and managing resources. You have separate structures that are fully autonomous and isolated from one another. The forests do not share schema, configuration information, trusts, global catalogs, or forest-wide administrators. If desired, you can join the forests with a cross-forest trust.
Should you decide to implement a cross-forest trust between the forests, you can control whether a trust is one-way or two-way and the trust authentication level. Unlike inter-forest trusts, which are two-way and transitive by default, cross-forest trusts are either two-way or one-way. With a two-way trust, users in either forest have access to resources in the other forest. With a one-way trust, users in one forest have access to resources in the other forest but not vice versa.
The trust authentication level is set on outgoing trusts and is either domain-wide or selective. Domain-wide authentication is open and implies a certain level of trust as users in the trusted forest can be authenticated to use all of the resources in the trusting forest. Selective authentication is closed and more secure, because only the users or groups to which you explicitly grant permission can access resources in the trusting domain.
Tip
Consider the size of the organization
You should consider the size of the organization when deciding forest structure. However, the size of an organization alone is not a reason for deploying multiple forests. A forest can contain multiple domains. The domains can be deployed in multiple namespaces. Each domain is a separate unit of administration and each domain can have millions of objects.
Inside Out: Geographically separated sites
Geographically separated business units may want completely separate forests or domains. Although there may be business reasons for this, the decision should not be made based on perceived limitations in Active Directory. As long as a connection can be made between locations, there is no need for separate forests or domains. Active Directory sites provide the solution for connecting across limited bandwidth links. With the automatic compression feature for site bridgehead servers, replication traffic is compressed 85 to 90 percent, meaning that it is 10 to 15 percent of its non-compressed size. This means that even low bandwidth links can often be used effectively for replication. For more information on sites, see Chapter 35.
Most companies opt to deploy a single forest, and it is only through merger or acquisition that additional forests enter the picture. In part, this is because there is no easy way to merge forests if you decide to do so later: You must migrate objects from one forest to the other, which can be a very long process. For this and other reasons, you should decide from the start how many forests are going to be implemented and you should justify the need for each additional forest. Sometimes additional forests are deployed because of organizational politics or the inability of business units to decide how to manage the top-level forest functions. At other times, additional forests are deployed to isolate business units or give complete control of the directory to a business unit.
The organization should consider the following factors before creating additional forests:
Additional forests make it more difficult for users to collaborate and share information. For example, users have direct access to the global catalog and can search for resources easily only for their own forest. Access to resources in other forests must be configured, and the users will not be able to directly search for available resources in other forests.
Additional forests mean additional administrative overheard and duplication of infrastructure. Each forest will have its own forest-level configuration and one or more additional domain-level configurations that need to be managed. The ability to share resources and synchronize information across forests must be specifically configured rather than implemented by using built-in trusts and synchronization.
Sometimes, however, the additional controls put in place with additional forests are needed to give reasonable assurance that administrators from other domains in a forest do not make harmful changes to the directory, which are then replicated throughout the organization. All the domain controllers in a forest are tightly integrated. A change made on one domain controller will be replicated to all other domain controllers. Replication is automatic, and there are no security checks other than the fact that the person making the change must have the appropriate permissions in the first place, that is, the person must be a member of the appropriate administrator group for the type of change being made. If such an administrator is acting maliciously in making changes, those changes will be replicated regardless of the effect on the organization.
That said, reasonable assurance can be addressed by putting strict administration rules and procedures in place. With strict rules and procedures, the organization will have the following multiple levels of administrators:
Top-level administrators with enterprise-wide privileges who are trusted with forestwide administration. These administrators are members of the Enterprise Admins group.
High-level administrators with domain-wide privileges who are trusted with domainwide administration. These administrators are members of the Domain Admins, Administrators, Server Operators, or Backup Operators groups.
Administrators who are delegated responsibilities for specific tasks, which might include being a member of the Server Operators, Backup Operators, or similar groups.
To give reasonable assurance, the organization will also need to physically secure domain controllers, set policies about how administrators use their accounts, such as running tasks as an administrator only when needed for administration, and configure auditing of all actions performed by both users and administrators.