The
most basic of all AD DS structures is the single domain model; this
type of domain structure comes with one major advantage over the other
models: simplicity. A single security boundary defines the borders of
the domain, and all objects are located within that boundary. The
establishment of trust relationships between other domains is not
necessary, and implementation of technologies such as Group Policies is
made easier by the simple structure. More organizations than not can
take advantage of this design because AD DS has been simplified, and its
capability to span multiple physical boundaries has been enhanced.
Choosing the Single Domain Model
The single domain model is
ideal for many organizations and can be modified to fit many more. A
single domain structure possesses multiple advantages, first and
foremost being simplicity. As any administrator or engineer who has done
work in the trenches can confirm, often the simplest design works the
best. Adding unnecessary complexity to the system’s architecture
introduces potential risk and makes troubleshooting these systems more
difficult. Consequently, consolidating complex domain structures into a
simpler single domain AD DS structure can reduce the costs of
administration and minimize headaches in the process.
Another advantage realized by
the creation of a single domain is the attainment of centralized
administration. Many organizations with a strong central IT structure
want the capability to consolidate control over the entire IT and user
structure. AD DS and, specifically, the single domain model allows for a
high level of administrative control and the ability to delegate tasks
to lower sets of administrators. This has proven to be a strong draw to
AD DS.
Not
all AD DS structures can be composed of a single domain, however, and
some factors might limit an organization’s ability to adopt a single
domain structure. If these factors affect your organization, you might
need to begin expanding your domain model to include other domains in
the forest and a different domain design. For example, the single
security boundary formed by a single domain might not be exactly what
your organization needs. Organizational units (OUs) can be used to
delegate administration of security elements, but members of the Domain
Admins group can still override permissions within different OUs. If the
security lines within your organization need to follow exact
boundaries, a single domain might not be for you. For example, if your
HR department requires that no users from IT have access to resources
within its environment, you will need to expand your domain structure to
accommodate the additional security concerns.
Another disadvantage of
the single domain model is that a single domain in a forest necessitates
that the computer with the role of schema master is located in that
domain. This places the schema master within the domain that contains
all the user accounts. Although access to the schema master can be
strictly controlled through proper administration, your risk of schema
exposure is greater when the schema master role resides in a user
domain. For example, members of the domain administrators group could
override the security of the schema administrators group and add their
account to that group. If this design model poses problems for you as an
organization, design models that separate the schema master into a
placeholder domain can do the trick.
Exploring a Single Domain Real-World Design Example
To illustrate a good example
of an organization that would logically choose a single domain model,
let’s consider fictional CompanyA. CompanyA is a 500-user organization
with a central office located in Minneapolis. A few smaller branch
offices are scattered throughout the Midwest, but all help desk
administration is centralized at the company headquarters. CompanyA
currently utilizes a single user domain and has multiple resource
domains in various locations across the country.
The IT team in Minneapolis
is designing an AD DS structure and wants to centralize administration
at corporate headquarters. Branch offices should have the capability to
change passwords and clear print jobs locally, but should have no other
form of administrative privilege on the network.
During the AD DS design
process, CompanyA started with a single AD DS forest, domain, and
namespace named companya.net. Organizational units for each branch
office were added to delegate password-change control and print
administration to those offices.
Current legacy Windows 2000
AD and Windows Server 2003 forests and domains were consolidated into
the AD DS structure, as shown in Figure 1.
CompanyA could not justify the existence of additional domains because
their security model was centralized, and it did not have any far-flung
geographical locations with slow link speeds to the main office or any
other similar constraints that required additional domains.
Delegation
of password-change control and other local administrative functions was
granted to individuals in each specific geographical OU, which gave
those administrators permissions specific to only resources within their
own group but maintained central administrative control in Minneapolis.
Several AD DS sites were
created to control the frequency of replication. A site was positioned
to correspond with each separate geographical area, creating a site
structure similar to the one shown in Figure 2.
Creating the separate sites
helped to throttle replication traffic and reduce the load placed on
the WAN links between the sites.
This type of single domain
design is ideal for the type of organization described in this section
and actually can be used for many other types of organizations, large
and small. Because delegation of administration is now accomplished
through the use of OUs and Group Policy Objects, and the throttling of
replication is accomplished through AD sites, the number of reasons for
organizations to use multiple domains has been reduced.
