Peer-Root Domain Model

The schema is the most critical component of Active Directory and should therefore be protected and guarded closely. Unauthorized access to the schema master domain controller for a forest can cause some serious problems and is probably the best way to corrupt the entire directory. Needless to say, segregation of the keys to the schema from the user base is a wise option to consider. From this concept was born the peer-root domain model, shown in Figure 5.11.

Figure 5.11. Peer-root domain model with an unpopulated forest root.

In short, the peer-root domain model makes use of an unpopulated forest root domain that exists solely to segregate the schema master function from the rest of the network.

In Figure 5.11, the companyabc.com domain is used for all user and computer accounts, whereas the abcschema.root domain is the peer-root domain that holds the schema master role for the company. Most users would not even be aware of the fact that this domain exists, which makes it even more secure.

The one major disadvantage to this design model lies in the hardware costs. Because a separate domain is necessary, at least one extra domain controller will be needed as part of the design plan, and preferably two for redundancy issues. This domain controller for the peer-root domain will not need to be the speediest machine because it will not perform much work, but it should definitely be made redundant, because the forest-specific FSMO roles will be handled by the machine.

Determining When to Choose the Peer-Root Model

Security needs vary from organization to organization. A company that performs topsecret work for the military is going to have drastically different security issues than a company that manufactures rubber duckies. Consequently, if the needs of your organization require a greater amount of security, the peer-root domain model may be the right one for you.

An additional advantage that this type of environment gives you is the flexibility to rename domains, add domains, and essentially move in and out of subdomains without the need to rename the forest. Although the domain rename tool exists in Windows Server 2003, undertaking this task is still complicated, and using the peer-root model can help to simplify changes. In a merger, for example, if your peer root is named root.network and all your resource domains are located in companyabc.com in the same forest, it becomes much easier to add companya.net into your forest by joining it to the root.network domain.

The beauty of the peer-root domain model is that it can be incorporated into any one of the previously defined domain models. For example, a large grouping of trees with published namespaces can have a forest root with any name desired.

The example shown in Figure 5.12 demonstrates how this type of environment could conceivably be configured. The flexibility of Active Directory is not limited by this design model because the options available for multiple configurations still exist.

Figure 5.12. The peer-root domain model using different domain tree names throughout the forest.

Of course, many organizations often cannot justify the increased hardware costs, and this type of design model can prove to be more costly. Realistically, two domain controllers need to be established in the root domain to handle authentication requests and to provide for redundancy within the domain. Keeping these costs in mind, it is important to align your organization's security requirements with the cost-benefit ratio of this design model.

A Real-World Peer-Root Domain Design Example

Company D is a biomedical corporation centered in the San Francisco Bay area. Infrastructure security is highly important for the organization, and the company needs to ensure that directory information is safe and secure in the network environment. The IT organization is centralized, and most employees are located at the main headquarters building.

The administrators of Company D originally chose Active Directory and Windows Server 2003 to provide for robust security for their environment and to take advantage of the increased functionality. However, management was concerned about limiting access to vital components of the directory service such as the schema. Further investigation into the varying domain design models for Active Directory uncovered the peer-root domain model as a fully functional substitute to the single domain model, but with the added schema security that they desired. This resulted in a forest structure similar to the one shown in Figure 5.13.

Figure 5.13. Peer-root domain with schema security for added protection and integrity.

Organizational units were created for each department and placed in the companyd.com domain. The only user account in the rootd.peer domain is the Administrator account for the forest. Access to this account was limited to a choice group of high-level administrators. This helped to control access to the schema root for the security-conscious organization and provided for the simplicity of a single domain environment for its users.