The
schema is the most critical component of AD DS 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 empty-root
domain model, shown in Figure 1.
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 1,
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 empty-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.
Note
Instead of using a physical
hardware system for the schema master, an organization could choose to
use Windows Server 2008 R2 Hyper-V virtualization and create virtual
domain controllers for the empty-root domain. This would help to reduce
the costs of deploying the empty-root model. Do be sure to treat these
virtual machines with the same respect as you would any other domain
controller, with regular maintenance and backups, as losing the forest
root would be disastrous for the other domains in the forest.
Determining When to Choose the Empty-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 toys. Consequently, if the needs of
your organization require a greater amount of security, the peer-root
domain model might 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 2008 R2, 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 2
demonstrates how this type of environment could conceivably be
configured. The flexibility of AD DS is not limited by this design model
because the options available for multiple configurations still exist.
Of course, many
organizations often cannot justify the increased hardware costs, and
this type of design model can prove to be more costly. Realistically, at
least 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.
Examining a Real-World Empty-Root Domain Design Example
CompanyD 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
CompanyD originally chose AD DS and Windows Server 2008 R2 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 AD DS 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 3.
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.
