Windows Server 2008 R2 Unleashed (259 page)

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.