When planning an Active Directory (AD) implementation in a Windows environment, significant thought must be given to its topology. Determining how many Forests, Domains and Organizational Units (OUs) to implement is critical to the success of the project. This note, the first in a series of four, provides a quick overview of the difference between these functions to allow IT managers to understand the architectural planning process.

Active Directory Topology This is the first in a series of notes addressing topology decisions in an Active Directory implementation. The remaining notes will examine, in detail, the three layers of topology hierarchy: Forests Domains Organizational Units

Here a Forest, There a Forest…

The first structure that must be examined when discussing AD topology is the Forest. The Forest is the top tier in the topology and, since it contains all other objects, is the level at which inclusive policies are implemented. Though the inclusion of only a single forest is the more common structure in an AD deployment, it is by no means the only viable choice.

To determine whether the enterprise needs more than a single Forest, the enterprise must assess whether it needs resource isolation, or whether resource autonomy is sufficient:

• Autonomy is independent, but non-exclusive control of a resource. This means that, while a given administrator / administrator group controls a specific resource, that control can be superseded by an administrator / administrator group with greater authority. If autonomy is sufficient, a single Forest can be used.
• Isolation is independent and exclusive control of a resource. This means that a given administrator / administrator group controls a specific resource and that control cannot be superseded by any other administrator / administration group. If isolation is required, multiple Forests must be used.

Decide on Domains

Domains are the second administrative tier within an AD topology and represent the first opportunity for introducing administrative differentiation. As with Forests, the most typical deployment scenario includes only one Domain. Also, as with Forests, multiple Domains can be implemented, though there are only two deciding factors when it comes to determining the number of Domains to implement:

1. Performance. Within an AD implementation, replication traffic is restricted by Domains. Any changes made to permissions, schema, etc. are replicated to all domain controllers within the Domain. The number of objects in the Domain, the geographical distribution of sites in the Domain and the network bandwidth between the sites in the Domain can all impact replication and result in performance loss.
2. Security. Security management in an AD environment occurs at the Domain. This is expressed in two ways:

• Security policies and resource access are restricted to and by Domains.
• Security events noted by a domain controller are visible only to the Domain administrators.

As such, if divisions exist within the enterprise as a whole that, for whatever reason, require distinct security controls and independent security monitoring, those divisions must be provided with their own Domain.

A situation under which different Domains might be required is where the enterprise spans a sufficiently large geography that local administration (according to differing business hours) is needed. Alternately, if one division of the enterprise is governed by a specific set of legislative regulations that are more restrictive than are needed for the rest of the company, a separate Domain can be established for that division.

Organize Your Units with Organizational Units

When it comes to providing streamlined administration of an AD environment, OUs are the meat and potatoes and will form the bulk of the divisions of administrative responsibility. While enterprises must still be cautious about implementing too many OUs and creating an administrative mess, it’s acceptable, and necessary, to have more than one.

The primary purpose of OUs is to provide fine granular control of the administration of resources such as users, computers and files. This granular control can be further enhanced by layering or tiering OUs such that each successive layer further reduces the scope of the resources managed by the OU. For example, an enterprise could specify the sequential OU structure shown in Figure 1:

Figure 1. Sample Active Directory OU Topology

Source: Info-Tech Research Group

 

Recommendations

1. Keep it simple. An Active Directory implementation is supposed to simplify and streamline resource management within the enterprise. An architecture that is unnecessarily complex will not only nullify those goals, but will end up costing the enterprise money. Planning for simplicity will result in the most efficiency.
2. Only deploy multiple Forests if resource isolation is needed. At any point, if the enterprise has resources for which superseding administrative control cannot exist, the enterprise must implement multiple forests. Otherwise, the additional complexity and cost mean the enterprise should utilize only a single forest.
3. Use one Domain unless performance issues or security requirements exist. Should the enterprise be of sufficient size, be geographically dispersed or have slow WAN links, multiple Domains may be required. Further, if mutually exclusive security requirements exist for segments of the enterprise, multiple Domains should be implemented. Otherwise, a single Domain is sufficient.
4. Use OUs for fine-grained administrative control, just don’t go to extremes. While neither the number of OUs in a specific tier, nor the number of tiers themselves is functionally limited, creating too deep or too broad a structure will lead to more complicated management. Tier count and tier membership need to be balanced to achieve the greatest levels of granularity and manageability.

Bottom Line

Implementing a properly designed Active Directory infrastructure requires careful and thoughtful planning. Understanding the differences between Forests, Domains and OUs is essential when developing the architecture.