Active Directory Design and Security Concepts - MCTS Guide to Microsoft Windows Server 2008 Active Directory Configuration - page 139

frequent branch offices with different domains must authenticate to their home domain. If
their home domain isn't available for some reason, they can't log on to the network.

Although a single domain structure is usually easier and less expensive than a multidomain
structure, it's not always better. Using more than one domain makes sense or is even a necessity
in the following circumstances:
• Compatibility with a Windows NT domain —If you need to maintain an existing Windows
NT domain structure, the easiest option is to use multiple domains and create an external
trust between them.
• Need for differing account policies —Account policies that govern password and account
lockout policies apply to all users in a domain. If you need to have differing policies for
different business units, using separate domains is the best way to meet this requirement.
A new feature in Windows Server 2008 called fine-grained password policies can be used
to apply different password policies for users or groups in a domain, but this feature can
be difficult to manage when many users are involved.
• Need for different name identities —Each domain has its own name that can represent a
separate company or business unit. If each business unit must maintain its own identity,
child domains can be created in which part of the name is shared, or multiple trees with
completely different namespaces can be created.
• Replication control —Replication in a large domain maintaining several thousand objects
can generate substantial traffic. When multiple corporate locations are connected through
a WAN, the amount of replication traffic could be unacceptable. Replication traffic can be
reduced by creating separate domains for key locations because only global catalog repli-
cation is required between domains.
• Need for internal versus external domains —Companies that run public Web servers often
create a domain used only for publicly accessible resources and another domain used for
internal resources.
• Need for tight security —With separate domains, stricter resource control and administra-
tive permissions are easier. If a business unit prefers to have its own administrative staff,
separate domains must be created.

4

Understanding Sites
As discussed in Chapter 2, a site is one of Active Directory's physical components, along with a
domain controller. An Active Directory site represents a physical location where domain controllers
are placed and group policies can be applied. When you're designing the logical components of
Active Directory, such as domains and OUs, you don't need to consider the physical location of
objects. In other words, an OU named Accounting could contain user accounts from both Chicago
and New Orleans, and the domain controllers holding the Active Directory database could be
located in San Francisco and New York. As long as there's a network connection between the loca-
tion where a user logs on and the location of the domain controller, the system works.
Having said that, having a domain controller near the accounts using it makes sense.
Authentication and resource access works fine across a WAN link, but if a corporate location
contains several users, placing domain controllers in that location is more efficient. Performance
and reliability are less predictable on slower WAN links than on LAN links. So the extra cost of
additional domain controllers can be outweighed by the productivity gained from faster, more
reliable network access.
When the first domain controller of a forest is installed, a site is created named Default-First-
Site-Name. Any additional domain controllers installed in the forest are assigned to this site until
additional sites are created. Figure 4-17 depicts a single-site domain in two locations at the top
and the same domain defined as two sites at the bottom.