The
placement of domain controllers in Windows Server 2008 R2 is a critical
factor in providing quality communication between Active Directory
clients and domain controllers. Without prompt response from a domain
controller, a user might have to wait several seconds to several minutes
to merely log on to the network or a computer to complete booting up.
Understanding the Role of the Active Directory Global Catalog
The global catalog in
Active Directory holds an indexed subset of frequently queried or
accessed objects in an Active Directory forest. Not all domain
controllers in the Windows Server 2008 R2 Active Directory are global
catalog servers by default. That being said, when installing a new
Windows Server 2008 R2 forest, the first Windows Server 2008 R2 domain
controller in the forest will be configured as a global catalog server
because this is a necessary service for Active Directory to function
properly. Also, the DCPROMO Wizard on Windows Server 2008 R2 defaults to
deploy all domain controllers as global catalog servers. Domain
controllers that are not global catalog servers can be established as
such through the following procedure:
1. | Open
Active Directory Sites and Services by clicking Start, All Programs,
Administrative Tools, Active Directory Sites and Services.
|
2. | In
the console tree, click the server to which you want to add the global
catalog. Do this by navigating to
Sites\<SiteName>\Servers\<ServerName>. Select the desired
server in the console or tree pane.
|
3. | In the Details pane, right-click NTDS Settings node of the selected server, and then click Properties.
|
4. | Select the Global Catalog check box on the General tab.
|
5. | Click OK to finish.
|
Note
To complete this
process, the administrator must be a member of the Enterprise Admins
group in the forest or a member of the Domain Admins group in the domain
of the selected domain controller or equivalent permissions. Security
best practices dictate that this process be performed with the
lowest-level user account and using the Run As Administrator option to
manage Active Directory Domain Services.
Placing Global Catalog/Domain Controllers
It
is important to understand that global catalog objects must be
physically located close to all objects in a network that require prompt
logon times and fast connectivity. Because a global catalog entry is
parsed for universal group membership every time a user logs on, this
effectively means that this information must be close at hand. This can
be accomplished by placing global catalog and domain controller (GC/DC)
servers on the same WAN site or by using a process called universal
group caching.
Exploring Universal Group Caching
Universal group caching is a
process by which an Active Directory site caches all universal group
membership locally so that the next time clients log on, information is
more quickly provided to the clients and they are able to log on faster.
Universal group caching can be
more effective than placing a GC/DC server locally because only those
universal groups that are relevant to a local site’s members are
replicated and are cached on the local domain controller. The downside
to this approach, however, is that the first logon for clients will
still be longer than if a local GC/DC were provided, and the cache
eventually expires, requiring another sync with a GC/DC.
Examining Global Catalog and Domain Controller Placement
As illustrated in
the preceding sections, decisions must be made regarding the most
efficient placement of DCs and GC/DCs in an environment. Determining the
placement of GC/DCs and universal group caching sites must be done with
an eye toward determining how important fast logons are for users in a
site compared with higher replication throughput. For many Windows
Server 2008 R2 environments, the following guidelines apply:
Sites with fewer than 50 users— Use a single DC configured with universal group caching.
Sites with 50–100 users— Use two DCs configured for universal group caching.
Sites with 100–200 users— Use a single GC server and single DC server.
Sites with 200+ users— Alternate adding additional DCs and GC/DCs for every 100 users.
The recommendations
listed here are generalized and should not be construed as relevant to
every environment. Some scenarios might call for variations to these
approaches, such as when using Microsoft Exchange Server in a site where
Exchange requires close connection to a global catalog server (not a
caching controller) or in single domain/single forest environments with
limited sites where all domain controllers can be global catalog
servers. However, these general guidelines can help to size an Active
Directory environment for domain controller placement.
Examining Read-Only Domain Controllers
A
concept similar to universal group caching, one of the new features for
Active Directory Domain Services in Windows Server 2008 and Windows
Server 2008 R2 is the Read-Only Domain Controller (RODC). An RODC server
is a new type of domain controller that contains read-only replicas of
the domain Active Directory database. As shown in Figure 1,
this is well suited for branch offices or other locations where
physical security of the domain controller can be compromised, where
excessive wide area networking activity might have a negative impact on
productivity, or where other applications must run on a domain
controller and be maintained by an understaffed technical department or
an IT department with little technical knowledge. The benefits of RODCs
are a read-only Active Directory Domain Services database, inbound-only
replication, credential caching, administrator role separation, and
read-only DNS.
Although an RODC can
replicate data from domain controllers running Windows Server 2003, it
can only replicate updates of the domain partition from a Windows Server
2008 or
Windows Server 2008 R2 domain controller running within the same
domain. Because RODCs cannot perform outbound replication, they cannot
be a source domain controller for any other domain controller. In
contrast, writable Windows Server 2008 R2 domain controllers and Windows
Server 2008 domain controllers can perform inbound and outbound
replication of all available partitions. Thus, they do not require the
same placement considerations required by RODCs.
Because an RODC can
replicate the domain partition only from a writable Windows Server 2008
R2 or Windows Server 2008 domain controller, careful planning is
required. The placement of an RODC and writable Windows Server 2008 R2
domain controllers is important as their deployment might be affected by
the site topology and network constraints; each RODC requires a
writable Windows Server 2008 R2 domain controller for the same domain
from which the RODC directly replicates. This requires a writable
Windows Server 2008 R2 domain controller be placed in the nearest site
that contains a direct site link to the site in the topology that
includes the RODC, as illustrated in Figure 11.22.
An RODC server contains
the same objects and attributes as a writable domain controller with the
exception of user passwords. The difference between an RODC server and
the writable domain controller is that changes that originate locally
are not made to the RODC replica itself but are forwarded to a writable
domain controller and then replicated back to the RODC server. Also, the
Active Directory administrator can determine or limit which user
account password or credentials can be cached on a remote RODC. This
improves security by reducing the risk or exposure of the read-only
Active Directory database on the RODC.
Active Directory
administrators might also specifically configure an RODC to cache user
credentials. The first time a user attempts to authenticate to an RODC,
the RODC forwards the request to a writable domain controller. When
authentication is successful, the RODC requests a copy of the user
credentials. By default, the RODC does not cache the passwords of any
domain users so administrators must modify the default password
replication policy for the RODC to allow the RODC to authenticate users
and their computers when the WAN link to the hub site is unavailable.
The active Password Replication Policy determines if the credentials are
allowed to be replicated and cached on the RODC. The next time that
user attempts to log on, the request is directly serviced by the RODC.
This occurs until the RODC is informed by the writable domain controller
that a user credential change has occurred. In the scenario, end-user
productivity is vastly improved because of the efficient logon process.
Connectivity issues commonly experienced by branch offices such as poor
network bandwidth or WAN latency are mitigated because the user is
authenticated on the locally deployed RODC. Because the RODC only
performs inbound replication, network traffic is also reduced. To allow a
user account’s password to be cached on a Read-Only Domain Controller,
the user will need to be added to the default “Allowed RODC Password
Replication Group” or the user can be added specifically to the Password
Replication Policy on the specific Read-Only Domain Controllers.
RODCs also help reduce
security risks and administration tasks associated with branch office
servers. Because Active Directory Domain Services also manages a list of
all credentials stored on RODCs, if an RODC is compromised,
administrators can force a password reset for all user credentials
stored on that RODC. To further mitigate security risks, RODCs
cannot operate as an operation role holder (Flexible Single Master
Operations [FSMO]) because this role requires writing of information to
the Active Directory database. Also, RODCs cannot act as a bridgehead
server because bridgehead servers are designed to replicate changes from
other sites.
Another feature of RODCs
is delegation of installation and management task to non-administrative
personnel at a branch office. Nontechnical branch office personnel can
perform an installation by attaching a server to the RODC account that a
domain administrator has previously created. This eliminates the need
to use a home office staging site for branch office domain controllers.
This feature also eliminates the need to send installation media and a
domain administrator to branch locations, which reduces the cost of
server setup and improves setup time at branch locations.
