When you develop the logical
design, it is essentially the development of the forest and domain
structure, including the OU structure, Global Catalog (GC) server
planning, naming standards, Group Policy, and trust definitions. The
fundamental components of the logical structure are illustrated in Figure 1.This section deals with logical design details
needed in developing a new AD structure, as well as considerations if
you already have a Windows 2000 domain structure in place. In today's
business climate of seemingly continual mergers and acquisitions, few
companies can consider their forest structure set in stone. In addition,
the experience the Windows community has gained since the release of
Windows 2000, along with new capabilities of Windows Server 2003, has
provided motivation to re-evaluate the forest structure.
Your organization's logical structure includes the
forest structure, domain structure, and OU structure, and is commonly
referred to as the design of the namespace. These elements form the
foundation for all other aspects of AD, so it's critical to incorporate
the right design for your organization.
1. Domain and OU Structure
The three basic domain structures illustrated in Figure 2
are the single domain model, the multiple domain model in a
parent/child relationship, and the multiple domain model in a multiple
domain tree relationship. In each model, OUs are used to create
subdomain organizations for more granular administration and security
purposes. Note that OUs contain nearly anything a domain can contain,
including users, computers, printers, groups, shares, Group Policies,
and even other (nested) child OUs. Administration of the OUs is
delegated from a higher-level container (domain or parent OU).
This section details the differences and design
considerations of multiple- versus single domain models. The decision
really rests with the question “Can I accomplish my design criteria more
effectively with OUs or domains?” To help determine this, refer to Table 1
to compare features of domains and OUs. Note that multiple domains are
clearly more rigid and add to the complexity of the AD, as well as being
more costly because you must add servers to create and support the
additional domains.
Table 1. Domain and OU Feature Comparison
| Feature | Domain | OU |
|---|
| Cost | More
expensive because additional servers must be employed as DCs.
Administrative costs, including problem troubleshooting, also increase. | No additional hardware or additional cost required. |
| Ability to create | Must have enterprise admin privileges, additional hardware, and so on. Not trivial. | Easily created—compare to creating a folder and adding objects. This right can be delegated. |
| Ability to rename | Not possible in Windows 2000. Possible in Windows Server 2003, but very complex. | As simple as renaming a file or folder. |
| Ability to delete | Must go through the DCPromo demotion process, and requires enterprise Admin privileges. | As simple as right-clicking the icon in the snap-in and deleting it. |
| Group Policy | Apply to domains. Default domain policy created. Account security is enforced only from the domain-level policies. | Apply
to OUs. No default OU policy. Account security cannot be enforced at
the OU level; instead, the account security policies as defined at the
domain level are applied to all OUs.
Group Policy applies only to the OU where the user or computer account
exists. |
| Administration | Can delegate certain functions, such as DNS administration. Domain Admin has authority over all OUs. | OU Admins can have rights delegated as desired by the domain Admin. |
| Replication | Significant
impact—expands the replication topology, adds latency, affects the
topology design, and requires more network bandwidth and administration,
including monitoring and troubleshooting. | No impact on replication, bandwidth, or topology. Some troubleshooting impact for applying Group Policy and user rights. |
note
OUs are significantly restricted, in that even though
it is available in the Group Policy Editor, account security cannot be
applied at the OU level. For example, you cannot set the Maximum
Password Age to 60 days on the domain level and then set it to 30 days
at an OU. Actually, you can set it at
the OU, but it won't apply. This applies only to the Account Security
settings and not to User Rights or Audit Policy or any other setting
configured in a Group Policy. Windows Server 2003 does not change this
behavior.
This behavior is noted here because this security
restriction could dictate the necessity of creating domains rather than
OUs if separate password policies are required for different business
entities. However, if different business entities truly have different
security requirements, it might be more advisable to create multiple
forests, instead of different domains.
Microsoft has been advising customers even before
Windows 2000 was released that the best AD design strategy was to begin
with a single domain and prove you need more. After nearly five years of
experience with AD, we can say that this design principle is still
true. That is not to say that a single domain will always suffice, but
that exercise will force you to justify additional domains.
Single Domain
The single domain, as illustrated in Figure 3,
is well suited for small- or medium-size companies with simple business
organization models, as well as a large global enterprise. Microsoft
itself implemented a multiple domain model and is now attempting to
collapse it to a single domain model for security reasons. Remember that
the key design principle is to create domains representing entities
that do not change, and to use OUs for entities that do change (such as
business units). Business unit names, location in the organization
hierarchy, and subordinate organizations not only change, but also
sometimes disappear altogether.
Creating domains based on business entities
guarantees a lot of work for the system architect and Administrators,
because changing organization structure and department names require
changing the domain structure and names. As I worked with companies to
design their AD models, it became clear that the most popular domain
model is to name domains after geographical entities, such as Americas,
North America, South America, Latin America, EMEA (Europe, Middle East,
Africa), and Asia Pacific. As one designer noted, “The globe never
changes.”
Thus, it becomes easy to see that a company just
doing business in a single country or region would be a good candidate
for a single domain model. College campuses would fit well in this
example. Some features that qualify you for a single domain model
include
Centralized administration:
Managing a single domain makes life much easier for Administrators if they operate in a central location.
Small number of remote sites:
Remember that a single domain contains all objects and attributes in the
AD that must be replicated to all DCs in the forest. Multiple domain
models partition the AD to reduce replication traffic, although GC
servers hold about 70% of the data from each domain in the forest.
Windows 2000 had limits of a single Bridgehead Server (BHS) per domain
per site with no load balancing, requiring manual intervention.
note
Windows Server 2003 contains significant improvements
in replication performance that eliminate barriers that existed in
Windows 2000 .
The new application partition feature allows you to partition the AD
independently of the domain level and replicate independently between
any specifically targeted DCs in a forest. By default, this feature is
used to replicate the DNS data stored in AD only to those DCs that are
also running the DNS service. If the AD schema is to be extended to hold
a lot of special data for your company's applications, you are now able
to sufficiently control replication of this AD data using application
partitions across domains, which might make single domains even more
attractive.
Monolithic business model:
Organizations such as holding companies or corporations with multiple
independent business units will not benefit from a single domain model.
Rather these organizations will likely use a multiple forest model. A
simple business organization without these complexities lends itself to a
single domain.
User population:
There has never been any limit—real or practical—on the number of
objects that can effectively be put into a single Windows 2000 or 2003
domain. HP built a domain in the early days of Windows 2000 that had
more than 100 million objects (mostly users) with no significant
degradation of performance as the number of objects increased. The
single domain models I've seen are typically fewer than 40,000 or 50,000
users. However, that seems to be a result of taking other factors noted
here, such as business structure, administration model, and so on, that
tend to limit the size of the company and thus the user community. I
don't know of a single instance in which the number of users was the
sole design criteria for determining a single or multiple domain model.
Although Microsoft and experienced AD architects
usually recommend that you start with a single domain model and then
prove you need more domains, there are some very good reasons to
implement a multiple domain model, as described in the next section.
Multiple Domains
Multiple domain structures are probably the most
common AD configuration. Even in small organizations, multiple domains
can have advantages. As I noted in the “Single Domain”
section, multiple domain models are almost always named after
geographical entities. One of the design practices to evolve as Windows
2000 was deployed in the past few years is the role of the empty root domain,
also referred to as a “ghost” or “placeholder” domain. This domain
contains enterprise Admin and schema Admin accounts, and serves as the
forest root domain, which holds the domain structure together. It can be
implemented either as a parent to the other domains or a separate
domain tree, as shown in Figure 4. Compaq implemented a placeholder domain in a parent-child relationship. Figures 5 and 6
illustrate how Compaqtrimmed more than 1,300 resource domains and 13
master user domains (MUDs) to a simple 4-domain structure in a
parent-child relationship.
I know consultants who have advised their customers
to create a placeholder domain even if a single domain model would be
sufficient. Their reasoning was for expansion. In reality, if you did
create a single domain and later wanted to implement a placeholder
domain structure,you could create additional domains and leave the
original as the placeholder, migrating users, computers, groups, and so
on to the other domains.
Consider the case of the Georgia (United States) Department of Transportation (GDOT), which moved from a multimaster full mesh Windows NT domain model (shown in Figure 7) to a two-domain model with an empty root for its Windows 2000 infrastructure (shown in Figure 8).
Essentially, this is a single domain model because GDOT employs a
placeholder domain as a root domain, which contains only enterprise
Admin accounts. GDOT replaced the Windows NT resource domains with OUs.
Consider the simplicity of the new domain model. Note also that GDOT has
migrated now to Windows Server 2003 without modifying its AD structure.
A structure of this nature gives the simplistic
advantage of a single domain with the flexibility of a multiple domain
structure.
However, even though the empty root + one or many
child domain structure has often been implemented in the past, the
rising security awareness of Microsoft and companies using these
infrastructures (including HP) has taught us some clear disadvantages of
this AD design. Companies that have not yet deployed AD in their
enterprise should especially take the following drawbacks into
consideration when deciding between creating multiple domains within
their forest (including the empty root domain) or multiple single-domain
forests if one single domain forest won't meet their needs:
Disaster-recovery practices, including
restoring deleted objects, are more complicated and lengthened. For
example, special recovery mechanisms are required to restore group
memberships in universal or domain local groups of other domains in the
forest; the order of operation becomes very relevant for forest-recovery
scenarios needed to differentiate between rebuilds of GC versus non-GC
DCs.
Replication topology is more complex due to a larger number of connection objects.
Token
evaluation on GCs. Token evaluation depends upon the domain in which a
GC resides. This can cause intermittent and difficult to troubleshoot
application failures.
Trusts between
forests (that is, between the root domains of the forests) that are not
at Windows Server 2003 forest functional level behave like Windows 2000
cross forest trusts; that is, they are not transitive and need to be
created between each participating domain.
When
creating forest trusts (at 2003 forest functional level), they lack the
visibility of child domains in logon dialogue (even if trust is
transitive to child domains, users from “other” forests have to log on
using their User Principal Name [UPN]).
Additional DCs (security event logs, capital and licensing costs, Syskey, restore mode password management).
More
Flexible Single Master Operation (FSMO) role holders to manage and
monitor as each domain has a PDC (Primary Domain Controller) Emulator,
an RID master, and an infrastructure master.
Duplication
of policy for each domain. Domain-specific processes have to be
executed multiple times (for example, if you want to ensure Global
Policies in a forest).
A more complex
namespace is always more difficult to understand for help desk and other
support staff and can thus increase troubleshooting efforts.
More
administrative and service accounts, which potentially increase the
attack surface of an AD forest. Every domain Administrator of any child
domain could—by the nature of how security in AD is designed—elevate his
privileges to become an enterprise Administrator. As such, multiple
domains could potentially decrease the security of an AD forest.
Not-well-known
security issue: Kerberos tickets can still be requested by and obtained
for the disabled user in trusted domains within the forest (because DCs
of the trusted domains do not check the status of an account when
granting Kerberos tickets to access resources in their domain).
