Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
traditional writable domain controllers store both the user’s account information and
password on a domain controller, ultimately leaving users very vulnerable.
Because an RODC by default does not store user accounts or passwords locally, branch
ptg
office users must authenticate against a writable domain controller in a hub site. This is
often not practical for branch office users, especially if the WAN link between the sites is
slow or unavailable. In this case, it is possible to configure password replication caching
for specific branch office users on the branch office RODC. After the credentials are
cached on the RODC, the domain controller will service users the next time they try to
log on and every other time after that until the credentials change. Typically, a branch
office only has a few users, so only a subset of an organization’s users’ accounts are cached
on the RODC at the branch office, limiting the exposure of credentials in the event of a
system breach.
To provide an additional level of security and at the same time reduce the amount of
information exposed in the event an RODC is stolen, a domain administrator can use
tools within Active Directory Users and Computers to delete the RODC from the Active
Directory domain/forest and reset the passwords for user accounts cached on the RODC.
NOTE
By default, security groups with high privileges such as Domain Administrators and
Enterprise Administrators are configured to never allow their passwords to replicate to
RODCs.
Administrator Role Separation
Organizations are encouraged to use RODCs when there is a need to satisfy unique admin-
istrative requirements and to maintain administrator role separation and isolation. The
use of an RODC is especially encouraged if the domain controller situated in a branch
office hosts more than one server function or server role, such as a print server, messaging
1310
CHAPTER 32
Optimizing Windows Server 2008 R2 for Branch Office
Communications
server, file server, and much more. The use of an RODC is also recommended when there
are other applications installed on the domain controller. Traditionally, in this situation
the administrator of these applications has privileges not only to the applications, but also
to the entire Active Directory, which can pose a threat. With RODC, however, you can
delegate permissions to local administrators, granting them rights to a particular server,
roles, or LOB applications without ever granting them access to Active Directory or
domain resources beyond the scope of the branch. As a result, the local administrator at
the branch can perform his or her administrator work activities effectively without
compromising the entire Active Directory environment.
Read-Only DNS
When using RODCs, it is possible to add the DNS role/service to the RODC. After the DNS
service is added to an RODC, the RODC will replicate Active Directory–integrated DNS
information such as DNS-related AD partitions, including both the ForestDNS and
DomainDNS zones.
Running DNS on an RODC is very similar to running DNS on a writable domain
controller. Users can query the local DNS server residing on the branch office RODC for A
records and other DNS-related items such as Internet requests. However, unlike traditional
writable domain controllers, DNS on RODC does not support dynamic updates. The DNS
zone information is entirely read-only.
ptg
If a client wants to update their DNS A or PTR record in the local branch office, the RODC
will send a DNS replicate-single-object change request to a writable domain controller
running the traditional DNS service. The DNS change for the client will occur on the
writable DNS server and, eventually, the change will be propagated back to the RODC via
unidirectional Active Directory replication.
NOTE
It is a best practice to have clients in the branch office point to their local RODC DNS
server for DNS lookups. This can be achieved via an Active Directory group policy or
DNS lookup list based on DHCP.
Read-Only SYSVOL
In Windows Server 2008, it was still possible for changes to be made to the sysvol folder of
an RODC. When changes were made to the contents of the sysvol folder, those changes
persisted until being overwritten by the next DFS Replication cycle. In Windows Server
2008 R2, Microsoft made changes to the RODC functionality such that the sysvol folder is
now read-only on an RODC.
Installing a Read-Only Domain Controller
RODCs can be implemented on a full or core installation of Windows Server 2008 or
Windows Server 2008 R2. The installation can be performed in a standard or in a staged
manner. Because RODCs are tailored toward branch office implementations where physi-
Installing a Read-Only Domain Controller
1311
cal security and theft are a concern, it is a best practice to heighten security even further
by installing an RODC on a Server Core installation. A Server Core installation mini-
mizes surface attacks and provides the maximum amount of protection in the event of a
system breach.
The upcoming sections include step-by-step procedures for installing an RODC on a full
32
installation of Windows Server 2008 R2, installing an RODC on a Windows Server 2008
R2 Server Core installation, and performing a staged installation. Before launching into
the procedures, however, let us examine the prerequisites associated with installing
RODCs and understanding the limitations associated with using an RODC.
NOTE
The following steps assume an RODC install is being performed using Windows Server
2008 R2. However, RODC functionality was first introduced in Windows Server 2008 and
as such the installation can also be completed using that version of Windows Server.
Examining Prerequisite Tasks When Deploying an RODC
The following bullets list the items you should review and complete before installing
RODCs:
ptg
. Active Directory running on Windows Server 2003 or Windows Server 2008 R2 must
already exist in the environment.
. The Active Directory schema must support the Windows Server 2008 R2 server
extensions.
. The forest and domain functional level must be running Windows Server 2003 or
higher.
. At least one domain controller within the domain must be running Windows
Server 2008 R2.
. The PDC Emulator FSMO role must be running Windows Server 2008 R2.
. A regular non-read-only (writable) domain controller must already exist within the
Active Directory infrastructure.
. The RODC cannot be the first domain controller within the Active Directory infra-
structure.
. If the DNS service will be configured on a Server Core installation, a non-read-only
DNS server must be present within the domain.
Limitations Associated with Windows Server 2008 R2 RODCs
There are situations when RODCs cannot be used. This is the case with bridgehead servers
and operations master role holders. For example, a Windows Server 2008 R2 bridgehead
server is responsible for managing Active Directory replication from a physical site.
Because an RODC can only perform inbound unidirectional replication, it cannot be
1312
CHAPTER 32
Optimizing Windows Server 2008 R2 for Branch Office
Communications
designated as a bridgehead server because these servers must support both inbound and
outbound replication.
An RODC also cannot function as a Flexible Single Master Operations (FSMO) role holder.
Each FSMO role needs to write information to an Active Directory domain controller. As
an example, consider extending the Active Directory schema for Microsoft Exchange
Server 2007. The new schema extensions would be written on a domain controller to
support Exchange 2007. The schema extensions would fail on an RODC because the
domain controller is not writable, which, of course, explains why an RODC cannot
perform the FSMO role.
To add to its limitations, out-of-the-box RODCs cannot authenticate a smart card logon.
This is because the Enterprise Read-Only Domain Controller (ERODC) group is not defined
in the domain controller certificate template by default. Because the ERODC is not associ-
ated with the default group defined in the template, the RODC is not automatically
enrolled in the certificate process, which is a requirement for authenticating smart card
logons. Unlike the limitations of RODCs stated in the previous two paragraphs, there is a
way to work around this particular drawback so an RODC can authenticate a smart card
logon. The following changes must be orchestrated in the certificate templates for an
RODC to support smart card logons:
. ERODC group permissions for Enroll must be set to Allow on the Domain Controller
ptg
certificate template.
. ERODC group permissions for Enroll and Autoenroll must be set to Allow on the
Domain Controller Authentication and Directory E-Mail Replication certificate
template.
. The Authenticated Users group permissions must be set to Allow Read on the Domain
Controller Authentication and Directory E-Mail Replication certificate template.
Conducting an RODC Installation
As mentioned earlier, an RODC can be implemented on either a full installation of
Windows Server 2008 R2 or on a Windows Server 2008 R2 Server Core installation. The
upcoming sections include step-by-step instructions on installing an RODC for both types
of scenarios.
Installing an RODC on a Full Installation of Windows Server 2008 R2
Before installing an RODC within your Active Directory infrastructure, ensure the prereq-
uisites are met and you fully understand the circumstances under which the RODC should
not be used or else you will jeopardize the success of your installation.
Now, let’s look at how to install an RODC; this example assumes the base Windows Server
2008 R2 system has already been installed. The installation is very similar to a traditional
domain controller installation; however, the final steps include Read-Only Domain
Controller settings. To conduct the installation with the Active Directory Domain Services
Wizard, follow these steps:
1. Log on to the new branch office Windows Server 2008 R2 system with an account
that has domain administrative privileges.
Installing a Read-Only Domain Controller
1313
2. Click Start, Run, and type dcpromo.exe. Click OK to commence the full installation
of an RODC. Alternatively, you can add the Active Directory Domain Services role
via Server Manager.
NOTE
32
The Active Directory Domain Services Wizard checks to see if the Active Directory Domain
Services binaries are installed. If they are not, the wizard will begin installing them.
3. On the Welcome to the Active Directory Domain Services Wizard page, click Next to
commence the installation of Active Directory Domain Services (AD DS) on the server.
4. Review the warning on the Operating System Compatibility page, and then click Next.
5. On the Choose a Deployment Configuration page, ensure the Existing Forest option
is selected, and then specify Add a Domain Controller to an Existing Domain. Click
Next to continue, as illustrated in Figure 32.1.
ptg
FIGURE 32.1
Adding a new RODC to an existing domain.
6. On the Network Credentials page, type the name of any domain in the forest where
you plan to install the domain controller. After the domain name is entered, specify
the account credentials that have permissions to conduct the dcpromo process and
that will be used to perform the installation. You can either use the current logged-
on credentials or specify alternate credentials. Click Next to continue, as displayed in
Figure 32.2.