Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
namespace of companyb.net. A root domain exists for conglomeratea.net, but it is not
populated because all users exist in one of three subdomains: asia, europe, and na.
ConglomerateA has recently entered into a joint venture with SupplierA and wants to
facilitate the sharing of information between the two companies. SupplierA also currently
operates in a Windows Server 2008 R2 AD DS environment and keeps all user and
computer accounts in an AD DS forest that is composed of two domains in the
suppliera.com namespace and a separate tree with a DNS namespace of
supplierabranch.org that reflects a certain function of one of its branches.
The decision was made to create a cross-forest trust between the two forests so that
credentials from one forest are trusted by the other forest and information can be
exchanged. The cross-forest trust was put into place between the root domains in each
forest, as shown in Figure 5.10.
Remember, a trust does not automatically grant any permissions in other domains or
forests; it simply allows for resources to be implicitly shared. Administrators from the
trusting domain still need to manually grant access. In our example, administrators in
both forests can decide what resources will be shared and can configure their environ-
ment as such.
Understanding the Empty-Root Domain Model
165
Two-Way Cross-Forest Trust
conglomeratea.net
Forest
Forest
Root
Root
suppliera.com
supplierabranch.org
asia.conglomeratea.net
na.conglomeratea.net
sales.suppliera.com
europe.conglomeratea.net
Conglomerate A Forest
Supplier A Forest
FIGURE 5.10
Cross-forest trust between root domains in each forest.
5
Understanding the Empty-Root Domain Model
ptg
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 5.11.
Forest
Root
abcschema.root
companyabc.com
Users
Computers
Printers
FIGURE 5.11
Empty-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.
166
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
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
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 virtu-
al 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.
ptg
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 5.12 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
Understanding the Placeholder Domain Model
167
microsoft.com
Forest
Root
msn.com
root.msft
hotmail.com
redmond.microsoft.com
tokyo.microsoft.com
europe.msn.com
asia.msn.com
sales.redmond.microsoft.com
FIGURE 5.12
The empty-root domain model using different domain tree names throughout
the forest.
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
5
this design model.
ptg
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 compo-
nents 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 func-
tional 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.
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 administra-
tors. This helped to control access to the schema root for the security-conscious organiza-
tion and provided for the simplicity of a single domain environment for its users.
Understanding the Placeholder Domain Model
The placeholder domain model, also known as the sterile parent domain model,
deserves special mention because of its combination of a single namespace/multiple
domain model and the peer-root model. Simply put, the placeholder domain model,
168
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
Forest
Root
companyd.com
Administrator
rootd.peer
Sales
Corporate
Engineering
IT
Research
HR
FIGURE 5.13
Peer-root domain with schema security for added protection and integrity.
shown in Figure 5.14, is composed of an unoccupied domain as the forest root, with
multiple subdomains populated with user accounts and other objects.
companyabc.com
ptg
Unpopulated
Forest
Root
Placeholder Domain
asia.companyabc.com
na.companyabc.com
europe.companyabc.com
Computer
User
Printers
OUs
Objects
Objects
Subdomains
Populated with AD
Objects
FIGURE 5.14
Unpopulated placeholder domain.
There are two distinct advantages to this design. First, as with the peer-root model, the
schema is separate from the user domains, thus limiting their exposure and helping to
protect the schema. Second, the namespace for the user accounts is consistent in the
namespace, thus mitigating any potential political issues. In other words, because all users
in all locations are at the same logical level in the domain structure, no one group will
feel superior or inferior to another. This issue might seem trite, but the psychological
nature of humans is finicky, and you might find that this design offers advantages for
certain organizations.
Understanding the Special-Purpose Domain Design Model
169
Examining a Placeholder Domain Real-World Design Example
CompanyE is an architectural firm with major offices located in New York, Chicago, Los
Angeles, San Paulo, Rio de Janeiro, Berlin, Paris, London, Tokyo, Singapore, and Hong
Kong. Administration is centralized in New York, but regional administration takes place
in Rio de Janeiro, London, and Tokyo. The company has recently migrated to AD DS and
has chosen to deploy a placeholder domain model for its organization that looks similar
to Figure 5.15.
companye.com Forest
Root
Company E
Placeholder Domain
Structure
5
ptg
San Paulo
Rio de Janeiro
Paris
London
Berlin
sa.companye.com
europe.companye.com
New York
Chicago
LA
Singapore
Tokyo
Hong Kong
na.companye.com
asia.companye.com
FIGURE 5.15
Complex AD DS placeholder domain structure.
All users authenticate to geographically centric subdomains. In addition, the administra-
tors in New York have segregated the schema master function into the placeholder
domain, limiting its exposure and have limited access to this domain to a small group of
high-level administrators. Each domain is logically oriented as well, to give the impression
of autonomy to each geographical unit.
Understanding the Special-Purpose Domain Design
A special-purpose domain or forest is one that is set up to serve a specific need. For
example, your organization might set up a special-purpose domain to house outside
contractors or temporary workers to limit their exposure to the main AD DS forest. In
170
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
addition, trust relationships could be established between this domain or other domains
to allow for resource access.
Generally, there has to be a good reason before additional domains are deployed in AD
DS. Overhead is increased with each domain that is added to an environment, and your
logical network structure begins to look convoluted. However, in some unique cases, a
special-purpose domain might become necessary.
Another possible use for a separate special-purpose domain structure is to house a direc-
tory service–capable application that requires itself, for security or other reasons, to have
exclusive access to the schema. In other words, if your HR department runs an application
that stores confidential employee information in an application that utilizes an LDAP-
compliant directory, such as AD DS, a domain could be set up for that application alone.
A cross-forest trust relationship can be established to allow for the sharing of information
between the two environments. This type of situation is rare because most of these appli-
cations make use of their own directory, but it is possible. Because the AD DS schema
must be unique across the forest, this would preclude the use of a single forest if these
applications require exclusive access or utilize common schema attributes. This concept,
known as Active Directory Lightweight Domain Services (AD LDS), is further elaborated in
Chapter 8, “Creating Federated Forests and Lightweight Directories.”