1. Authentication and Domain Controller Placement in a Branch
Office
Consider a scenario in which an enterprise is characterized by a
hub site and several branch offices. The branch offices connect to the
hub site over WAN links that might be congested, expensive, slow, or
unreliable. Users in the branch office must be authenticated by Active
Directory to access resources in the domain. Should a DC be placed in
the branch office?
In branch office scenarios, many of the services provided by IT
are centralized in a hub site that is carefully maintained by the IT
staff. In larger organizations, the hub site may include a robust
datacenter. Branch offices, however, are often smaller sites at which
no datacenter exists. In fact, many branch offices have no significant
IT presence other than a small handful of servers. There may be no
physically secure facility to house branch office servers. There may
be few, if any, local IT staff to support the servers.
If a DC is not placed in the branch office, authentication and
service ticket activities are directed to the hub site
over the WAN link. Authentication occurs when a user first logs on to
his computer in the morning. Service tickets are
a component of the Kerberos authentication mechanism used by AD DS
domains. You can think of a service ticket as a key issued by the
domain controller to a user. The key allows the user to connect to a
service such as the file and print services on a file server. When a
user first tries to access a specific service, the user’s client
requests a service ticket from the domain controller. Because users
typically connect to multiple services during a workday, service
ticket activity happens regularly. Authentication and service ticket
activity over the WAN link between a branch office and a hub site can
result in slow or unreliable performance.
If a DC is placed in the branch office, authentication is much
more efficient but there are several potentially significant risks. A
DC maintains a copy of all attributes of all objects in its domain,
including secrets such as information related to user passwords. If a
DC is accessed or stolen, it becomes possible for a determined expert
to identify valid user names and passwords, at which point the entire
domain is compromised. At a minimum, you must reset the passwords of
every user account in the domain. Because the security of servers at
branch offices is often less than ideal, a branch office DC
poses a considerable security risk.
A second concern is that changes to the Active Directory
database on a branch office DC replicate to the hub site and to all
other DCs in the environment. Therefore, corruption to the branch
office DC poses a risk to the integrity of the enterprise directory
service. For example, if a branch office administrator
performs a restore of the DC from an outdated backup, there can be
significant repercussions for the entire domain.
The third concern relates to administration. A branch office
domain controller might require maintenance—for example,
a new device driver. To perform maintenance on a standard domain
controller, you must log on as a member of the Administrators group on
the domain controller, which means you are effectively an
administrator of the domain. It might not be appropriate to grant that
level of capability to a support team at a branch office.
2. Read-Only Domain Controllers
These concerns—security, directory service integrity, and
administration—left many enterprises with a difficult choice to make,
and there was no best practice answer. Windows Server 2008 introduced
the RODC, which is designed specifically to address the branch office
scenario. An RODC is a domain controller, typically placed in the
branch office, that maintains a copy of all objects in the domain and
all attributes except for secrets such as password-related properties.
When a user in the branch office logs on, the RODC receives the
request and forwards it to a domain controller in the hub site for
authentication.
You can configure a password replication policy (PRP) for the RODC that
specifies user accounts the RODC is allowed to cache. If the user
logging on is included in the PRP, the RODC caches that user’s
credentials, so the next time authentication is requested the RODC can
perform the task locally. As users who are included in the PRP log on,
the RODC builds its cache of credentials so that it can perform
authentication locally for those users. These concepts are illustrated
in Figure 1.
Because the RODC maintains only a subset of user credentials, if
the RODC is compromised or stolen, the effect of the security exposure
is limited. Only the user accounts that had been cached on the RODC
must have their passwords changed. Writable domain controllers
maintain a list of all cached credentials on individual RODCs. When
you delete the account of the stolen or compromised RODC from Active
Directory, you have the option to reset the passwords of all user
accounts that were cached on the RODC. The RODC replicates changes to
Active Directory from DCs in the hub site. Replication is one way,
from a writable domain controller to the RODC. No changes to the RODC
are replicated to any other domain controller. This eliminates the
exposure of the directory service to corruption resulting from changes
made to a compromised branch office DC. Finally, RODCs, unlike
writable DCs, have some local groups, most notably a local
Administrators group. You can give one or more local support personnel
the ability to maintain an RODC fully, without granting them the equivalence of
domain administrators.
The high-level steps to install an RODC are as
follows:
-
Ensure that the forest functional level is Windows Server
2003 or higher.
-
If the forest has any DCs running Microsoft Windows Server
2003, run ADPrep /RODCPrep.
-
Ensure that at least one writable DC is running Windows
Server 2008 or Windows Server 2008 R2.
-
Install the RODC.
Each of these steps is detailed in the following
sections.
Verifying and Configuring Forest Functional Level of Windows
Server 2003 or Higher
Functional levels enable features unique to specific versions
of Windows and are, therefore, dependent on the versions of Windows
running on domain controllers. If all domain controllers are
Windows Server 2003 or later, the domain functional level can be set
to Windows Server 2003. If all domains are at Windows Server 2003
domain functional level, the forest functional level can be set to
Windows Server 2003.
RODCs require that the forest functional level is Windows
Server 2003 or higher. That means that all domain controllers in the
entire forest are running Windows Server 2003 or later.
To determine the functional level of your forest:
-
Open Active Directory Domains And Trusts.
-
In the console tree, right-click the root node, Active
Directory Domains And Trusts [Server Name], and then click
Properties.
-
Verify the forest functional level, as shown in Figure 2.
Any user can verify the forest functional level in this way.
No special administrative credentials are required to view the
forest functional level.
If the forest functional level is not at least Windows Server
2003, examine the properties of each domain to identify any domains
for which the domain functional level is not at least Windows Server
2003. If you find such a domain, you must ensure that all domain
controllers in the domain are running Windows Server 2003. Then, in
Active Directory Domains And Trusts, right-click the domain and
choose Raise Domain Functional Level. After you have raised each
domain functional level to at least Windows Server 2003, right-click
the root node of the Active Directory Domains And Trusts snap-in and
choose Raise Forest Functional Level. In the Select An Available
Forest Functional Level drop-down list, choose Windows Server 2003
and click Raise. You must be an administrator of a domain to raise
the domain’s functional level. To raise the forest functional level,
you must be either a member of the Domain Admins group in the forest
root domain or a member of the Enterprise Admins group.
If you are upgrading an existing forest to include domain controllers running Windows Server 2008 or
Windows Server 2008 R2, you must run ADPrep /RODCPrep. This command configures permissions so that
RODCs can replicate DNS application directory partitions. If you are
creating a new Active Directory forest that will have only domain
controllers running Windows Server 2008 or Windows Server 2008 R2,
you do not need to run ADPrep /RODCPrep.
The command is found in the \support\adprep folder of the
Windows Server 2008 or Windows Server 2008 R2 installation DVD. Copy
the folder to the domain controller acting as the schema master. Log on to the schema
master as a member of the Enterprise Admins group, open Command
Prompt, change directories to the ADPrep folder, and type adprep /rodcprep.
Before running ADPrep /RODCPrep, you must run ADPrep
/ForestPrep and ADPrep /DomainPrep.
Placing a Writable Windows Server 2008 or Windows Server 2008
R2 Domain Controller
An RODC must replicate domain updates from a writable
domain controller running Windows Server 2008 or Windows Server 2008
R2. It is critical that an RODC can establish a replication connection with a
writable Windows Server 2008 or Windows Server 2008 R2 domain
controller. Ideally, the writable domain controller should be in the
closest site—the hub site. If you
want the RODC to act as a DNS server, the writable Windows Server
2008 or Windows Server 2008 R2 domain controller must also host the
DNS domain zone.
After completing the preparatory steps, you can install an
RODC. An RODC can be either a full or Server Core installation of
Windows Server 2008 or Windows Server 2008 R2. With a full
installation of Windows Server 2008 or Windows Server 2008 R2, you
can use the Active Directory Domain Services Installation Wizard to
create an RODC. Simply select Read-Only Domain Controller (RODC) on the Additional
Domain Controller Options page of the wizard, as shown in Figure 3.
Note
PRACTICE IT
Exercise 1, “Install an RODC,” in the practice at the end of this lesson walks you
through the use of the Active Directory Domain Services
Installation Wizard to create an RODC.
Alternately, you can use the dcpromo.exe command with the
/unattend switch to create the RODC. On a
Server Core installation of Windows Server 2008 or Windows Server
2008 R2, you must use the DCPromo /unattend command.
It is also possible to delegate the installation of the RODC,
which allows a user who is not a domain administrator to create the
RODC by adding a new server in the branch office and running
Dcpromo.exe. To delegate the installation of an RODC, pre-create the
computer account for the RODC in the Domain Controllers OU and
specify the credentials that will be used to add the RODC to the
domain. That user can then promote a server running Windows Server
2008 or Windows Server 2008 R2 as an RODC, using the prestaged RODC
account. The server must be a member of a workgroup—not of the
domain—when creating an RODC by using delegated
installation.
