- Domain Design Overview
- Choosing Your Domain Namespace
- New Domain Design Features in Windows .NET Server 2003
- Choosing Your Domain Structure
- Single Domain Model
- Multiple Subdomain Model
- Multiple Trees in a Single Forest Model
- Federated Forests Design Model
- Peer-Root Domain Model
- Placeholder Domain Model
- Special-Purpose Domains
- Renaming an Active Directory Domain
- Summary
- Best Practices
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, while 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. So, in other words, a small pizza boxstyle server should be sufficient for this task, as long as the OS is mirrored.
When to Choose the Peer-Root Model
Security needs vary from organization to organization. A company that performs top-secret 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 subdomains without the need to rename the forest. While the domain rename tool exists in Windows .NET 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 compaq.com in the same forest, it becomes much easier to add hp.com 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.
Real-World 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 .NET 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.