lhbog plan

Planning and Deploying Read-Only Domain Controllers

Microsoft Corporation

Published: June 2008

AbstractA read-only domain controller (RODC) is a new type of domain controller in the

Windows Server® 2008 operating system. This guide explains what RODCs are, how they

function, and how you can use them in various scenarios.

Information in this document, including URL and other Internet Web site references, is subject to

change without notice. Unless otherwise noted, the example companies, organizations, products,

domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,

and no association with any real company, organization, product, domain name, e-mail address,

logo, person, place, or event is intended or should be inferred. Complying with all applicable

copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part

of this document may be reproduced, stored in, or introduced into a retrieval system, or

transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or

otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any

written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

© 2008 Microsoft Corporation. All rights reserved.

Active Directory, Microsoft, Windows, Windows NT, and Windows Server are either registered

trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their

respective owners.

Contents

Planning and Deploying Read-Only Domain Controllers................................................................7

Purpose of this guide................................................................................................................... 7

Related information about new features in Active Directory Domain Services............................8

Related planning and deployment guides....................................................................................8

Understanding Planning and Deployment for Read-Only Domain Controllers................................9

What Is an RODC?......................................................................................................................... 9

Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication.........................10

Read-only SYSVOL................................................................................................................... 12

System attributes that are written on an RODC.........................................................................13

RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC

.................................................................................................................................................. 14

RODC FAS................................................................................................................................ 14

Credential caching.....................................................................................................................16

Key points for authentication through an RODC........................................................................19

Administrator Role Separation......................................................................................................20

Differences Between an RODC and a Writable Domain Controller...............................................21

Advantages That an RODC Can Provide to an Existing Deployment...........................................22

Security.................................................................................................................................. 22

Manageability......................................................................................................................... 23

Scalability............................................................................................................................... 24

Prerequisites for Deploying an RODC..........................................................................................26

Prepare a Windows 2000 or Windows Server 2003 Forest Schema for a Domain Controller That

Runs Windows Server 2008......................................................................................................27

Prepare a Windows 2000 or Windows Server 2003 Domain for a Domain Controller That Runs

Windows Server 2008...............................................................................................................28

Prepare a Forest for a Read-Only Domain Controller...................................................................29

Known Issues for Deploying RODCs............................................................................................29

Apply the RODC compatibility pack or plan a workaround for any known issue........................30

Client operating system updates...............................................................................................34

Group Policy tools can apply updates inadvertently to SYSVOL on an RODC..........................35

Adprep /rodcprep will log an error if the infrastructure master for an application directory

partition is not available..........................................................................................................36

Applications can fail to register SPNs in a site with an RODC...................................................36

Repadmin /PRP might return only a subset of accounts...........................................................37

RODC Placement Considerations................................................................................................37

Placing RODCs with site link bridging.......................................................................................38

Placing RODCs without site link bridging..................................................................................39

How Operations in a Branch Site with an RODC Are Affected When the WAN Is Not Available...44

Client operations........................................................................................................................ 45

Application operations...............................................................................................................46

Planning for Application Compatibility with RODCs......................................................................47

Directory-enabled applications............................................................................................49

Impact of RODC on directory-enabled applications............................................................50

Problem 1: Inefficient or failed Read operations.................................................................50

Problem 2: Failed Write operations.....................................................................................51

Problem 3: Failed Write-Read-Back operations..................................................................51

Testing application compatibility for RODCs...........................................................................51

Step 1: Set up the test environment....................................................................................51

Step 2: Categorize the applications....................................................................................52

Step 3: Test your application...............................................................................................53

Step 4: Fix broken or inefficient applications.......................................................................54

Sites with Multiple Domain Controllers..........................................................................................54

Placing an RODC and a writable domain controller from the same domain in the same site....55

Placing multiple RODCs from the same domain in the same site..............................................56

Placing an RODC and a domain controller (writable or read-only) from different domains in the

same site................................................................................................................................ 57

RODC Installation......................................................................................................................... 59

Choosing whether to upgrade an existing domain controller or install a new domain controller59

Upgrading an existing domain controller................................................................................59

Known issues for upgrading domain controllers.................................................................61

Installing a new domain controller..........................................................................................62

Choosing whether to install the Server Core or the Full installation options and using BitLocker

............................................................................................................................................... 62

Using the Server Core installation for RODCs....................................................................63

Considerations for installing Server Core and upgrading domain controllers..................64

Using BitLocker on RODCs................................................................................................64

Using virtualization....................................................................................................................65

Installing writable domain controllers.........................................................................................67

Installing RODCs....................................................................................................................... 67

Staged installation.................................................................................................................. 68

Direct installation....................................................................................................................69

Installing AD DS from Media.........................................................................................................70

Direct Installation Method.............................................................................................................72

Performing a Staged RODC Installation.......................................................................................87

Performing a staged RODC installation by using the Windows interface..................................88

Performing a staged RODC installation by using an answer file...............................................91

Creating the RODC account...................................................................................................92

Attaching a server to an RODC account................................................................................94

Performing a staged RODC installation by entering installation parameters at the command line

............................................................................................................................................... 96

Post-Installation Configuration......................................................................................................98

Verify installation........................................................................................................................ 99

RODC Administration..................................................................................................................100

Using remote management tools to administer an RODC.......................................................100

Using RSAT.......................................................................................................................... 100

Using WinRM and WinRS....................................................................................................101

Delegating local administration of an RODC...........................................................................101

Steps and best practices for setting up ARS........................................................................102

Use a security group instead of individual user accounts.................................................105

Restrict logon with a privileged account in a site that has an RODC................................105

Cache the password for the delegated RODC administrator............................................106

Managing passwords and the PRP.........................................................................................106

Default PRP......................................................................................................................... 106

Modifying the PRP...............................................................................................................107

No accounts are cached......................................................................................................108

Most accounts are cached...................................................................................................108

Few accounts are cached....................................................................................................109

Additional tasks and tools for managing passwords................................................................110

Prepopulate the password cache for an RODC................................................................110

View current credentials that are stored on an RODC......................................................110

Review whose accounts have been authenticated to an RODC.......................................110

Clear cached passwords that are cached on an RODC if it is stolen................................111

Adding attributes to the RODC filtered attribute set.................................................................112

Default RODC FAS...............................................................................................................113

Installing Remote Server Administration Tools............................................................................114

Displaying Administrative Tools................................................................................................115

Administering the Password Replication Policy..........................................................................116

Viewing the PRP...................................................................................................................... 116

Reviewing the accounts that are authenticated to an RODC...................................................118

Clearing the authenticated accounts list..................................................................................120

Configuring the PRP................................................................................................................120

Moving accounts from the Auth2 list to the Allow list...............................................................123

Reviewing PRP resultant policy...............................................................................................124

Reviewing accounts with cached passwords on the RODC....................................................125

Prepopulating the password cache for an RODC....................................................................127

See Also.................................................................................................................................. 129

Adding Attributes to the RODC Filtered Attribute Set..................................................................129

Determine and then modify the current searchFlags value of an attribute...............................130

Verify that an attribute is added to the RODC FAS..................................................................131

Appendix A: Technical Reference Topics....................................................................................131

Password changes on an RODC.............................................................................................131

DNS updates for clients that are located in an RODC site......................................................135

User and computer credentials................................................................................................137

How the authentication process works on an RODC...............................................................138

Computer account authentication using an RODC...............................................................139

Initial user logon process using an RODC...........................................................................140

Subsequent user logons after credentials are cached on the RODC...................................142

Resource access using authentication by an RODC............................................................144

How the Windows Time Service Works on an RODC..............................................................145

Security mechanisms that are related to the Windows Time service on an RODC..............147

Registry entries that are specific to the Windows Time service forwarding mechanism on an

RODC............................................................................................................................... 148

Appendix B: Events That Are Related to RODCs........................................................................150

Appendix C: List of Acronyms Used in this Guide.......................................................................156

Planning and Deploying Read-Only Domain Controllers

This section provides an overview of the guide, including what is covered in this guide as

opposed what is covered in other related guides.

Purpose of this guideThe purpose of this guide is to explain what a read-only domain controller (RODC) is, how an

RODC works, and how you can plan for and deploy RODCs in your environment. The guide is

meant to be a comprehensive resource that provides all the information that you might need in

order to use an RODC. It will be updated continuously as additional information about using

RODCs is learned as a result of customer experiences and product team recommendations.

Ultimately, the guide will provide guidelines for planning and deploying RODCs in each of the

following scenarios:

Branch office

Perimeter network (also known as DMZ)

Internet

The first update for this guide will cover only the branch office scenario of the three scenarios

mentioned. This is the most common scenario for organizations that plan to use an RODC. The

guide will be updated with information about planning for and deploying an RODC in the other

scenarios as more knowledge and expertise becomes available.

This guide consists of the following sections:

Understanding Planning and Deployment for Read-Only Domain Controllers

This section explains what an RODC is, and it covers general issues that affect any of the

scenarios that include an RODC. This chapter also provides steps for installing and administering

an RODC.

Planning and Deploying RODCs in Branch Offices

This section will describe special planning and deployment steps for placing RODCs in branch

offices.

Appendix A: Technical Reference Topics

This section includes supplemental information that can help some organizations with planning an

RODC deployment.

Appendix B: Events That Are Related to RODCs

This appendix covers events that can be logged for various operations RODCs.

Appendix C: List of Acronyms Used in this Guide

7

This appendix includes some of the acronyms that are commonly used in discussion about

RODCs.

Related information about new features in Active Directory Domain Services RODCs are one of many new features that are introduced in Active Directory® Domain Services

(AD DS) in the Windows Server® 2008 operating system. The following links provide more

information about the other new Active Directory features and the steps that you can take to try

them out:

What's New in Active Directory Domain Services in Windows Server 2008

(http://go.microsoft.com/fwlink/?LinkID=117789)

This document provides an overview of new features in AD DS.

Getting Started: AD DS (http://go.microsoft.com/fwlink/?LinkID=117791)

This page contains links to step-by-step guides for setting up Windows Server 2008 domain

controllers and implementing the new features in AD DS.

Related planning and deployment guidesThe following guides cover related scenarios for planning and deploying AD DS and RODCs:

Upgrading Active Directory Domains to Windows Server 2008 AD DS Domains


This guide provides information about deploying writable Windows Server 2008 domain

controllers and upgrading to Windows Server 2008 from Windows 2000 Server domains and

Windows Server 2003 domains.

Designing the Logical Structure for Windows Server 2008 AD DS


This guide explains design considerations for creating a new forest with domain controllers

that run Windows Server 2008.

Designing the Site Topology for Windows Server 2008 AD DS


This guide explains how to plan sites and site links for a new forest.

Branch Infrastructure Implementation Solution for Windows Server 2008

(http://go.microsoft.com/fwlink/?LinkId=120084)

This guide provides guidance to help organizations design complete branch office

infrastructures. It provides planning guidance for the services in a typical branch office

design, including core services such as Dynamic Host Configuration Protocol (DHCP), file

server, and print server. It also covers extended services, such as virtualization, Web caching

services, messaging services, and collaboration services.

8

http://go.microsoft.com/fwlink/?LinkId=120084

http://go.microsoft.com/fwlink/?LinkID=89026





SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process

(http://go.microsoft.com/fwlink/?LinkId=119296)

If you are currently using File Replication Service (FRS) for replication of the SYSVOL shared

folder on domain controllers, you will have to migrate to using DFS Replication Service for

SYSVOL replication after you raise the domain functional level to Windows Server 2008. You

can use the Dfsrmig.exe tool to perform the migration procedure.

Windows Server 2003 Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?

LinkID=28523)

This guide provides recommendations for deploying domain controllers that run

Windows Server 2003 in a branch office environment. It also includes scripts and tools to help

you monitor the environment. Some of the tools, such as the Active Directory Load Balancing

tool (ADLB.exe), are useful for monitoring domain controllers that run Windows Server 2008

in addition to monitoring domain controllers that run Windows Server 2003.

Understanding Planning and Deployment for Read-Only Domain Controllers

This section of the guide explains what a read-only domain controller (RODC) is. It also describes

some planning issues to consider before you deploy an RODC. This section includes procedures

for installing and administering an RODC.

This section includes the following topics:

What Is an RODC?

Prerequisites for Deploying an RODC

Known Issues for Deploying RODCs

RODC Placement Considerations

RODC Installation

RODC Administration

What Is an RODC?

Read-only domain controllers (RODCs) are a new feature of Active Directory Domain Services

(AD DS) in Windows Server 2008. RODCs are additional domain controllers for a domain that

host complete, read-only copies of the partitions of the Active Directory database and a read-only

copy of the SYSVOL folder contents. By selectively caching credentials, RODCs address some of

the challenges that enterprises can encounter in branch offices and perimeter networks (also

known as DMZs) that may lack the physical security that is commonly found in datacenters and

hub sites. RODCs also offer a number of manageability improvements that are described in this

guide. This section describes how RODCs work with the rest of the Active Directory environment,

9




the main differences between RODCs and writable domain controllers, and the RODC features

that can help resolve a number of security or manageability issues.

Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication

RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an

RODC

Administrator Role Separation

Differences Between an RODC and a Writable Domain Controller

Advantages That an RODC Can Provide to an Existing Deployment

Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication

This topic explains how the read-only copies of the Active Directory database and the SYSVOL

shared folder work with unidirectional replication to prevent any potentially malicious changes on

a compromised read-only domain controller (RODC) from affecting the rest of the forest.

Domain controllers replicate data by pulling in any changes that occur on other domain

controllers. Inbound replication is single threaded. A domain controller can pull updates from only

one replication partner at a time. When a domain controller has a large number of replication

partners, replication can become a bottleneck.

Because no user-initiated changes are written directly to an RODC—and therefore no changes

originate from RODCs—other domain controllers do not have to pull changes from RODCs.

Therefore, the other domain controllers can ignore RODCs when they replicate changes. By

replacing writable domain controllers in remote locations with RODCs, you can simplify the

replication topology of your environment and reduce the load on domain controllers in central

locations that are replication partners for a large number of other domain controllers in remote

locations. Monitoring and managing replication is also simpler because there are fewer replication

connections.

Restricting RODCs from originating changes also prevents any changes or corruption that a

malicious user or application might make on an RODC from replicating to the rest of the forest, as

described in the following examples:

A malicious user obtaining physical access to an RODC in a branch office in which there is

only limited security and attempts to perform modifications locally on the database

Memory corruption of the database as a result of hardware failure

Accidental deletion of the SYSVOL folder by an administrator in the branch office

When a user or application in a site that is serviced by an RODC attempts to perform a write

operation, one of the following actions can occur:

The RODC forwards the write request to a writable domain controller and then replicates the

change back from the writable domain controller. For most write operations, the change is

replicated back to the RODC during the next scheduled replication interval. In some other

10

cases, the RODC attempts to replicate the change immediately. An RODC forwards a very

limited set of writes, including the following:

Most types of password changes. For more information about password changes, see

Password changes on an RODC.

Service principal name (SPN) updates. When a domain-joined machine has a secure

channel to an RODC and Netlogon attempts to update SPNs, the forwarding is done over

RPC.

Some updates to client attributes over Netlogon: client name, DnsHostName,

OsVersionInfo, OsName, Supported Encryption Types

LastLogonTimeStamp. When a domain-joined computer has a secure channel to an

RODC and Netlogon attempts to update these attributes, the forwarding is done over

LDAP.

The RODC sends a referral for a writable domain controller to the client. The application from

which the write operation originated can then chase the referral and target a writable domain

controller to perform the write operation. By default, RODCs send referrals for Lightweight

Directory Access Protocol (LDAP) updates and Domain Name System (DNS) record updates.

Note

During forwarding (or “chaining”), the RODC sends the write request to a writable

domain controller and returns the result back to the client upon completion of the

write request. Referrals are a hint that the client can chase. For example, in the case

of an LDAP application, if chase referrals is enabled on the LDAP connection

between the client and the RODC, the application never knows that the client

received a referral from the RODC. The client is automatically redirected to the

writable domain controller that is specified in the referral.

The write operation fails: it is neither referred nor forwarded to a writable domain controller. In

this case, the application requesting the write should be updated to specifically target a

writable domain controller. A number of RPC writes fall under this category.

For a small set of operations, an RODC attempts to inbound-replicate an individual change,

where only the modified object is replicated by using a replicate-single-object (RSO) operation

that is initiated by the RODC without waiting for the replication schedule. These operations are

limited to the following:

Some types of password changes.

For more information about RSO operations for password changes, see Password changes

on an RODC.

DNS updates in which a client attempts to make a DNS update and is then referred to DNS

server where the updates are registered and the RODC attempts to pull those changes back

in by performing an RSO operation. This operation occurs only for Active Directory-integrated

DNS zones.

By default, this replication of DNS updates occurs within a timeframe anywhere from

30 seconds up to 210 seconds after the update is registered.

11

For more information about RSO operations for DNS updates, see DNS updates for clients

that are located in an RODC site.

Updates for the previously listed client attributes: client name, DnsHostName,

OsVersionInfo, OsName, Supported Encryption TypesLastLogonTimeStamp.

The following sections explain in more detail how some of these processes work.

Read-only SYSVOLThe SYSVOL share on an RODC is read only. For both the File Replication Service (FRS) and

Distribute File System (DFS) Replication, updates to the SYSVOL share on an RODC must be

performed on a writable domain controller and then replicated to the RODC. However, there are

differences in how FRS and DFS Replication handle updates to SYSVOL on an RODC. FRS is

used to replicate SYSVOL at the Windows 2000 and Windows Sever 2003 domain functional

levels. At the Windows Server 2008 domain functional level, you can use DFS Replication to

replicate SYSVOL, instead of FRS.

If you are using FRS to replicate SYSVOL, it is possible for SYSVOL contents on an RODC to

become out of sync with other domain controllers. For example:

If a delegated RODC administrator deletes a file or directory in the SYSVOL folder on the

RODC:

The change is not replicated from the RODC to other domain controllers, but the contents

of the SYSVOL folder on the RODC are now different from the contents of the same

folder on other domain controllers. This change can affect any computer that obtains

Group Policy objects or logon scripts from that RODC, not only computers that are

defined in the PRP. In this case, the affected computers might not obtain intended Group

Policy objects or logon scripts.

To synchronize the contents of the SYSVOL folder again, you can make a change on a

writable domain controller to force the directory or file to replicate to the RODC, or you

can set the Burflags registry setting to D2. For more information about setting the

Burflags registry setting, see How to rebuild the SYSVOL tree and its content in a

domain (http://go.microsoft.com/fwlink/?LinkID=70802).

If a delegated RODC administrator adds a file or directory in the SYSVOL folder on the

RODC:

The change is not replicated from the RODC to other domain controllers. However, the

contents of the SYSVOL folder on the RODC are now different from the contents of the

same folder on other domain controllers. This change can affect any computer that

obtains Group Policy objects or logon scripts from that RODC, not only computers that

are defined in the PRP. In this case, the affected computers might obtain unintended

Group Policy objects or logon scripts.

To synchronize the contents of the SYSVOL folder again, you have to manually delete the

file or directory on the RODC or completely rebuild the SYSVOL tree. For more

12


information, see How to rebuild the SYSVOL tree and its content in a domain

(http://go.microsoft.com/fwlink/?LinkID=70802).

However, if you are using DFS Replication for SYSVOL, the DFS Replication service reverses all

changes that have been made locally. Any changes that you try to make to the contents of the

SYSVOL share on an RODC are not blocked. However, the DFS Replication service takes steps

to revert those changes. The changes will not be replicated out to other domain controllers.

Note

No event is logged when the DFS Replication services reverts the changes.

This behavior is by design because FRS provides limited support for read-only SYSVOL on an

RODC. We recommend that you use DFS Replication for SYSVOL as soon as possible because

it provides better support for read-only SYSVOL on an RODC.

For more information about how DFS Replication reverts any changes to SYSVOL on an RODC,

see How does DFSR function on Read Only Domain Controllers?

(http://go.microsoft.com/fwlink/?LinkId=119624).

System attributes that are written on an RODCThere is a set of attributes that an RODC maintains directly as part of logon policies and

bookkeeping. The following table lists the attributes that an RODC maintains for successful and

failed logon attempts.

Successful logon Failed logon

LastLogon, LogonCount, BadPwdCount are

written.

If the authentication has succeeded only after a

retry on the PDC emulator, the RODC

determines that the password is no longer valid.

The RODC nulls the password for the account

(that is, the link between the password attribute

value and its memory address is removed; the

password itself is unchanged and remains

stored in memory). This operation affects a set

of attributes, including unicodePwd.

The Last interactive logon statistics are also

written if it is enabled. (It is not enabled, by

default.)

Site affinity is updated if the RODC is in a site

that is enabled for universal and global group

membership caching.

LastLogonTimeStamp is written locally on the

BadPwdTime and BadPwdCount are written.

The Last (failed) interactive logon statistics

are also written if it is enabled. (It is not

enabled, by default.)

Site affinity is updated if the RODC is in a site

that is enabled for universal and global group

membership caching and a global catalog

server could not be contacted.

13



RODC, and a best effort is made to forward this

write to the writable replication partner.

Another attribute that is updated locally on the RODC is the ms-DS-Site-Affinity attribute. This

attribute is present on user objects if they log on with a domain controller in a site that has

universal group membership caching enabled. It is used by a periodic background refresh task on

the domain controller to determine whether the cache for this user should be refreshed.

Connection objects for the RODC are also written locally under the NTDS Settings object for the

RODC. They are written identically as they are written on any other domain controller. However,

they do not replicate to other domain controllers. The Knowledge Consistency Checker (KCC)

generates the replication topology for the forest. When the KCC runs on an RODC, it writes

connection objects locally. These connections objects are subsequently writable on the RODC,

and an administrator can modify or delete them.

The LastLogonTimeStamp attribute is handled in a particular way. This attribute was introduced

in Windows Server 2003 as a way to detect stale accounts from a central place, without having to

poll all domain controllers in the domain for the LastLogon attribute. For more information, see

Dandelions, VCR Clocks, and Last Logon Times: These are a Few of Our Least Favorite Things


When a user authenticates with a writable domain controller, the domain controller updates the

LastLogonTimeStamp attribute locally, and that value replicates to other domain controllers.

However, updates that are written locally on RODCs do not replicate to other domain controllers.

Instead, if the user is cached on the RODC and its LastLogonTimeStamp attribute needs to be

updated, the RODC writes locally the new value for this attribute, and the RODC attempts to

forward this write operation to a writable domain controller. At the next replication cycle, because

the attribute update on the writable domain controller happened at a later time, its value

overwrites the value that was written locally on the RODC.

RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC

This topic explains what the read-only domain controller (RODC) Filtered Attributes Set (FAS) is

and how credential caching and the authentication process work for an RODC.

RODC FASRODCs contain a complete copy of the Active Directory database in the sense that they contain a

read-only copy of all partitions that are held by an equivalent writable domain controller. For

example, an RODC contains read-only copies of the schema and configuration partitions. If you

14


are using Active Directory–integrated Domain Name System (DNS), an RODC that is a DNS

server contains read-only copies of the DNS application directory partitions.

However, there is a set of attributes that, by default, are not replicated to an RODC:

Attributes that belong to the RODC FAS

Credentials, except for the RODC's own computer account credentials and a special krbtgt

account for the RODC

The RODC FAS is a dynamic set of attributes that is not replicated to any RODCs in the forest.

These attributes are not replicated to RODCs because they contain sensitive data. Because they

are not replicated to RODCs, a malicious user who has managed to compromise an RODC

cannot expose them.

The default RODC FAS contains the following list of attributes:

ms-PKI-DPAPIMasterKeys

ms-PKI-AccountCredentials

ms-PKI-RoamingTimeStamp

ms-FVE-KeyPackage

ms-FVE-RecoveryGuid

ms-FVE-RecoveryInformation

ms-FVE-RecoveryPassword

ms-FVE-VolumeGuid

ms-TPM-OwnerInformation

These attributes are defined in the RODC FAS and marked as confidential to support Credential

Roaming and BitLocker Drive Encryption.

Some other applications that use Active Directory Domain Services (AD DS) as a data store may

also have credential-like data (such as passwords, credentials, or encryption keys) that you do

not want to be stored on an RODC in case the RODC is stolen or compromised.

For applications with this type of data, you can take these precautions:

Extend the RODC FAS to include any credential-like attributes that you want to prevent from

replicating to any RODC in the forest.

Mark the attributes as confidential, which removes the ability to read the data for members of

the Authenticated Users group, which includes RODCs. This step is necessary so that if an

RODC gets compromised, an attacker cannot—using the RODC account—read the data

directly from the directory. This acts as an additional measure of protection by preventing an

attacker from using a compromised RODC to read the attributes from the directory, even if

they are not replicated to the RODC.

Note

In general, if an authenticated user requests READ_PROPERTY permissions for an

attribute or for its property set, read access is granted. Default security in AD DS is

set so that authenticated users have read access to all attributes.

15

When the attributes are prevented from replicating to RODCs, they cannot be exposed

unnecessarily if an RODC is stolen or compromised.

A malicious user who compromises an RODC can attempt to replicate attributes that are defined

in the RODC FAS. If the RODC tries to replicate those attributes from a domain controller that is

running Windows Server 2008, the replication request is denied. However, if the RODC tries to

replicate those attributes from a domain controller that is running Windows Server 2003, the

replication request could succeed. Therefore, as a security precaution, you should ensure that the

forest functional level is Windows Server 2008 if you plan to configure the RODC FAS. When the

forest functional level is Windows Server 2008, an RODC that is compromised cannot be

exploited in this manner because domain controllers that are running Windows Server 2003 are

not allowed in the forest.

If an RODC is stolen, any attributes that were configured to be part of the RODC FAS will not be

present on the RODC. Therefore, RODC FAS data cannot be read on a stolen RODC whether

the forest functional level is Windows Server 2003 or Windows Server 2008. Other data that

resides on the stolen RODC can be read, but the RODC FAS data will not be read because it will

not be present.

We recommend that you also mark as confidential any attributes that you configure as part of the

RODC FAS. Marking the attribute as confidential provides an additional safeguard against an

RODC that is compromised by removing the permissions that are necessary to read the

credential-like data.

For procedures that show how to add an attribute to the RODC FAS, see RODC Administration.

Credential cachingAs mentioned earlier, by default an RODC does not store user credentials or computer

credentials, except for its own computer account and a special krbtgt account for that RODC. For

more information about the attributes that are part of a user or computer account credentials, see

User and Computer Credentials.

When users or computers in a site that is serviced by an RODC attempt to authenticate to the

domain, the RODC by default cannot validate their credentials. The RODC then forwards the

authentication request to a writable domain controller. However, there might be a set of security

principals that may need to be able to authenticate in a site that is serviced by an RODC, even in

cases where they have no connectivity to writable domain controllers.

For example, you might have a set of users and computers in a branch office that you want to be

authenticated even if there is no connectivity between the branch office and sites that contain

writable domain controllers. To resolve this issue, you can configure the PRP for that RODC to

allow the passwords for those users to be cached on the RODC. If the account passwords are

cached on the RODC, the RODC can authenticate those accounts when connectivity to writable

domain controllers is not available.

The PRP acts as an access control list (ACL). It determines whether an RODC is permitted to

cache credentials for an account. After the RODC receives a user or computer logon request, it

attempts to replicate the credentials for that account from a writable Windows Server 2008

16

domain controller. The writable Windows Server 2008 domain controller refers to the PRP to

determine if the credentials for the account should be cached. If the PRP allows the account to be

cached, the writable Windows Server 2008 domain controller replicates the credentials for that

account to the RODC and the RODC caches them. During subsequent logons for that account,

the RODC can authenticate the account by referring to the credentials that it has cached. The

RODC does not have to contact the writable domain controller.

Note

The credentials are not actually stored in a cache, as in the traditional sense of a storage

buffer. Instead, the credentials are stored directly in the Active Directory database. Also

note that while there are approximately five attributes that comprise the credentials for

each account, there can be any number accounts defined in the PRP.

A default PRP is defined that applies to any newly installed RODC. The default PRP specifies that

no account passwords can be cached on any RODC, and certain accounts are explicitly denied

from being cached on any RODC.

The PRP is defined by two multivalued Active Directory attributes that contain security principals

(users, computers, and groups). Each RODC computer account has these two attributes:

msDS-Reveal-OnDemandGroup, also known as the Allowed List

msDS-NeverRevealGroup, also known as the Denied List

To help manage the PRP, two other attributes that are related to the PRP are maintained for each

RODC:

msDS-RevealedList, also known as the Revealed List

msDS-AuthenticatedToAccountList, also known as the Authenticated to List

The msDS-Reveal-OnDemandGroup attribute specifies what security principals can have

passwords cached on an RODC. By default, this attribute has one value, which is the Allowed

RODC Password Replication Group. Because this domain local group has no members by

default, no account passwords can be cached on any RODC by default.

The list of user and computer accounts whose credentials are permitted to be cached does not

imply that the RODC has necessarily cached the passwords for those accounts. These accounts

are considered “cacheable,” and if an administrator takes no further action other than setting the

PRP, these users will have their passwords cached only after they log on against the RODC for

the first time. However, an administrator can also have an RODC cache any accounts in advance

of any authentication request. This way, the RODC can authenticate those accounts, even if the

wide area network (WAN) link to the hub site is offline. You can cache passwords in advance by

using the Active Directory Users and Computers snap-in or by using the repadmin /rodcpwdrepl

command. For more information, see Administering the Password Replication Policy.

You must include the appropriate user, computer, and service accounts in the PRP so that the

RODC can resolve authentication and service ticket requests locally (for the site). When only

users (but not computers or service accounts) from the site are specified on the Allow list, the

RODC is not able to resolve requests for service tickets locally, and it relies on access to a

writable Windows Server 2008 domain controller to resolve the requests. Also, the RODC is not

17

able to authenticate the computer account if the password for the account is not cached. In the

WAN offline scenario, this is likely to lead to a service outage.

Note

RODCs have a feature known as Administrator Role Separation, which you can use to

delegate to any domain user the credentials to be an administrator of an RODC, without

granting that user any other privileges in the domain. However, the password for the

delegated administrator is not cached by default. As a best practice, cache the password

of the delegated RODC administrator and refresh the cache after each time that the

password changes. For more information about the delegated administrator, see

Administrator Role Separation.

The msDS-NeverRevealGroup attribute specifies what security principals are explicitly denied

from having their passwords cached on an RODC. This is useful to help prevent credentials for

highly privileged accounts from replicating to an RODC. That way, you can be assured that an

attacker cannot obtain credentials for highly privileged accounts from a stolen or compromised

RODC. This attribute has the following default values:

Account Operators

Server Operators

Backup Operators

Administrators

The Denied RODC Password Replication Group, which is a domain local group that includes

the following:

Enterprise Domain Controllers

Enterprise Read-Only Domain Controllers

Group Policy Creator Owners

Domain Admins

Cert Publishers

Enterprise Admins

Schema Admins

Domain-wide krbtgt account

The msDS-NeverRevealGroup attribute takes precedence over the msDS-Reveal-

OnDemandGroup attribute. Therefore, if an account is either directly or indirectly included in

both the Allowed List and the Denied List, the account password cannot be cached on the RODC.

The msDS-RevealedList is the list of security principals (including computer accounts) whose

current credentials have been replicated to the RODC.

Note

The msDS-RevealedUsers attribute is another attribute that is related to credential

caching. The msDS-RevealedUsers attribute is used by the system to store information

about the secrets of any security principal, including computers, which has ever had its

18

secrets replicated to the RODC at any point in time. It contains separate entries for each

secret of each security principal (when a security principal is said to be cached on the

RODC, it means that five secrets are replicated to the RODC). The msDS-RevealedList,

on the other hand, is a list of currently revealed secrets and their associated users or

computers that administrators use to manage the Password replication policy. Unlike

msDS-RevealedUsers, msDS-RevealedList contains only one entry for each user or

computer.

The msDS-AuthenticatedToAccountList is the list of security principals that have been

authenticated by the RODC. This list includes accounts whose passwords have not been cached

by the RODC and all accounts whose passwords have been cached. This list provides

administrators with information about which accounts are using an RODC for authentication

requests and therefore might be good candidates to add to the msDS-Reveal-OnDemandGroup

attribute (the Allowed List).

Notes

The msDS-AuthenticatedToAccountList contains all accounts that have been granted

a service ticket to the RODC. This means that any user who accesses a resource on the

RODC will be added to this list. You should not use this list as a conclusive reference to

decide which accounts to add to the Allowed List. Instead, carefully review the list and

use it only to help you understand which accounts might be candidates to add to the

Allowed List.

It is possible to have users in the msDS-RevealedList that are not in the msDS-

AuthenticatedToAccountList. Accounts whose passwords are prepopulated on the

RODC are not going to appear in the msDS-AuthenticatedToAccountList, but they will

be in the msDS-RevealedList. This could also happen if you clear the msDS-

AuthenticatedToAccountList by using repadmin /prp. For more information about

prepoulating passwords, see Prepopulating the password cache for an RODC. For more

information about clearing the msDS-AuthenticatedToAccountList, see Clearing the

authenticated accounts list.

Key points for authentication through an RODCThis section covers some of the important points about how authentication works with an RODC.

For a step-by-step description of how authentication occurs with an RODC, see How the

authentication process works on an RODC.

If only user accounts are cached on an RODC in a particular site, users will not be able to log on

using computers in that site when the RODC is unable to contact a writeable domain controller

running Windows Server 2008.

All credentials for user, computer, and service accounts that should be cached must be

specifically allowed by the PRP. For the RODC to locally authenticate the credentials of any

account, those credentials must already be cached on the RODC.

19

Regardless of the PRP, the RODC attempts to cache accounts that are successfully

authenticated. The PRP is enforced by the writeable domain controller running Windows

Server 2008, which either allows or denies the caching of account credentials on the RODC.

RODCs are advertised as KDCs for the sites in which they are configured. RODCs use different

krbtgt accounts than the KDCs on writable domain controllers for encrypting or signing TGTs. This

provides cryptographic isolation between KDCs running on RODCs in different sites; a

compromised RODC is therefore prevented from issuing service tickets to resources in other

sites. Writable domain controllers contain credentials for all accounts, including the credentials of

the krbtgt accounts of the RODCs.

By limiting the caching of credentials on RODCs, the exposure of domain accounts is limited in

the event that an RODC is compromised. In the event that an RODC is stolen or otherwise

compromised, the accounts that were cached on that RODC are the only accounts that can be

potentially compromised.

Administrator Role Separation

This topic explains how you can use Administrator Role Separation (ARS) on a read-only domain

controller (RODC) to delegate RODC administration to a user who is not a member of the Domain

Admins group.

One problem encountered by administrators of domain controllers in perimeter networks is that

domain controllers typically have to be set up and administered by domain administrators.

Administrative operations, such as applying software updates, performing an offline

defragmentation, or backing up the system, cannot be delegated.

With the introduction of RODCs, domain administrators can delegate both the installation and the

administration of RODCs to any domain user, without granting them any additional rights in the

domain. The ability to perform this delegation is called ARS.

You can use ARS for two different purposes:

RODC installation. You can promote an RODC in two stages:

a. A domain administrator creates an account in the domain for the computer that is going to

be promoted as an RODC. During this process, the domain administrator can specify the

Password Replication Policy (PRP) for this RODC and the security principal (user or

group) that, using this account, will have the right to promote and subsequently

administer the RODC.

b. In the site where the RODC is going to be located, the delegated administrator that the

domain administrator specifies during the first stage can attach the computer that is going

to be the RODC to the precreated RODC account.

RODC maintenance. The delegated administrator for the RODC can log on to it to perform

maintenance work, such as upgrading a driver or an application, installing other server roles,

performing offline defragmentation of the disks, and so on. But the delegated administrator

cannot log on to any other domain controller—including other RODCs—or perform any other

20

administrative task in the domain. In this way, a member of the Domain Admins group can

delegate the ability to effectively manage the RODC without compromising the security of the

rest of the domain.

Differences Between an RODC and a Writable Domain Controller

As an additional domain controller for a domain, a read-only domain controller (RODC) performs

the same operations as a writable domain controller. For example, because an RODC contains a

copy of the directory database and a copy of the SYSVOL folder that contains the Group Policy

objects (GPOs) and logon scripts for client computers, it can respond to authentication requests

just as a writable domain controller does. However, there are a number of differences between an

RODC and a writable domain controller. The following table lists the important differences in the

characteristics of an RODC and a writable domain controller.

Characteristic RODC Writable domain controller

Active Directory database

access

The database on an RODC is

read only. Applications can only

read data from the directory

when they target an RODC;

they cannot write data in the

directory. However, RODCs

automatically forward certain

write operations to writable

domain controllers, and they

can send referrals to writable

domain controllers when

necessary.

All read and write operations

are possible on a writable

domain controller.

Data replication between

domain controllers

An RODC only replicates data

from a writable domain

controller, and it never

replicates data to another

domain controller in the

domain. This is true for both the

Active Directory data and the

SYSVOL data.

Writable domain controllers

replicate any changes that

occur elsewhere in the domain

from other writable domain

controllers, and they replicate

data that was written to their

database to other domain

controllers.

Data that is stored in the RODCs contain a complete Writable domain controllers

21

Characteristic RODC Writable domain controller

database copy of the database, with the

exception of credentials and

other credential-like attributes

that are part of the RODC

filtered attributes set (FAS).

However, you can select which

credentials can be cached on

the RODC to provide better

authentication performance for

users who are located in a site

that an RODC services.

contain a complete copy of the

directory database, including

credentials for all accounts.

Administration RODCs can be administered by

delegated users that do not

have any domain privileges

beyond standard domain users.

Administration operations

include applying hotfixes and

software updates, performing

offline defragmentation and

backups, and so on.

Only domain administrators

can manage writable domain

controllers.

Advantages That an RODC Can Provide to an Existing Deployment

This topic describes the fundamental changes that read-only domain controllers (RODCs) provide

and how these changes can affect your considerations for using RODCs in your environment.

SecurityThe following new features that are associated with RODCs can provide security benefits for your

deployment:

Unidirectional replication. Unidirectional replication refers to how RODCs can replicate

changes inbound but outbound replication does not occur. No other domain controllers

replicate changes from an RODC. Unidirectional replication helps to improve security by

restricting potentially malicious updates that can originate in a branch office. Because no

22

changes can replicate from an RODC, only the RODC in the branch office can be

compromised.

Special krbtgt account. Each RODC has a special krbtgt account that also helps to restrict

malicious updates from affecting the rest of the forest. The RODC can issue a ticket-granting

ticket (TGT) based on its krbtgt account to security principals whose passwords can be

cached locally. If a TGT that an RODC issues is used to request a service ticket from a

writable domain controller, the authorization data in the TGT is discarded and recalculated

before it is added to the TGT.

This means that the krbtgt account for an RODC is useful only in the local branch where the

RODC is deployed. Even if an RODC is compromised, a user cannot use a ticket that has

been maliciously created by a compromised RODC to access resources in a different site.

For example, suppose that a user in branch A tries to access a resource in branch B. If the

password for the resource is cached on the RODC in branch A and connectivity is available,

the Privileged Authentication Certificate (PAC) that the RODC in branch A creates can be

used to access the resource. However, if the password for the resource cannot be cached on

the RODC in branch A, the RODC in branch A will forward the request to a hub site domain

controller.

The hub site domain controller discards the PAC from the TGT, recalculates the PAC, and

then makes the connection. This way, a branch-signed krbtgt can be used at any writable

Windows Server 2008 domain controller in the forest for service tickets for any resource in

the forest, but an attacker cannot modify a PAC on an RODC and use that PAC to access

resources that cannot be cached by that RODC.

Password Replication Policy (PRP). Each RODC has a PRP that, by default, does not

allow any passwords to be cached on the RODC. This helps ensure that you can deploy

RODCs more securely, because, if the default configuration is unchanged, no account

passwords can be obtained from a compromised RODC.

RODC filtered attribute set (FAS). You can also restrict which application data can replicate

to RODCs in your forest by adding attributes to the RODC FAS and marking them as

confidential. When the attributes are prevented from replicating to RODCs and marked as

confidential, that data cannot be exposed on an RODC that is stolen or compromised.

ManageabilityThe following new features that are associated with RODCs can provide manageability benefits

for your deployment:

Branch office server administration. RODCs provide Administrator Role Separation (ARS),

which you can use to delegate administration of an RODC to a nonadministrative user or group.

This means that it is not necessary for a highly privileged administrator to log on to the domain

controller in the branch office to perform routine server maintenance.

23

Note

If a wide area network (WAN) link to a hub site is not available, the password for the

delegated RODC administrator must be cached on the RODC so that the delegated

administrator can log on to the RODC. As a best practice to enable RODC administration

when a WAN is not available, make sure that the PRP allows the delegated RODC

administrator account password to be cached, cache the password, and ensure that it is

cached again after every password change. For more information, see Administrator Role

Separation.

Domain administrators, on the other hand, can continue to remotely manage directory service

issues on the RODC as necessary. However, you should not use a domain administrator account

to log on to an RODC or to log on to a workstation that is serviced by an RODC. For more

information about logging on to manage RODCs, see Steps and best practices for setting up

ARS.

Branch office application administration. You might also deploy an RODC for special

requirements related to administering applications in a branch office. For example, it might be

necessary to run a line-of-business (LOB) application on a domain controller in the branch office.

To administer the application, the LOB application owner must log on to the domain controller

interactively or by using Terminal Services.

In this case, an RODC can provide a secure mechanism for granting nonadministrative domain

users the right to log on to the domain controller without jeopardizing the security of

Active Directory Domain Services (AD DS). Furthermore, any Active Directory data that is

tampered with locally cannot replicate from the RODC to other domain controllers.

Note

Many applications and operating system components use data that is stored in AD DS.

Typically, these applications perform read operations, and they are not affected by using

a read-only database. However, some applications must update information that is stored

in AD DS, and they might rely on the ability to write data to AD DS. These applications

might not function correctly if they perform write operations against an RODC. For more

information, see Planning for Application Compatibility with RODCs.

ScalabilityThe following new features that are associated with RODCs can provide scalability benefits for

your deployment:

Unidirectional replication. Writable domain controllers that are replication partners do not have

to pull changes from an RODC. This applies to both AD DS and Distributed File System (DFS)

Replication of SYSVOL. In larger branch office environments, inbound replication typically puts a

significant load on bridgehead servers in a hub site because it is serialized, which means that the

bridgehead server cannot process changes from all of its replication partners simultaneously.

RODCs that are deployed in the spoke sites can relieve the inbound replication load on

bridgehead servers in the hub site because they never replicate any changes.

24

This can help to reduce the number of domain controllers that you need to deploy in the hub site.

The total number of connection objects that have to be created is also reduced by about half,

because inbound connection objects do not have to be created on the hub domain controllers for

each branch domain controller. Consequently, you do not have to plan for as much configuration

of hub site Windows Server 2008 domain controllers as compared with Windows Server 2003

domain controllers.

This can also help to reduce the end-to-end synchronization time for an enterprise. Writable

domain controllers in the hub can be configured to replicate updates to a higher number of

RODCs concurrently. This can help to implement security changes, such as updates for fine-

grained password policies or updates to the RODC FAS, more rapidly.

DFS Replication versus FRS for SYSVOL replication. Windows Server 2008 contains both the

File Replication Service (FRS) and Distributed File System (DFS) Replication for replicating

SYSVOL. FRS enables interoperability with domain controllers that run Windows 2000 Server or

Windows Server 2003. DFS Replication is used to replicate SYSVOL if the domain functional

level is Windows Server 2008.

Due to some limitations with how SYSVOL can be restored when it is replicated by FRS in a

large-scale environment, the Windows Server 2003 Branch Office Guide recommended that you

not exceed 1,200 domain controllers in a domain. Existing branch office deployments might

include multiple domains because of this limitation. For example, if you had more than 1,200

branch offices and you wanted to place a domain controller in each branch, you may have

created multiple domains.

DFS Replication is a new state-based, multimaster replication engine that supports scheduling

and bandwidth throttling. It uses a new compression algorithm to replicate only the changes—not

the entire files—when files are updated. This helps DFS Replication to scale up to include a

larger number of domain controllers in a domain than can be used with FRS. However, if you

want to use DFS Replication, the domain functional level must be Windows Server 2008. You

have to continue using FRS to replicate SYSVOL until all domain controllers in the domain are

running Windows Server 2008. Plan for migrating from FRS to DFS Replication, and then perform

the migration. For more information about planning for the migration, see SYSVOL Migration

Series: Part 1 – Introduction to the SYSVOL migration process (http://go.microsoft.com/fwlink/?

LinkId=119296).

DC Locator improvements. Domain controller Locator (DC Locator) is a mechanism that clients

use to discover the closest domain controller. Windows Server 2008 includes a new Registry or

Group Policy setting that enables Windows Vista and Windows Server 2008 client computers to

attempt to locate the next closest domain controller if the closest domain controller is not

available. The Try Next Closest Site setting improves the performance of DC Locator by helping

to streamline network traffic, especially in large enterprises that have many branch offices and

sites. By default, DC Locator does not consider a site that has an RODC when it determines

which site is the next closest site. If necessary, you can modify the default behavior of the clients

(by modifying the NextClosestSiteFilter value) so that clients do consider a site that has an RODC

when they determine which site is the next closest site.

25



You can apply the Try Next Closest Site setting to Windows Vista and Windows Server 2008

client computers by using Group Policy or by editing the registry.

Prerequisites for Deploying an RODC

Complete the following prerequisites before you deploy a read-only domain controller (RODC):

Ensure that the forest functional level is Windows Server 2003 or higher, so that linked-

value replication (LVR) is available. This provides a higher level of replication consistency.

The domain functional level must be Windows Server 2003 or higher, so that Kerberos

constrained delegation is available. If the forest functional level is Windows Server 2003, the

domain functional level of all domains in the forest is Windows Server 2003 or higher.

Constrained delegation supports security calls that must be impersonated under the context

of the caller. Delegation makes it possible for applications and services to authenticate to a

remote resource on behalf of a user. Because it provides powerful capabilities, typically only

domain controllers are enabled for delegation. For RODCs, applications and services must be

able to delegate, but only constrained delegation is allowed because it prevents the target

from impersonating again and making another hop. The user or computer must be cacheable

at the RODC for constrained delegation to work. This restriction places limits on how a rogue

RODC may be able to abuse cached credentials.

Run Adprep.exe commands to prepare your existing forest and domains for domain

controllers that run Windows Server 2008. The adprep commands extend the

Active Directory schema and update security descriptors so that you can add Windows

Server 2008 domain controllers.

a. Prepare the forest and domains. There are three adprep commands to complete and

have the changes replicate throughout the forest. Run the three commands as follows:

Prepare the forest by running adprep /forestprep on the server that holds the schema master operations master (also known as flexible single master operations or FSMO) role to update the schema. For more information, see Prepare a Windows 2000 or Windows Server 2003 Forest Schema for a Domain Controller That Runs Windows Server 2008.

Prepare the domain by running adprep /domainprep /gpprep on the server that holds the infrastructure operations master role. For more information, see Prepare a Windows 2000 or Windows Server 2003 Domain for a Domain Controller That Runs Windows Server 2008.

If you are installing an RODC in an existing Windows Server 2003 domain, you must also run adprep /rodcprep. For more information, see Prepare a Forest for a Read-Only Domain Controller. For more information about how to resolve possible errors when you run adprep /rodcprep, see Adprep /rodcprep can have an error if the infrastructure master for an application directory partition is not available.

b. Install Active Directory Domain Services (AD DS). You can install AD DS by using a

wizard, the command line, or an answer file. For more information, see Installing an

26

Additional Windows Server 2008 Domain Controller (http://go.microsoft.com/fwlink/?

LinkID=93254).

Deploy at least one writable domain controller running Windows Server 2008 in the same

domain as the RODC. An RODC must replicate domain updates from a writable domain

controller running Windows Server 2008. For fault tolerance, you should deploy at least two

writable domain controllers running Windows Server 2008. An RODC can use the second

domain controller for failover if the first domain controller is not available.

Prepare a Windows 2000 or Windows Server 2003 Forest Schema for a Domain Controller That Runs Windows Server 2008

Before you can add a domain controller that is running Windows Server 2008 to an

Active Directory environment running Windows 2000 Server or Windows Server 2003, you must

update the Active Directory schema. You must update the schema from the domain controller that

hosts the schema operations master role. If you are performing an unattended installation of

AD DS with Windows Server 2008, you must update the schema before you install the operating

system. For normal installations, you must update the schema after you run Setup and before you

install AD DS.

After you prepare the forest, you need to prepare any domain where you plan to install a domain

controller that runs Windows Server 2008. For more information, see Prepare a Windows 2000 or

Windows Server 2003 Domain for a Domain Controller That Runs Windows Server 2008.

If you are creating a new Windows Server 2008 forest, you do not have to prepare the schema or

any of the domains in the forest.

Use the following procedure to update the Windows Server 2003 or Windows 2000 Server

Active Directory schema for Windows Server 2008.

Administrative credentials

To perform this procedure, you must use an account that has membership in all of the following

groups:

Enterprise Admins

Schema Admins

Domain Admins for the domain that contains the schema master

To prepare the forest schema for Windows Server 2008

1. Log on to the schema master as a member of the Enterprise Admins, Schema Admins,

and Domain Admins groups.

2. Insert the Windows Server 2008 DVD into the CD or DVD drive.

3. Click Start, right click Command prompt, and then click Run as administrator.

27



4. Type the following command, and then press ENTER:

D:\sources\adprep\adprep /forestprep

Where D: is the drive letter of your CD or DVD drive.

5. If you plan to install an RODC in any domain in the forest, type the following, and then

press ENTER:

D:\sources\adprep\adprep /rodcprep

6. Allow the operation to complete, and then allow the changes to replicate throughout the

forest before you prepare any domains for a domain controller that runs Windows

Server 2008.

Prepare a Windows 2000 or Windows Server 2003 Domain for a Domain Controller That Runs Windows Server 2008

Use the following procedure to prepare a Windows 2000 or Windows Server 2003 domain for

Windows Server 2008.


To perform this procedure, you must be a member of the Domain Admins group. Membership in

the Enterprise Admins group is not sufficient to perform this procedure.

To prepare a Windows 2000 or Windows Server 2003 domain for Windows Server 2008

1. Identify the domain infrastructure operations master role holder (also known as flexible

single master operations or FSMO) as follows:

In Active Directory Users and Computers, right-click the domain object, click

Operations Masters, and then click Infrastructure.

2. Log on to the infrastructure master as a member of the Domain Admins group.




D:\sources\adprep\adprep /domainprep /gpprep



forest before you install a domain controller that runs Windows Server 2008.

28

Prepare a Forest for a Read-Only Domain Controller

Before you can install a read-only domain controller (RODC) in a Windows Server 2003 forest or

a forest in which you have upgraded the domain controller to Windows Server 2008, you must

prepare the forest by running adprep /rodcprep. You can run adprep /rodcprep on any

computer in the forest. This operation runs remotely. It contacts the infrastructure master for each

domain and for each application directory partition to update the permissions. This includes the

infrastructure master for the two default Domain Name System (DNS) application directory

partitions (ForestDNSZones and DomainDNSZones) that are created in an Active Directory–

integrated DNS environment.

If you are attempting to run adprep /rodcprep in an isolated environment, the infrastructure

master for each domain and for each application directory partition must be available within the

environment for the operation to succeed. For more information, see article 949257 in the

Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=114419).

You need to run this command only once in the forest; however, you can rerun this command any

time if it fails to complete successfully because an infrastructure master is not available.

Use the following procedure to prepare a forest for an RODC.


To perform this procedure, you must be a member of the Enterprise Admins group.

To prepare a forest for an RODC

1. Log on to any computer in the forest as a member of the Enterprise Admins group.




D:\sources\adprep\adprep /rodcprep



forest before you try to install an RODC.

Known Issues for Deploying RODCs

This topic explains known issues for read-only domain controllers (RODCs). Many of the issues in

this topic are resolved if you apply the Windows Server 2008 read-only domain controller

compatibility pack for Windows Server 2003 clients and for Windows XP clients, which is a

cumulative hotfix that you can apply to client computers that interact with RODCs. To obtain the

29


RODC compatibility pack, see article 944043 in the Microsoft Knowledge Base

(http://go.microsoft.com/fwlink/?LinkId=120375). If you cannot apply the hotfix in a particular

situation, you can try an alternative workaround.

Note

Some of the known issues from preliminary releases of Windows Server 2008 are no

longer valid. For example, an RODC advertises as a time source without a Windows

Server 2008 domain controller having to be configured as GTIMESERV or having the

primary domain controller (PDC) emulator operations master role run on a

Windows Server 2008 domain controller. It can take from 10 to 15 minutes after an

RODC restarts after installation of Active Directory Domain Services (AD DS) before the

RODC begins to advertise as a time source.

Apply the RODC compatibility pack or plan a workaround for any known issueFor client computers that interact with an RODC, you can apply a cumulative hotfix that

addresses all the issues in the following table. The hotfix is available in article 944043 in the

Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=120375). However, you do not

necessarily have to apply the hotfix before you can deploy an RODC. In many cases, you might

find that an issue does not affect your deployment, or you might be able to implement a

workaround rather than apply the hotfix.

The following table explains each issue, the types of clients and the RODC deployment scenario

that are affected by the issue, the potential impact of the issue, and a workaround if you cannot

apply a hotfix to address the issue. Consider each issue with regard to the specific rules and

policies that your organization has for its network. For some networks, a suggested workaround

might not be acceptable.

In general, you do not have to apply updates to any other domain controllers to get them to work

with RODCs. The one exception is for domain controllers that run Windows Server 2003 and

perform automatic site coverage for sites with RODCs. When domain controllers perform

automatic site coverage, they register records in DNS in order to cover authentication requests in

other sites that do not have a domain controller. Because Windows Server 2003 domain

controllers do not recognize RODCs, they can perform automatic site coverage for sites that have

RODCs. In this case, you have to apply the hotfix to any Windows Server 2003 domain controller

that performs the automatic site coverage if you cannot implement one of the workarounds that is

suggested in the table.

If an issue is about an RODC deployment scenario that does not pertain to your environment, you

can disregard it. For example, the issue about domain join failures that target an RODC only

affects scenarios in which a firewall is configured tightly between the RODC site and the site that

contains the writable domain controller. If you are not deploying an RODC in a similar

configuration, you can disregard that issue.

30



If you do face one of the following issues and you cannot implement the workaround, you must

apply the hotfix.

Issue Affects … Impact Workaround

Group Policy fails

to access Windows

Management

Instrumentation

(WMI) filters on an

RODC.

Client

computers

in the

RODC site

If an RODC is available but a writable

domain controller is not available,

Group Policy fails to access any WMI

filters and does not apply any Group

Policy object (GPO) to which the WMI

filters are linked. Failure to access WMI

filters may prevent affected clients from

applying intended Group Policy or cause

those clients to improperly apply Group

Policy that an administrator might have

intended the WMI filter to exclude.

There is no

workaround for this

issue.

Internet Protocol

security (IPsec)

policies fail to apply

from an RODC.

Client

computers

in the

RODC site

(branch

office

scenario)

Attempts by Windows Server 2003 and

Windows XP member computers to

apply IPsec policies from RODCs fail

with Win32 error 8219

(ERROR_POLICY_OBJECT_NOT_FO

UND). The same member computers

can successfully apply policy from

writable domain controllers. You may

encounter this scenario when network

connectivity for IPsec clients has been

limited to Active Directory sites that

contain RODCs but no writable domain

controllers.

There is no

workaround for this

issue.

The Windows Time

service (W32time)

in Windows XP and

Windows Server 20

03 does not

recognize an

RODC.

Client

computers

in the

RODC site

(branch

office and

perimeter

network

(also

known as

DMZ)

scenarios)

The affected client computers will not

synchronize time with the RODC during

authentication. When the time service

gets out of sync, users can receive

errors when they attempt to access

resources on the network.

You can configure

the client computers

to synchronize time

from another

domain controller

on the network if

one is available.

Unsecure domain Client In a perimeter network scenario where There is no

31


join fails computers

in the

RODC site

(perimeter

network

scenario)

an RODC is available but a writable


unsecure domain joins will fail.

Unsecure domain joins are performed

by Active Directory Migration Tool

(ADMT) and Windows Deployments

Service (WDS).

workaround for this

issue

Domain join using

RODC in the

perimeter network

fails.

Client

computers

in the

RODC site

(perimeter

network

scenario)

In a perimeter network scenario where



domain joins will fail even if the

computer account and password are

prepopulated on the RODC.

You can create

firewall rules to

allow a writable

domain controller to

be contacted for the

domain join

operation, or you

can bridge the

perimeter and

intranet networks.

However, most

firewall

administrators do

not allow these

options. In that

case, you must

apply the hotfix or

determine a more

suitable workaround

for your network.

Password changes

fail in the perimeter

network when only

an RODC is

available.

Client

computers

in the

RODC site

(perimeter

network

scenario)

In a perimeter network scenario in which



password changes that are initiated

from a computer that runs Windows XP,

Windows Server 2003, or

Windows 2000 will fail. This is true if the

user initiates the password change by

pressing Ctrl+Alt+Del or if an

administrator selects the option that the

user must change the password during

the next logon, for example, when the

administrator creates a new user

You can create

firewall rules that

allow a writable

domain controller to

be contacted for the

password change

request, you can

change the

password from

within the intranet,

or you can perform

the password

change from a client

32


account. computer that runs

Windows Vista or

Windows Server 20

08.

The RODC fails to

retrieve or create a

public key

certificate.

Client

computers

in the

RODC site

(branch

office and

perimeter

network

scenarios)

The Data Protection Application

Programming Interface (DPAPI) on

client computers that only have access

to an RODC cannot decrypt master keys

unless they have previously contacted a

writable domain controller and retrieved

a public key certificate. Clients that only

have access to an RODC cannot

decrypt master keys.

Without this fix, even if a writable

controller is available, DPAPI on clients

may fail to decrypt master keys if the

closest domain controller is an RODC.

When DPAPI

attempts to decrypt

master keys, ensure

that the client has

access only to a

writable domain

controller. DPAPI

attempts to decrypt

master keys during

password changes.

Spooler does not

reflect the correct

printer publish

state.

Client

computers

in the

RODC site

(branch

office

scenario)

If an RODC services a client request to

publish a printer, it forwards the request

to a writable domain controller. The

spooler attempts to read from the RODC

immediately after the write. The

information has not yet been replicated

to the RODC, and spooler fails the

publish operation. All spooler internal

structures are updated, and the printer

is marked as unpublished.

There is no

workaround for this

issue.

The Find Printer

user interface (UI)

hangs when a

computer that runs

Windows XP or

Windows Server 20

03 can contact an

RODC but not a

writable domain

controller.

Client

computers

in the

RODC site

(branch

office

scenario)

Users will not be able to find printers

that are published in AD DS.

There is no

workaround for this

issue.

Active Directory

Service Interfaces

Client

computers

ADSI calls from Windows XP and

Windows Server 2003 client computers

Ensure that these

client computers

33


(ADSI) in

Windows XP and

Windows Server 20

03 requests a

remote writable

domain controller

instead of a local

RODC.

in the

RODC site

(branch

office

scenario)

are directed to a writable domain

controller even if an RODC is in the

same site as the client. This can cause

unnecessary wide area network (WAN)

traffic to a writable domain controller in a

remote site.

have connectivity to

a writable domain

controller when they

make ADSI calls,

even for read-only

operations. ADSI

calls to the writable

domain controller

will create additional

WAN traffic.

Domain controllers

running

Windows Server 20

03 perform

automatic site

coverage for sites

with RODCs.

Windows

Server 20

03 domain

controllers

that

provide

automatic

site

coverage

for other

branch

office sites

(branch

office

scenario)

A domain controller running

Windows Server 2003 may register its

Domain Name System (DNS) service

(SRV) resource records for a site that

contains an RODC. Consequently, client

computers that attempt to discover a

domain controller in the RODC site can

also find the domain controller that is

running Windows Server 2003. As a

result, they might not authenticate with

the RODC as desired.

There are two

possible

workarounds for this

issue:

Ensure that

only domain

controllers

running

Windows Serve

r 2008 are

present in the

site that is

closest to the

RODC site.

Disable

automatic site

coverage on

domain

controllers

running

Windows Serve

r 2003.

Client operating system updatesUnless you are affected by one of the scenarios in the preceding table, RODCs do not require

any changes to make it possible for client computers to use an RODC. Client computers running

any of the following operating systems are supported for use with RODCs:

Windows 2000 Server

34

Windows 2000 Professional

Windows XP

Windows Server 2003

Windows Vista

Windows Server 2008

We recommend that you install the latest service pack on all client computers in RODC sites.

Group Policy tools can apply updates inadvertently to SYSVOL on an RODCIt is possible to write data inadvertently to the SYSVOL share on an RODC in the following

situations:

You use the Group Policy Management Console (GPMC) to edit Group Policy objects over

high-latency or transient network connections.

You have configured sites and subnets in AD DS incorrectly.

At startup, Group Policy management tools attempt to locate and connect to the domain controller

in the current domain that holds the PDC emulator operations master role. The Group Policy

setting Group Policy domain controller selection ensures that the initial connection only uses

the domain controller that is defined in the policy setting. The policy setting does not prevent you

from targeting another domain controller after you have loaded the Group Policy object in the

appropriate editor.

It may be that the newly targeted domain controller is an RODC, in which case the GPMC

attempts to modify the content of the SYSVOL folder on the RODC. If that happens, the changes

will be completely lost if Distributed File System Replication (DFS Replication) is used for

SYSVOL replication, or the SYSVOL content will be different between the RODC and the rest of

the domain if the File Replication Service (FRS) is used for SYSVOL replication.

If you are using FRS to replicate SYSVOL, the contents of the SYSVOL folder on the RODC will

remain different from the contents of the same folder on other domain controllers.

To synchronize the contents again, you can make a change on a writable domain controller to

force the directory or file to replicate to the RODC or set the Burflags registry setting to D2. For

more information about setting the Burflags registry setting, see article 315457 in the Microsoft

Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=119911). Note that in this case the

changes that you made while targeting the RODC will be lost.

However, if you are using DFS Replication for SYSVOL, any file or directory that you modify in

the SYSVOL share on an RODC reverts back to the original state.

This behavior is by design because FRS provides limited support for read-only SYSVOL on an

RODC. We recommend that you use DFS Replication for SYSVOL as soon as possible because

it provides better support for read-only SYSVOL on an RODC.

35


For more information about how DFS Replication reverts any changes to SYSVOL on an RODC,

see How Does DFSR Function on Read Only Domain Controllers?


Follow these guidelines when you edit Group Policy and you have RODCs in the domain:

Edit a GPO directly on the domain controller that you want to receive changes.

Note

This is not ideal for delegated environments.

Ensure that the computer from which you edit Group Policy is in the same site as the domain

controller that you want to receive changes.

Do not edit Group Policy over transient or high-latency connections. Use Remote Desktop or

Terminal Services and connect to a computer that is located in the same site as the domain

controller, and then edit or create Group Policy on that computer.

Do not leave Group Policy tools open for an extended period of time, most importantly, when

you are editing a domain-based GPO. Save changes as soon as possible.

Adprep /rodcprep will log an error if the infrastructure master for an application directory partition is not availableIf the domain controller that holds the infrastructure operations master (also known as flexible

single master operations or FSMO) role for an application directory partition is not available when

you run the adprep /rodcprep command to prepare a forest for an RODC, the command can

return an error. The error is logged in the Adprep.log file, and it indicates that Adprep failed an

operation on the application directory partition that is named in the error. By default, domain

controllers have application directory partitions for DNS.

The infrastructure operations master role holder for each application directory partition must be

online when you run adprep /rodcprep. If the role holder is not online, which could happen if the

domain controller that hosted the role was forcefully demoted without performing metadata

cleanup, then adprep /rodcprep can log the error.

Note

The infrastructure operations master role for an application directory partition is not the

same as the infrastructure operations master role for a domain partition.

For more information about fixing this issue, see article 949257 in the Microsoft Knowledge base


36



Applications can fail to register SPNs in a site with an RODCIf an RODC is present in a site, applications might fail to register their Service Principal Names

(SPNs).

To correct this problem, identify the service account of any application that has failed to register

its SPN, and cache that service account on all RODCs in the same site.

To identify which RODCs have currently cached the password of the service account, open the

Active Directory Users and Computers snap-in, right-click the service account object, click

Properties, and click the Password Replication tab.

To cache the password on a specific RODC, open Active Directory Users and Computers, click

Domain Controllers, right-click the RODC account object, click Properties, and then click the

Password Replication Policy tab. Click Advanced, and then click Prepopulate Passwords.

Repadmin /PRP might return only a subset of accountsIf you have a large number of accounts cached, such as thousands of accounts, you might see

that only a subset of the cached accounts are returned when you run the repadmin /prp view

<RODC> reveal command. When a server retrieves an attribute from AD DS that has many

entries, the server requests as many entries as AD DS can return at one time. If the initial request

returns only a partial list of the entries for the attribute, the server is supposed to trigger additional

requests for the remaining entries. When you run the repadmin /prp view <RODC> reveal

command, it does not make the additional requests for remaining entries.

RODC Placement Considerations

With respect to placement of a read-only domain controller (RODC) in a site, consider how the

RODC will replicate scheduled updates. An RODC can replicate updates of the domain partition

only from a writable domain controller running Windows Server 2008 in the same domain. The

RODC can replicate other partitions, including application directory partitions and global catalog

partitions, from any writable domain controller that runs either Windows Server 2003 or Windows

Server 2008. An RODC cannot be a source domain controller for any other domain controller

because it cannot perform outbound replication.

An RODC must replicate the domain partition from a writable domain controller running Windows

Server 2008 because only a writable domain controller that runs Windows Server 2008 can

enforce the Password Replication Policy (PRP) for an RODC.

To replicate the domain partition to the RODC, you typically place a writable domain controller

running Windows Server 2008 in the nearest site in your network topology to the site that

37

contains the RODC. The nearest site in this sense is defined as the site that has the lowest-cost

site link for the site that contains the RODC.

Note

As a best practice, do not place an RODC in the same site as a writable domain

controller. If an RODC is compromised, all other resources in that site are at risk,

including any writable domain controllers.

If you cannot place a writable Windows Server 2008 domain controller in the nearest site to the

RODC, RODC replication depends on a site link bridge between the site links that contain the site

of the RODC and the site of the writable Windows Server 2008 domain controller.

By default, a new Windows Server 2008 forest has the Bridge all site links option enabled,

which means that all site links are bridged. You can configure this setting in the properties of the

Inter-Site transport in the Active Directory Sites and Services snap-in.

For most existing branch office deployments that use Windows Server 2003 domain controllers,

however, the Bridge all site links option is disabled. If you are adding RODCs to an existing

deployment where Bridge all site links option is disabled, consider how RODC replication will

work if you cannot place a writable Windows Server 2008 domain controller in the nearest site.

The following sections in this topic explain how domain partition replication works in scenarios in

which the Bridge all site links option is either enabled or disabled. For more information about

how RODC placement affects other operations, see the following topics:

How Operations in a Branch Site with an RODC Are Affected When the WAN Is Not Available

Sites with Multiple Domain Controllers

Placing RODCs with site link bridgingIf the Bridge all site links option is enabled, as shown in the following illustration, a writable

domain controller running Windows Server 2008 can be placed in Site A rather than Site B. This

is because physical connectivity between Site A and Site C is available implicitly. If the site link

schedules overlap and the wide area network (WAN) links are available for a time that is sufficient

to complete replication, the RODC in Site C can replicate from the writable domain controller

running Windows Server 2008 in Site A.

38

Site topology where Bridge all site links is enabled

Placing RODCs without site link bridgingIn the following illustration, Sites A, B, and C have site links A–B and B–C and the Bridge all site

links option is disabled. In this example, there are Windows Server 2003 domain controllers in

Site A and Site B, and there is an RODC in Site C.

So that an RODC can be placed in Site C, a writable domain controller running Windows

Server 2008 for the same domain should be placed in Site B to replicate the domain partition to

the RODC. Otherwise, the RODC in Site C can replicate the schema, configuration, and

application directory partitions, but not the domain partition.

39

Site topology where Bridge all site links is disabled

In general, the introduction of an RODC should require minimal, if any, replication topology

changes. For example, consider a multitier replication topology in which:

The Bridge all site links option is disabled.

RODCs are placed in edge (or spoke) sites (Site C and Site D).

A writable domain controller running Windows Server 2008 is placed in a hub site (Site A).

A domain controller running Windows Server 2003 is placed in an intermediary site (Site B).

This topology is shown in the following figure.

40

Multitier replication topology with Windows Server 2003 domain controller in an intermediary site

In this scenario, you can do any of the following options to accommodate the need for direct

replication between the RODC and the writable domain controller running Windows Server 2008.

Create an additional site link between site A and site C and between site A and site D.

41

Create a new site link

Create a site link bridge that includes site link A-B, site link B-C, and site link B-D.

42

Create a site link bridge

Add a writable domain controller running Windows Server 2008 in the intermediary site (site

B).

43

Add a writeable Windows Server 2008 domain controller

How Operations in a Branch Site with an RODC Are Affected When the WAN Is Not Available

This topic describes common operations for client computers and applications against a read-only

domain controller (RODC) when the wide area network (WAN) is online as opposed to when the

WAN is offline.

Client operations

Application operations

44

Client operationsThe following table shows the results that occur for directory operations by a client computer in a

branch site that includes only an RODC, both when the WAN is online and when it is offline.

Operation WAN online WAN offline

Authentication If the account password is

not cached, the RODC

forwards the request to a

domain controller running

Windows Server 2008 in the

same domain. If the account

is cached, the RODC

satisfies the request locally.

Authentication fails if the account

password is not cached and the

user attempts to authenticate to

the RODC. Offline authentication

succeeds if the account password

is cached and if the RODC is a

global catalog server or the site

with the RODC has the universal

group membership caching

feature enabled.

Password change Either clients target a

writable domain controller

directly or the RODC

forwards the request to a

writable domain controller in

the same domain.

Password change fails. It is

important to change your

password while connectivity to a

writable domain controller is

available because if the password

expires while the WAN is offline,

although the RODC will prompt

the user to change the expired

password, the password change

request and logon will fail

because a writable domain

controller cannot be contacted.

Unlock a locked account An account that is locked out

on an RODC can be

unlocked manually from any

writable domain controller.

There is no way to manually

unlock an account that is locked

out by an RODC while the WAN

is offline. If the WAN remains

offline, the account can be

unlocked only after the account

lockout duration has elapsed.

Note

Unless the account

lockout policy is

configured with an infinite

lockout duration, the

account will automatically

45

Operation WAN online WAN offline

unlock after the duration

has elapsed and the

correct password is

presented for logon.

Application operationsWAN availability can affect some operations for applications. Perform specialized testing for the

applications that you plan to use in the site with an RODC to see how specific operations are

affected. You can use the guidelines in this section as a starting point and quick reference for

issues that you might encounter.

When the WAN link between the RODC and a writable domain controller is available, operations

succeed for most applications in the site with the RODC. However, some read operations that are

performed by Active Directory Service Interfaces (ADSI) operations, for example, might continue

to work but not take advantage of the RODC.

When the WAN is offline, Lightweight Directory Access Protocol (LDAP) read operations, which

are the most common type of LDAP operations, and authentication for accounts whose

passwords are cached succeed. However, other types of operations fail if the WAN is offline.

The following table lists the expected results for common operations that are performed by

applications running in a branch site with an RODC. You can use this table as a checklist to help

you anticipate possible issues with application operations. For operations that are marked as

inefficient, review the usage of the DsGetDcName function and update the application if needed.

For more details about potential issues that applications can encounter and possible resolutions

of those issues, see Planning for Application Compatibility with RODCs.

Key:

√ = operation succeeds

Ineff = operation succeeds but not efficiently

X = operation fails

Operation Operation condition WAN online WAN offline

Authentication Password cached √ √

Authentication Password not cached √ X

Password change √ X

LDAP read Application targets a

writable domain

controller

Ineff X

46

Operation Operation condition WAN online WAN offline

LDAP read Application does not

target a writable

domain controller

(default)

√ √

LDAP write Application targets a

writable domain

controller

√ X

LDAP write Application does not

target a writable

domain controller

(default) and can chase

a referral

√ X

LDAP write Application does not

target a writable

domain controller

(default) and cannot

chase a referral

X X

ADSI read Ineff X

ADSI write √ X

Planning for Application Compatibility with RODCs

Because most Active Directory–enabled applications are read intensive, they continue to work

regardless of whether the directory is writable. Therefore, these applications are not affected by

the introduction of read-only domain controllers (RODCs) into the environment. Infrastructure

applications and services, such as Domain Name System (DNS) and Dynamic Host Configuration

Protocol (DHCP), also typically work well with read-only directory data. For a list of applications

and services that are known to work with RODCs, see Applications That Are Known to Work with

RODCs (http://go.microsoft.com/fwlink/?LinkID=119953).

However, introducing RODCs into enterprise environments can affect some applications that

interact with Active Directory Domain Services (AD DS). Organizations that deploy RODCs can

test how their applications are affected in scenarios in which the applications may interact with an

47


RODC in the site rather than with a conventional, writable domain controller. Organizations can

also test their applications in scenarios in which connectivity between the RODC and the writable

domain controller may, or may not, be available.

The following illustrations depict these scenarios. The first scenario is a typical branch office

deployment in which the branch site has routine communication with the hub site. The second

scenario is a perimeter network (also known as DMZ and screened subnet) or an extranet

scenario where connectivity to a writable domain controller is restricted. You can refer to the

following illustrations as you review guidelines later in this document for testing your applications

and resolving problems that applications may have when they interact with RODCs.

Figure 1 A branch office scenario, where applications have access to a writable domain controller over a wide area network (WAN) link

Figure 2 An extranet or perimeter network scenario or a scenario where applications do not have access to a writable domain controller because of firewall rules or the WAN is offline

48

Directory-enabled applications

Directory-enabled applications that are built with Microsoft technologies primarily use the

following types of technologies:

Active Directory Service Interfaces (ADSI)

These applications use unmanaged ADSI providers and a managed

System.DirectoryServices namespace.

For more information about unmanaged ADSI providers, see ADSI Service Providers


For more information about the System.DirectoryServices namespace, see

System.DirectoryServices Namespace (http://go.microsoft.com/fwlink/?LinkId=100502).

Lightweight Directory Access Protocol (LDAP) application programming interfaces (APIs)

These applications use unmanaged WLDAP32 and a managed

System.DirectoryServices.Protocols namespace.

For more information about unmanaged WLDAP32, see Lightweight Directory Access

Protocol (http://go.microsoft.com/fwlink/?LinkId=99560).

For more information about the managed System.DirectoryServices.Protocols namespace,

see System.DirectoryServices.Protocols Namespace (http://go.microsoft.com/fwlink/?

LinkId=100504).

Directory-enabled applications use the DsGetDcName function of domain controller Locator

(DC Locator) to search for and connect to a domain controller for reading or writing data.

Note

Certain applications can also target a specific domain controller, for example, by its name

or IP address. If these applications continue to target a writable domain controller, they

are not affected by an RODC. As a best practice, however, make sure that your

applications use DC Locator.

In ADSI, the DsGetDcName function of DC Locator is called implicitly, a process that is known as

serverless binding. For an LDAP application, the application developer calls DsGetDcName

explicitly. Depending on the parameters that you set, DsGetDcName searches for a domain

controller that matches the criteria, such as a global catalog server or a domain controller that

holds the primary domain controller (PDC) emulator master operations (also known as flexible

single master operations or FSMO) role. The application then connects to that domain controller

to perform the desired operations.

For more information about DC Locator, see Directory Service Functions


For more information about DsGetDcName, see DsGetDcName Function


For more information about serverless binding, see Serverless Binding and RootDSE


49









Note

WAN availability can also affect client computer operations in other complex

deployments, such as scenarios in which an RODC is deployed in the same site as a

writable domain controller. For more information, see Appendix A: Technical Reference

Topics.

Impact of RODC on directory-enabled applications

Although ADSI and LDAP applications both use the same DsGetDcName function, by default

each type of application can connect to a different type of domain controller. In other words, an

ADSI application searches for, and connects to, a writable domain controller by default. In

contrast, by default an LDAP application searches for and connects to either a writable domain

controller or an RODC.

This default behavior can lead to the following problems for directory-enabled applications when

they interact with an RODC:

Problem 1: Inefficient or failed Read operations

Problem 2: Failed Write operations

Problem 3: Failed Write-Read-Back operations

Note

If an application runs under the LocalSystem security context on a domain controller, it

has reduced privileges when it runs on an RODC. This is because an application that

runs under the LocalSystem security context on a computer uses the credentials of that

computer's domain account. The domain account for an RODC has reduced privileges.

Problem 1: Inefficient or failed Read operations

An inefficient or failed Read operation occurs when an application does not target an RODC

because the RODC is read-only, regardless of whether it is the closest domain controller.

For example, assume that an application in Figure 1 only reads data from AD DS and that this

data is present on the RODC in the site to be read. If the application is configured to always

locate a writable domain controller for directory operations—as ADSI applications do by default—

the application reads data over the WAN link from the writable domain controller in the hub site. In

this case, the application disregards the RODC and does not use it for Read operations. This

results in inefficient Read operations when the WAN is online and failed Read operations when

the WAN is offline.

Important

Be sure to configure your applications that only read data from AD DS to use the closest

domain controller, regardless of whether that domain controller is a writable domain

controller or an RODC.

Although LDAP applications, by default, use the closest domain controller, ADSI applications, by

default, target only writable domain controllers. Therefore, you might have to resolve inefficient

50

Read operations for ADSI applications that can interact with RODCs that you deploy. For more

information, see Developer guidance for resolving compatibility problems between your

applications and an RODC (http://go.microsoft.com/fwlink/?LinkId=119960).

Problem 2: Failed Write operations

In an extranet or perimeter network scenario, Write operations fail. However, in a branch office

scenario, when an application contacts an RODC to attempt a Write operation, the RODC, by

default, returns a referral to a writable domain controller. The application must respond to the

referral and then use the information that it receives to locate a writable domain controller.

Although an ADSI application chases the referral automatically, a developer must configure an

LDAP application to chase the Write referral. This configuration is called an

LDAP_Write_Referral.

In a branch office scenario, if connectivity to a writable domain controller is not available, Write

operations fail regardless of whether the application uses LDAP or ADSI, and no additional

configuration helps.

Problem 3: Failed Write-Read-Back operations

A failed Write-Read-Back operation occurs when an application writes data to one domain

controller and then attempts to read the same data on a different domain controller. In this case,

the application does not read the updated data because that data has not yet replicated to the

domain controller that the application targeted for the Read operation. The introduction of RODCs

makes this problem more prominent because you might not be able to determine which writable

domain controller was returned in the referral.

For example, assume that an application that is shown in Figure 1 writes data to AD DS and then

reads back the same data. If this application expects the updated data to be available for a Write-

Read-Back operation, it should target the writable domain controller for both Write and Read

operations. If the application does not explicitly stick to the writable domain controller for both

Write and Read operations, it might read data that has not been updated from the RODC

because of the replication latency between the hub domain controller and the RODC.

If your applications write data to AD DS and then expect to read back the updated data, be sure

to explicitly locate a writable domain controller to write the data, and then stick to the same

domain controller to read back the same data.

Testing application compatibility for RODCsBefore you deploy an RODC in a branch office, perimeter network, or extranet, perform the

following steps to test all your directory-enabled applications in the site for compatibility with an

RODC.

Step 1: Set up the test environment

Set up your test environment according to the topology in the following figure.

51


Figure 3 A scenario for testing whether an application is compatible with an RODC

Perform the following steps to set up the test environment:

1. Install a writable domain controller that runs Windows Server 2008.

2. Install the DNS Server service on the domain controller.

For more information, see Installing a New Windows Server 2008 Forest by Using the

Windows Interface (http://go.microsoft.com/fwlink/?LinkId=100511). For this test, the domain

controller can remain in the Default-First-Site-Name site, where it is installed by default.

3. Use the Active Directory Sites and Services snap-in to create a new site.

For example, create a new site named Branch.

4. Add the Branch site to the DEFAULTIPSITELINK site link object.

DEFAULTIPSITELINK is the name of the first site link, which is created in AD DS by default.

You must add the Branch site to this site link to enable replication between the RODC and the

writable domain controller that you installed in step 1 of this procedure.

5. Install an RODC in the Branch site.

For more information, see Installing an Additional Windows Server 2008 Domain Controller


6. If necessary, configure rules for firewalls that exist between the sites.

7. Join client computers to the domain, and then move the client computer objects to the Branch

site, if necessary.

8. Install the applications in the Branch site.

Step 2: Categorize the applications

Determine how your applications interact with AD DS, and then categorize them based on how

your organization uses them and the types of operations that your applications perform. You can

use the categories in the following table as a reference.

Application type Description

Read application An application that only reads data from

AD DS. In this category, you might also include

an application that writes data to AD DS, if you

do not care whether Write operations fail. For

example, assume that you have an application

52



Application type Description

that performs Read operations for 99.9 percent

of its operations and Write operations for

0.1 percent of its operations. If you are not

concerned that a few Write operations will fail

when a writable domain controller is not

available, you might consider the application to

be a Read application.

Read-Write application An application that writes and reads data from

AD DS, where the Read operations are

independent of the Write operations. For this

application type, be sure that your application

performs independent Read and Write

operations. If Read operations depend on the

data written during Write operations, categorize

the application as a Write-Read-Back

application.

Write-Read-Back application An application that writes data to AD DS and

expects to read back the updated data.

Step 3: Test your application

Perform the following steps as needed to help you determine how to categorize and test your

applications:

1. Deploy the application on the application server.

2. Test the application using the test plan that you created for it.

The following table shows the results of tests that you can run to help you categorize your

applications by type.

53

Type of application Test Expected result

Read application Disconnect the writable

domain controller.

All directory operations

should pass.

Read-Write application Disconnect the writable

domain controller, and then

reconnect it.

When you disconnect the

writable domain controller,

the Read operations should

pass and the Write

operations should fail.

When you reconnect the

controller, all directory

operations should pass and

all Read operations should

be optimized. In other words,

the Read operations should

be targeted to the closest

domain controller, regardless

of whether it is writable or

read-only.

Write-Read-Back application Disconnect the writable

domain controller.

All directory operations

should fail.

Step 4: Fix broken or inefficient applications

Identify applications that do not provide the expected result because these applications will either

be broken or inefficient in an RODC environment. For information about fixing custom

applications, see Developer guidance for resolving compatibility problems between your

applications and an RODC (http://go.microsoft.com/fwlink/?LinkID=119960). For information

about fixing other applications, contact the independent software vendor (ISV) or developers for

those applications and provide them with details of the problem based on your tests. They can

use the same resolution steps that are described in this guide.

Sites with Multiple Domain Controllers

As a general best practice, you should not deploy other domain controllers in the same site as a

read-only domain controller (RODC). RODCs are designed to be placed in locations where the

physical security requirements for a writable domain controller cannot be met. If you place an

RODC in a site that has other domain controllers and the RODC is compromised in some way,

any other computers in that site may also be compromised.

54


However, it is technically possible to place RODCs in sites that have the following types of

domain controllers:

Domain controllers running Windows Server 2003 or Windows Server 2008 from the same

domain or a different domain

RODCs from the same domain or from a different domain

There are a number of constraints on operations by RODCs and on clients that communicate with

them when the RODCs are operating in a site with other domain controllers. There are also

considerations for operations when an RODC is placed in a site that has no other domain

controllers. These considerations pertain to operations when the wide area network (WAN) is

offline. The following sections explain what you can expect with regard to client operations in a

branch office that has another domain controller deployed with an RODC. The scenarios that are

described in this section are not generally recommended for most branch office deployments. But

organizations with more complex configurations might need to plan accordingly for situations

when there is WAN connectivity between the RODC and a writable domain controller.

Placing an RODC and a writable domain controller from the same domain in the same siteThis following table describes the results that you can expect for common client operations in a

branch office when the WAN is offline and an RODC is deployed in the branch office with a

writable domain controller. The results of the operations will vary depending on whether the

writable domain controller is running Windows Server 2003 or Windows Server 2008.

You should not typically deploy an RODC in the same site as a writable domain controller

because if the RODC is compromised, all resources in that site can also become compromised,

including the writable domain controller. However, you might choose to have a writable Windows

Server 2008 domain controller deployed in the same site as an RODC temporarily, for example,

while you are replacing the writable Windows Server 2008 domain controller with an RODC or for

some other special purpose.

Operation Expected result when a

Windows Server 2008 domain

controller is deployed in the site

with an RODC and the WAN is

offline

Expected result when a




offline

Authentication Offline authentication works for

all accounts, regardless of

which domain controller is

contacted. This is because the

RODC can forward

authentication requests for

account passwords that are not

Offline authentication works for

accounts whose passwords are

already cached, regardless of


contacted.

However, offline authentication

fails if the account is not cached

55

Operation Expected result when a




offline

Expected result when a




offline

cached to the writable Windows

Server 2008 domain controller.

and if the user authenticates to

RODC. This can result in

inconsistent and undesirable

behavior.

Lightweight Directory

Access Protocol (LDAP)

operations

LDAP read operations and write

operations work, regardless of


contacted.

LDAP read operations and write

operations work, regardless of


contacted.

Password changes Password changes succeed,

regardless of which domain

controller is contacted. This is

because the RODC can forward

authentication requests for

account passwords that are not

cached to the writable Windows

Server 2008 domain controller.

Password changes fail if the

RODC is contacted. This can

result in inconsistent and

undesirable behavior.

Placing multiple RODCs from the same domain in the same siteOne RODC is sufficient to service the authentication requests for even a large branch office that

includes many users and computers.

You should not deploy an RODC to provide redundancy for another RODC in the same site

because the RODCs cannot replicate information from each other. RODCs always ignore each

other for the purposes of authentication and replication. You can also encounter the following

problems if you deploy multiple RODCs in a site:

The Password Replication Policy (PRP) on each RODC is different. This can lead to an

inconsistent logon experience for users in the branch office when the WAN is offline, where

they can fail to log on if they authenticate with one RODC but succeed if they authenticate

with the other RODC in that site. To prevent logon failures, synchronize the PRP for each

RODC and then use a tool such as repadmin /rodcpwdrepl to synchronize the passwords

that are cached on each RODC after any of the passwords change.

Each RODC can become out of sync as a result of Replicate Single Object (RSO) operations

for dynamic Domain Name System (DNS) updates and password changes. When a DNS

56

client attempts a dynamic update of a DNS record or when a user attempts a password

change in a site with an RODC, the operation is performed on a writable domain controller in

a different site and then the RODC performs an RSO operation to replicate in the update

without waiting for the next scheduled replication cycle. The update is replicated to only the

RODC that forwarded the request, and any other RODC in the same site will remain out of

sync until the next scheduled replication cycle.

Placing an RODC and a domain controller (writable or read-only) from different domains in the same siteAs a best practice, you should have users and resources from only one domain in a site where

you deploy an RODC. If one domain is represented in the site, authentication in the site depends

on reaching only a domain controller for that domain. If more than one domain is represented in

the site, authentication can depend on reaching as many as four servers across WAN links.

The following illustration shows how authorization works across domains, when only RODCs from

these domains are available in the site. The behavior occurs because RODCs do not store trust

passwords, for security reasons. Trust passwords are generated by an administrator when the

administrator creates a trust. They are privileged, and storing them on RODCs constitutes a

potential security threat if the RODC is compromised.

57

How authorization with RODCs works across domains

The branch site contains an RODC for domain A and for domain B. A user from domain A (cached

on RODC1), whose computer account is also in domain A (cached on RODC1), attempts to

access a resource on server 1 in domain B (cached on RODC2). The following sequence occurs:

1. Using the ticket-granting service (TGS) issued by RODC1, the client computer presents a

service ticket request for Server1 to a local domain controller for its domain—in this case,

RODC1.

2. By reading files in the TGS, the RODC determines that the requested resource is in a

different domain. To proceed, the Key Distribution Center (KDC) on the RODC must be able

to provide the client computer with a referral ticket, which would allow the client computer to

access a KDC in the next domain in the trust path. However, the RODC does not have the

trust password. Therefore, it has to forward the request to a writable domain controller in the

same domain (domain A).

3. The writable domain controller (Hub1) returns the referral ticket to the RODC (RODC1).

58

4. RODC1 returns the referral ticket-granting ticket (TGT) to the client computer (computer1).

5. The client computer uses the referral TGT to contact a local domain controller in the target

domain (domain B) to request a TGS for the resource.

6. The domain controller, which again is an RODC (RODC2), cannot decrypt the request

because it does not have the trust password. Therefore, the RODC refers the request to a

writable domain controller in the same domain (Hub2).

7. The writable domain controller validates the request, issues the service ticket, and returns it

to the RODC (RODC2).

8. The RODC returns the TGS to the client (computer1).

The client computer can then present the service ticket to the resource.

The RODCs in this scenario must contact writable domain controllers because they do not have

the trust password. This means that any new cross-domain authentication requests will not work

if the WAN is offline.

RODC Installation

This topic describes tasks that you typically must complete to install a read-only domain controller

(RODC), including:

Choosing whether to upgrade an existing domain controller or install a new domain controller

Choosing whether to install the Server Core or the Full installation option

Using virtualization

Installing writable domain controllers

Installing RODCs

Depending on the scenario in which you plan to use an RODC, you may need to perform some

additional tasks.

Choosing whether to upgrade an existing domain controller or install a new domain controllerTo install a domain controller running Windows Server 2008, you can either upgrade an existing

domain controller that runs Windows Server 2003 or you can install a new server that runs

Windows Server 2008. This section explains the advantages and disadvantages of each

approach.

Upgrading an existing domain controllerAlthough you cannot upgrade domain controllers that run Windows 2000 Server to

Windows Server 2008, you can upgrade domain controllers running Windows Server 2003. When

you upgrade a Windows Server 2003 domain controller, it always remains a writable domain

59

controller. You cannot make a Windows Server 2003 domain controller an RODC during the

upgrade.

If you want to upgrade a Windows Server 2003 domain controller and make it an RODC, you

must remove Active Directory Domain Services (AD DS). You can remove AD DS either just

before or just after you upgrade the operating system. After you upgrade the server and it is no

longer a domain controller, reinstall AD DS and choose the RODC option during the AD DS

installation.

If the existing domain controller is in a remote location, you can reinstall AD DS more efficiently

by using the install from media (IFM) feature. The recommended steps for using IFM to reinstall

AD DS are as follows:

1. Upgrade the operating system of the Windows Server 2003 domain controller to

Windows Server 2008. For more information, see Upgrade Existing Domain Controllers to

Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=120008).

2. Run the ntdsutil ifm command to create installation media for an RODC, which removes any

cached secrets, such as passwords. For more information, see Installing AD DS from Media


3. Remove AD DS. For more information, see Removing a Windows Server 2008 Domain

Controller from a Domain (http://go.microsoft.com/fwlink/?LinkId=120012).

4. Reinstall AD DS using the IFM feature. For more information, see Installing AD DS from

Media (http://go.microsoft.com/fwlink/?LinkId=120013).

The following table lists some advantages and disadvantages of upgrading an existing domain

controller.

60





Advantages Disadvantages

The server retains information about its

state after the upgrade is complete. For

example, the domain controller retains the

same name, IP address, and other network

connection settings.

There are no additional costs for shipping a

new server to the location.

An increased amount of verification is

required after the upgrade is complete to

ensure that all existing data, services, and

settings are retained and functioning after

the upgrade is complete.

It is not possible to upgrade to the Server

Core installation option of the

Windows Server 2008 operating system.

It is not possible to upgrade directly to an

RODC. To make any writable domain

controller be an RODC, you need to

remove and then re-install AD DS.

Upgrading any application to run on a

server that runs Windows Server 2008 is

supported only if the application is certified

for Windows Server 2008. For more

information about applications that are

certified for Windows Server 2008, see

Windows Server Catalog

(http://go.microsoft.com/fwlink/?

LinkId=120525). If an application is not

certified for Windows Server 2008, you

must uninstall it before the upgrade and re-

install it after the upgrade.

Known issues for upgrading domain controllers

A branch office might have a single server that performs other server roles, in addition to AD DS

and DNS. For this type of server, you must perform additional testing to ensure that the other

server roles function correctly after the upgrade. In some cases, you may be able to perform

workarounds to avoid problems. Check the issues in the following list, and plan to resolve any

issues that can arise if you are upgrading a server that hosts a particular server role or

application.

An additional domain controller that is running Windows Server 2008 and that has the

Japanese language locale installed does not receive updates to some attributes on an object

during inbound replication. There are steps that you can take to prevent this issue from

occurring, and there are steps that you can take to resolve the issue if the issue has already

occurred. For more information, see article 949189 in the Microsoft Knowledge Base


61




The Windows SharePoint® Services 3.0 Search index may be corrupted when you upgrade

Windows Server 2003 to Windows Server 2008. If you are upgrading a server that hosts

Windows SharePoint Services 3.0, see article 943605 in the Microsoft Knowledge Base

(http://go.microsoft.com/fwlink/?LinkId=111882). This article provides steps for avoiding

corruption problems, and it provides steps for resolving corruption problems if they occur.

After you upgrade from Windows Server 2003 to Windows Server 2008, you cannot locally

configure or locally delete the application partitions that are created for IP telephony because

the Tapicfg.exe tool is not included in Windows Server 2008. You must complete any deletion

and configuration changes before you upgrade to Windows Server 2008. For more

information, see article 947039 in the Microsoft Knowledge Base


Installing a new domain controllerMany organizations choose to install new servers rather than upgrade existing servers. In many

cases, the decision to begin using a new operating system coincides with a scheduled hardware

refresh, in which an organization replaces all of its existing servers with new servers that run the

new operating system.

Installing new servers is especially advantageous when you are performing a platform upgrade,

such as replacing x86-based servers with 64-bit servers. In this case, there is no option to

upgrade the existing servers.

The following table lists additional advantages and disadvantages of installing a new domain

controller.

Advantages Disadvantages

Newer servers typically have better

resources and significant performance

advantages.

There are often fewer compatibility issues

with other devices such as network

adapters and storage controllers.

There are significant costs associated with

purchasing new hardware.

When you install a new domain controller,

you must configure all settings and other

state information, such as network settings

and user profile information.

Choosing whether to install the Server Core or the Full installation options and using BitLockerWindows Server 2008 provides two different installation options, a full installation option and a

Server Core installation option.

The full installation provides all the server roles and features that are available in Windows

Server 2008. The full installation includes a graphical user interface (GUI).

62



A Server Core installation is a minimal installation for running a limited set of server roles. A

server running a Server Core installation does not have a GUI or provide the ability to run most

applications, which helps to reduce the attack surface of the server. To improve the security of

branch office domain controllers, we recommend deploying RODCs that run on the Server Core

installation.

The following sections provide more details about the Server Core installation and Windows

BitLocker™ Drive Encryption, which you can also use to provide additional security for branch

office servers such as RODCs.

Using the Server Core installation for RODCs

A server running a Server Core installation can run the following server roles:

AD DS

Active Directory Lightweight Directory Services (AD LDS)

DNS

Dynamic Host Configuration Protocol (DHCP)

File Server

Internet Information Services (IIS)

Print Server

Streaming media services

In addition to being able to run these server roles, you can install other Windows Server 2008

features on a Server Core installation, such as BitLocker Drive Encryption and

Windows Server Backup. For a complete list of the features that you can install with a Server

Core installation, see Server Core Installation Option (http://go.microsoft.com/fwlink/?

LinkId=120025).

A Server Core installation provides the following benefits:

Reduced maintenance. Because a Server Core installation installs only what is required for

the specified server roles, less servicing is required than is required for a full installation of

Windows Server 2008.

Reduced attack surface. Because a Server Core installation is minimal, there are fewer

applications running on the server, which decreases the attack surface.

Reduced management. Because fewer applications and services are installed on a server

running a Server Core installation, there are less applications and services to manage.

Less required disk space. A Server Core installation requires only about 1 gigabyte (GB) of

disk space to install and approximately 2 GB for operations after the installation. However, the

system state backups for a domain controller that runs on a Server Core installation will not

use significantly less space than the system state backups for a full installation. This is

because the system state components for a domain controller, which include the

Active Directory database, SYSVOL, the registry, and some operating system files, are the

same for each installation option. Backups generally require similar resources for each

installation option.

63



A Server Core installation is not an application development platform, and it is not designed to run

roles and features other than the roles and features that are supported by default. But you can

run many types of applications on a Server Core installation. Be sure to test all applications that

you intend to run on a Server Core installation. As a general rule, the applications should meet

the following criteria:

The application installs silently, meaning it does not require interactive attention from an

administrator.

The application does not depend on a GUI.

The application does not depend on server roles or Windows features that might not be

installed on the Server Core installation.

Applications that depend on the .Net Framework, Windows Explorer, Windows PowerShell, or

Microsoft Management Console (MMC) will not run on a Server Core installation. However, many

monitoring and management applications, including many non-Microsoft backup and antivirus

programs, can run on a Server Core installation without any problems. Microsoft Operations

Manager (MOM) 2005, Systems Management Server (SMS) 2003, and Microsoft System Center

Operations Manager 2007 are examples of management applications that run on Server Core.

Considerations for installing Server Core and upgrading domain controllers

Keep in mind the following considerations as you plan whether to use the Server Core installation

option:

A Server Core installation is not a separate version or edition of Windows Server 2008. It is

an installation option that you can choose to run on any edition of Windows Server 2008.

You cannot upgrade a domain controller that runs Windows 2000 Server or

Windows Server 2003 to a Server Core installation of Windows Server 2008.

You cannot convert from a full installation to a Server Core installation, or the reverse.

From an administrative workstation that runs Windows Vista with Service Pack 1 (SP1) or

Windows Server 2008, you can use the MMC snap-ins in Remote Server Administration Tools

(RSAT) to remotely administer a Server Core installation. For more information, see Using

RSAT.

Using BitLocker on RODCs

RODCs do not require you to install BitLocker™ Drive Encryption. RODCs do not contain

passwords. Therefore, by default they can be deployed more securely than a writable domain

controller. But if your organization is planning on deploying an RODC in a location where it might

be stolen, you may want to install BitLocker as an additional precaution to help safeguard data on

the server.

Whereas RODCs prevent some sensitive data, including secrets and attributes in the RODC

filtered attribute set (FAS), from ever being present on the server, BitLocker encrypts the data that

is present on the server to protect it from being retrieved by an attacker, including, in particular, all

remaining Active Directory data, Group Policy data, file shares, and data on local volumes.

64

One possible administrative disadvantage to using BitLocker on an RODC is that you have to

provide a password and restart the RODC each time that you apply an operating system update

to it. Weigh the potential security benefits that BitLocker provides against this additional

administrative requirement to determine whether to use BitLocker on a specific RODC.

BitLocker is integrated with AD DS on domain controllers running Windows Server 2003 with

Service Pack 1 (SP1), Windows Server 2003 R2, or Windows Server 2008. You have to configure

AD DS to back up recovery information for BitLocker and the Trusted Platform Module (TPM). For

more information, see Configuring Active Directory to Back up Windows BitLocker Drive

Encryption and Trusted Platform Module Recovery Information (http://go.microsoft.com/fwlink/?

LinkId=120069).

Using virtualizationServer virtualization is a significant trend in all types of enterprises. Virtualization offers many

benefits, including better use of hardware capacity, improved disaster recovery scenarios, and

more manageable hardware upgrades.

You can run any type of domain controller as a virtual server. However, there are a number of

considerations that you should take into account. For more information about considerations for

hosting a domain controller as a virtual server, see article 888794 in the Microsoft Knowledge

Base (http://go.microsoft.com/fwlink/?LinkId=113458) and Running Domain Controllers in

Virtual Server 2005 (http://go.microsoft.com/fwlink/?LinkID=38330). The guidelines in these

documents are applicable for Windows Server 2008, in addition to Windows Server 2003.

You can use virtualization to reduce the number of servers that you deploy in hub sites and

branch offices. However, for any writable domain controller, there is a risk of encountering a

condition called an update sequence number (USN) rollback. A USN rollback occurs when you

perform an improper restore operation. This is particularly easy to do when you use virtualization,

because it becomes possible to take a backup of a domain controller, for example, by using the

snapshot feature of Microsoft Hyper-V™ Server and then reusing this backup later to effectively

“go back in time.”

What happens is the following:

1. At time T0, you take a snapshot (backup) of the virtual computer (which is a writable domain

controller).

2. The domain controller processes any changes, and the changes are replicated to other

domain controllers in the forest. The USN, which acts as a logical clock for the domain

controller, increases. The other domain controllers that have replicated these changes then

modify their up-to-dateness (UTD) vector based on the new value of the USN for the domain

controller from which the changes originate.

3. You restore the domain controller by using the snapshot in step 1. The USN for the domain

controller is then restored to the previous value that it had at time T0. The domain controller

processes additional changes, and the USN increases. In this situation, one of following two

things can happen:

65





a. If the value of the USN on the restored domain controller has not reached the value that it

had before the restore operation by the next replication cycle, the domain controller that

replicates the updates detects that its partner was improperly restored (because the USN

that is stored in its UTD vector is higher than the USN that is advertised by the restored

domain controller). The improperly restored domain controller is then automatically

quarantined to avoid divergence in the forest.

b. If the value of the USN on the restored domain controller has surpassed the value that it

had before the restore operation by the next replication cycle, the domain controller that

replicates from it requests only the changes that correspond to the USN values between

the value it has stored in its UTD vector (which is based on the USN from just before the

improper restore) and the new value. This means that the data that is stored on both

domain controllers is different. The improperly restored domain controller does not have

the changes that occurred before the restore, but it does have all the new changes. The

replication partner of this domain controller has all the changes that occurred before the

restore and only the new changes that correspond to the higher USN than the USN that

is stored in its UTD vector. It is important to note that the domain controllers in this case

cannot detect the USN rollback. The set of changes that are divergent between the two

domain controllers is referred to as a “USN bubble,” and they cannot be corrected.

For more information about USN rollback, see article 875495 in the Microsoft Knowledge Base


It is important to note that RODCs do not have the same risk for USN rollback because they do

not perform outbound replication. This helps make RODCs less susceptible to problems in a

virtual environment than writable domain controllers. An RODC that is restored with a Hyper-V

snapshot replicates all changes that it needs, but no divergence will happen in the forest because

of such a restore.

There are two other issues to keep in mind because they apply to RODCs:

You should not copy .vhd files, which are virtual hard disk files, because cloning of domain

controllers is not supported. It can result in divergences in the forest. To add more domain

controllers to a domain, install the operating system on the new virtual server and use

Dcpromo.exe to make that server an additional domain controller in an existing domain.

You should not pause and restart virtual machines because doing so can lead to the

Windows Time service (W32time) not working correctly. However, this type of issue occurs

less frequently when you use Hyper-V to virtualize servers.

In general, it is preferable to separate the AD DS domain controller role from other server roles,

both on physical servers and virtualized servers. The administrators who manage AD DS are not

typically the same administrators as for other server roles, such as IIS or Microsoft Internet

Security and Acceleration (ISA) Server. Virtualization makes it possible to isolate the server roles

by providing a way for you to deploy multiple virtual servers that are each dedicated to specific

functions on a single physical computer.

We recommend that you install one virtual server that is dedicated to AD DS and DNS. Note that

the File Replication Service (FRS) or Distributed File System (DFS) Replication are also installed

on the same server for SYSVOL replication. Dedicate one virtual server or multiple other virtual

66


servers to other functions. This recommendation applies to both writable domain controllers and

RODCs.

The best practice for Hyper-V is to deploy the Hyper-V role on a Server Core installation of

Windows Server 2008 and then run any other roles, including AD DS, as virtual machines.

The Branch Infrastructure Implementation Solution for Windows Server 2008 provides automated

tools and technical guidance for assessment, planning, design, and security for Hyper-V and

Virtual Server 2005 R2. For more information about the Branch Infrastructure Implementation

Solution for Windows Server 2008, see the Branch Infrastructure Implementation Solution for

Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=120084).

Installing writable domain controllersThe main issue with regard to deploying writable domain controllers in hub sites and data centers

is making sure that you have enough domain controllers up and running to support the branch

office domain controllers during the switchover to Windows Server 2008. If you are upgrading all

your current Windows Server 2003 domain controllers to Windows Server 2008 and you are not

adding any new servers, you might have to upgrade the domain controllers one at a time to

ensure that remaining domain controllers in the hub site do not become overloaded as they

handle the replication workload.

The steps that you have to perform to install writable domain controllers by using the GUI,

command line, or an answer file are documented in Installing an Additional Windows Server 2008

Domain Controller (http://go.microsoft.com/fwlink/?LinkID=93254).

Installing RODCsThere are two different methods for installing an RODC. Each method provides advantages for

specific installation scenarios.

Staged installation. This is a new installation method that is specifically designed to make it easier

to deploy RODCs in remote locations. This new method does not require a member of the

Domain Admins group to complete the installation in the remote location. You can delegate the

installation to any domain user.

This installation method is advantageous when you are installing an RODC as the first domain

controller in a remote site or you are replacing an RODC with another RODC. If you are replacing

a writable domain controller in a branch office with an RODC, a staged installation does not

provide any advantage over a direct installation. This is because the same person who is

currently managing the domain controller that is being replaced in that site can perform a full

promotion of the RODC, and there is no need to delegate the installation to a domain user.

Direct installation. This is the same installation as for any additional domain controller. To make

the additional domain controller an RODC, you only have to select the RODC domain controller

option during the installation. To complete a full promotion of an RODC, you must be a member of

the Domain Admins group or you must be delegated the appropriate permissions.

67



Note

You cannot transform an RODC into a writable domain controller or a writable domain

controller into an RODC. To change a writable domain controller to an RODC, you have

to demote the writable domain controller and then promote it again as an RODC.

Because you need to use Domain Admin credentials to demote the writable domain

controller, you most often perform a direct installation in this situation.

Staged installationWindows Server 2008 includes a new, staged installation process that you can use to install an

RODC in two stages. A Domain Admin can delegate the final stage of an RODC installation to any

domain user or group. The delegated user can complete the RODC installation in the branch

office where the RODC will ultimately be located and perform administration tasks on the RODC

after installation. This section describes the steps for installation. For steps for administering an

RODC, see RODC Administration.

Staged installation is designed specifically to help you deploy RODCs to remote branch offices by

separating the RODC installation process into two stages.

1. A Domain Admin creates a computer account for the RODC and (as an option) delegates a

user or group the ability perform the second stage of the installation and be the server

administrator for the RODC after the installation is complete. A Domain Admin will typically

complete this stage in a central location, such as a datacenter or hub site.

2. The delegated RODC server administrator joins the server to the RODC account that the

Domain Admin created for it. A staged AD DS installation makes it unnecessary to use a

highly privileged Domain Admin account in the branch office to complete the installation of

AD DS. The delegated RODC server administrator will typically complete this stage in branch

office where the organization plans to deploy the RODC.

You can also use the IFM installation option in conjunction with a staged installation. The IFM

option significantly reduces the amount of data that has to be replicated to a new domain

controller over the network during the installation of AD DS.

When you use the IFM option for an RODC installation, you can secure the installation media

before transporting it to the branch office by removing secrets, such as user account passwords,

from it. This way, if the installation media is lost or stolen while it is being transported, it cannot be

compromised to reveal passwords. Because the RODC does not cache any passwords by

default, they do not need to be present in the RODC installation media.

You can use the ntdsutil ifm command to create the media that you use for the IFM installation

option. For a procedure that uses this command, see Installing AD DS from Media


The staged installation process works as follows:

1. In the datacenter, an administrator uses the Active Directory Users and Computers snap-in to

create an account in the Domain Controllers container for the RODC. This account creation

process uses Dcpromo.exe, and it can be scripted if you need to create many accounts.

68


While creating the account, the administrator can also specify who will administer the RODC

and whose passwords can be cached on it.

2. The administrator obtains the server running Windows Server 2008 and has it shipped

directly to the branch office where it will be used as an RODC.

3. In the branch office, a local user (delegated by the administrator in step 1) starts the server

and runs Dcpromo, installing AD DS and completing the RODC installation. No highly

privileged credentials have to be used in the branch office, either by the local user or remotely

by a datacenter administrator.

Although performing a staged installation can help streamline the process for deploying RODCs

in branch offices, some organizations might continue to use procedures in which servers are built

in a central location and then transported to a branch office. Some reasons for retaining these

procedures include:

Security classification tagging or certification

Asset tagging

Installing new hardware or custom hardware

Ensuring that the computer has all of its hardware and software updates before it is

connected in the field

Burn-in testing (ensuring that all the hardware does not fail in the first 72 hours)

Note

If you continue to build servers in a central (hub) location, be aware that if a domain

controller that you build in the central location is disconnected from the network for more

than 30 days while it is transported to the branch office, you might have to reset the

machine account passwords so that the domain controller can perform replication. For

more information, see article 260575 in the Microsoft Knowledge Base


For more information about performing a staged installation, see Performing a Staged RODC

Installation (http://go.microsoft.com/fwlink/?LinkID=103323).

Direct installationIf you intend to perform a direct installation for an RODC, you can follow the same steps that you

used to install the writable domain controller in the hub site. A direct installation combines both

stages of a staged installation into a single step.

On the Additional Domain Controller Options page of the Active Directory Domain Services

Installation Wizard, select the Read-only domain controller check box. Be sure to delegate a

security group to administer the RODC. You can also specify the Password Replication Policy

(PRP) for the RODC during the installation.

Whether you specify the PRP during or after installation, cache the password of at least one user

from the security group that you delegated to administer the RODC. This ensures that some user

always has the ability to log on to the RODC by using the delegated account instead of privileged

credentials. Refresh the cache after each time that the password is changed.

69



For more information, see Direct Installation Method.

Installing AD DS from Media

You can use Ntdsutil.exe to create installation media for additional domain controllers that you are

creating in a domain. By installing from media, you can minimize the replication of directory data

over the network. This helps you install additional domain controllers in remote sites more

efficiently.

Ntdsutil.exe can create the two types of installation media as described in the following table.

Note

Although you can run ntdsutil with an option to include the SYSVOL shared folder in the

installation media, the SYSVOL folder will not be used when you create the additional

domain controller. The SYSVOL folder from the installation media is not used because

SYSVOL must be absent when the Active Directory Domain Services server role starts on

a server running Windows Server 2008.

To create installation media for a full (or writable) domain controller, you must run the ntdsutil ifm

command on a writable domain controller.

To create installation media for an RODC, you can run the ntdsutil ifm command on either a

writable domain controller or an RODC that runs Windows Server 2008. For RODC installation

media, ntdsutil removes any cached secrets, such as passwords.

Type of installation media Parameter Description

Full (or writable) domain

controller

Create Full %s Creates installation media for a

writable domain controller or an

Active Directory Lightweight

Directory Services (AD LDS)

instance into folder %s

Read-only domain controller Create RODC %s Creates installation media for an

RODC into folder %s

You cannot run the ifm command on a domain controller that runs Windows Server 2003.

However, you can create a backup of a Windows Server 2003 domain controller and then use the

dcpromo /adv command to create a Windows Server 2003 domain controller.

You can use a 32-bit domain controller to generate installation media for a 64-bit domain

controller, and vice-versa.

You can use the following procedure to create AD DS installation media.


70

To create installation media, you must be able to log on to a domain controller interactively and be

able to make a backup.

On a writable domain controller, this means that you must be a member of the Builtin

Administrators, Server Operators, Domain Admins, or the Enterprise Admins groups to perform

the following procedure.

On an RODC, a delegated user can create the installation media, but you can only create RODC

installation media (not installation media for a writable domain controller) on an RODC.

To create installation media

1. Click Start, right-click Command Prompt, and then click Run as administrator to open

an elevated command prompt.


ntdsutil

3. At the ntdsutil prompt, type the following command, and then press ENTER:

activate instance ntds

4. At the ntdsutil prompt, type the following command, and then press ENTER:

ifm

5. At the ifm: prompt, type the command for the type of installation media that you want to

create, and then press ENTER. For example, to create RODC installation media, type the

following command:

Create rodc C:\InstallationMedia

Where:

C:\InstallationMedia is the path to the folder where you want the installation media to be

created. You can save the installation media to a network shared folder or to any other

type of removable media.

When you create additional domain controllers in the domain, you can refer to the shared folder

or removable media where you store the installation media—on the Install from Media page in

the Active Directory Domain Services Installation Wizard or by using the /ReplicationSourcePath

parameter during an unattended installation.

The wizard installs AD DS using the data in the installation media, which eliminates the need to

replicate every object from a partner domain controller. However, objects that were modified,

added, or deleted since the installation media was created must be replicated. If the installation

media was created recently, the amount of replication that is required is considerably less than

the amount of replication that is required for a regular AD DS installation.

Note that the entire SYSVOL data must be replicated from another domain controller.

71

Direct Installation Method

This topic describes the steps for performing a direct installation of a read-only domain controller

(RODC). In a direct installation, you specify all the parameters that are necessary to install the

RODC in a single operation. A direct installation of an RODC is an alternative to a staged

installation, in which the parameters that are needed to install the RODC are specified in two

different procedures, completed by different people in different locations and at different times.

You can perform a direct installation of an RODC using any of the following:

Using the Windows interface

Using the command line

Using an answer file

Membership in Domain Admins, or equivalent, is the minimum required to complete these

procedures. Review details about using the appropriate accounts and group memberships at

http://go.microsoft.com/fwlink/?LinkId=83477.

To perform a direct installation of an RODC using the Windows interface

1. Click Start. In the Start Search box, type dcpromo, and then press ENTER.

2. On the Welcome page, select the Use advanced installation mode check box, and

then click Next.

The advanced installation mode in the Active Directory Domain Services Installation

Wizard provides you with options to install from media (IFM), choose the source domain

controller, and specify the Password Replication Policy (PRP) during the RODC

installation.

Welcome page

72


3. Review the information on the Operating System Compatibility page, and then click

Next.

Operating System Compatibility page

73

4. On the Choose a Deployment Configuration page, click Existing forest, click Add a

domain controller to an existing domain, and then click Next.

Choose a Deployment Configuration page

74

5. On the Network Credentials page, type the name of a domain in the forest where you

want to install an RODC, specify account credentials with sufficient permissions to install

an additional domain controller, and then click Next.

Network Credentials page

75

6. On the Select a Domain page, click the name of the domain in which you want to install

an RODC, and then click Next.

Select a Domain page

76

7. On the Select a Site page, click the name of the site where you want to install an RODC,

and then click Next.

We recommend that you assign a static IP address to the server that you want to be an

RODC. If you have assigned subnets to your sites and if you have assigned a static IP

address to the server that will become the RODC, the site that maps to the IP address of

the server will be selected by default.

Unless all the IP addresses that are associated with the network adapter of the server are

static, including the IP version 4 (IPv4) and IP version 6 (IPv6) addresses, the wizard

displays a warning that indicates that at least one of the IP addresses of the server is

dynamic.

8. On the Additional Domain Controller Options page, click the DNS server, Global

catalog, and Read-only domain controller (RODC) check boxes, and then click Next.

Additional Domain Controller Options page

77

9. On the Specify Password Replication Policy page, click Add.

Specify Password Replication Policy page

78

10. In the Select Users, Computers, or Groups dialog box, type the names of the users

and computers, or groups of users or computers, whose passwords you want to be

cached on the RODC.

Remember that you must add the computer accounts for any user accounts that you

want to be cached so that those users can be authenticated by the RODC when no other

domain controller is available. This is also true for service accounts that log on in the site

that has the RODC.

Select Users, Computers, or Groups for the Password Replication Policy

79

Click OK to close the Select Users, Computers, or Groups dialog box. On the Specify

Password Replication Policy page, click Next.

11. On the Delegation of RODC Installation and Administration page, click Set.

12. In the Select User or Group dialog box, type the name of the user or group that will

administer that RODC, and then click OK. We recommend that you specify a group rather

than an individual account so that you can efficiently manage changes to the delegation

when they arise.

Select a User or Group to be the Delegated RODC server administrator

On the Delegation of RODC Installation and Administration page, click Next.

13. On the Install from Media page, if you have created installation media for an RODC,

click Replicate data from media at the following location, and then type the path to

the media location. If you have not created installation media, click Replicate data over

the network from an existing domain controller. After you make a selection, click

80

Next.

Install from Media page

14. On the Source Domain Controller page, click Let the wizard choose an appropriate

domain controller, or, if you want to use a specific domain controller as the replication

source during the installation, click Use this specific domain controller, and then click

the name of the domain controller that you want to use. After you make a selection, click

Next.

Source Domain Controller page

81

15. On the Location for Database, Log Files, and SYSVOL page, type the path where you

want to store the Active Directory database, log files, and SYSVOL, and then click Next.

Location for Database, Log Files, and SYSVOL page

82

16. On the Directory Services Restore Mode Administrator Password page, type and

confirm a password that will be used to log on to the domain controller when it is started

in Directory Services Restore Mode (DSRM).

Directory Services Restore Mode Administrator Password page

83

17. On the Summary page, confirm your selections. To save the settings that you have

entered so that you can reuse them to automate additional domain controller installations,

click Export settings.

Summary page

84

18. Click Next to begin the installation.

You can use the following procedure to perform an unattended installation of a new RODC from

the command line. For a complete list of unattended installation options, including default values,

allowed values, and descriptions, at a command prompt, type dcpromo /?:Promotion, or see

Promotion Operation (http://go.microsoft.com/fwlink/?LinkID=120626).

To perform a direct installation of an RODC using the command line

1. At a command prompt, type the following command, and then press ENTER:

dcpromo /unattend /<unattendOption>:<value> /<unattendOption>:<value> ...

Where:

<unattendOption> is an option in the Promotion Operation

(http://go.microsoft.com/fwlink/?LinkID=120626) table. Separate each <option:value>

pair with a space.

<value> is the configuration instruction for the option.

The following example creates an RODC in the contoso.com domain, along with the

85



global catalog, and it installs and configures the Domain Name System (DNS) Server

service:

dcpromo /unattend /InstallDns:yes /confirmGC:yes

/replicaOrNewDomain:ReadOnlyReplica /replicaDomainDNSName:

contoso.com/databasePath:"e:\ntds" /logPath:"e:\ntdslogs" /sysvolpath:"g:\

sysvol" /safeModeAdminPassword:FH#3573.cK /rebootOnCompletion:yes

2. When you have typed all the options that are required to create the additional domain

controller, press ENTER.

To perform a direct installation of an RODC using an answer file

1. Open Notepad or any text editor.

2. On the first line, type [DCINSTALL], and then press ENTER.

3. Create the following entries, one entry on each line. For a complete list of unattended

installation options, including default values, allowed values, and descriptions, see

Promotion Operation (http://go.microsoft.com/fwlink/?LinkID=120626).

UserName=<administrative account with sufficient credentials to install an RODC>

UserDomain=<name of the domain for the administrative account that is used to install

the RODC>

Password=<password for the account in UserName>

ReplicaOrNewDomain=ReadOnlyReplica

ReplicaDomainDNSName=<name of the domain where you are installing an RODC>

ReplicationSourcePath=<path to the location where the installation media is stored for

the IFM option>

DelegatedAdmin=<name of the user or group who will administer the RODC>

DatabasePath=<path to a folder on a local volume, surrounded by double quotation

marks>

LogPath=<path to a folder on a local volume, surrounded by double quotation marks>

SYSVOLPath=<path to a folder on a local volume, surrounded by double quotation

marks>

; RODC Password Replication Policy

PasswordReplicationDenied=BUILTIN\Administrators

PasswordReplicationDenied="BUILTIN\Server Operators"

PasswordReplicationDenied="BUILTIN\Backup Operators"

PasswordReplicationDenied="BUILTIN\Account Operators"

PasswordReplicationDenied=DomainName\"Denied RODC Password Replication Group"

PasswordReplicationAllowed=DomainName\"Allowed RODC Password Replication

Group"

PasswordReplicationAllowed=GroupName1

86



PasswordReplicationAllowed=User_Name1

PasswordReplicationAllowed=Computer_Name1

InstallDNS=yes

ConfirmGC=yes

SafeModeAdminPassword=password

RebootOnCompletion=yes

4. Save the answer file to the location on the installation server from which it is to be called

by Dcpromo, or save the file to a network shared folder or removable media for

distribution.

5. At the command prompt on the server that you want to be an RODC, type the following

command, and then press ENTER:

dcpromo /unattend:"<path to the answer file>"

Performing a Staged RODC Installation

You can perform an installation of an RODC in which the installation is completed in two stages

by different individuals. The first stage of the installation, which requires domain administrative

credentials, creates an account for the RODC in AD DS. The second stage of the installation

attaches the actual server that will be the RODC in a remote location, such as a branch office, to

the account that was previously created for it. You can delegate the ability to attach the server to

a nonadministrative group or user.

During this first stage, the wizard records all data about the RODC that will be stored in the

distributed Active Directory database, such as its domain controller account name and the site in

which it will be placed. This stage must be performed by a member of the Domain Admins group.

The administrator who creates the RODC account can also specify at that time which users or

groups can complete the next stage of the installation. The next stage of the installation can be

performed in the branch office by any user or group who was delegated the right to complete the

installation when the account was created. This stage does not require any membership in built-in

groups, such as the Domain Admins group. If the user who creates the RODC account does not

specify any delegate to complete the installation (and administer the RODC), only a member of

the Domain Admins or Enterprise Admins groups can complete the installation.

During the second stage, the wizard installs AD DS on the server that will become the RODC and

attaches the server to the domain account that was previously created for it. This stage typically

occurs in the branch office where the RODC is deployed. During this stage, all AD DS data that

resides locally, such as the database, log files, and so on, is created on the RODC itself. The

installation source files can be replicated to the RODC from another domain controller over the

87

network, or you can use the install from media (IFM) feature. To use IFM, use Ntdsutil.exe to

create the installation media.

The server that will become the RODC must not be joined to the domain before you try to attach it

to the RODC account. As part of the installation, the wizard automatically detects whether the

name of the server matches the names of any RODC accounts that have been created in

advance for the domain. When the wizard finds a matching account name, it prompts the user to

use that account to complete the RODC installation.

You can complete each stage of the installation using any of the following methods:

Windows interface

Answer file

Command line

Performing a staged RODC installation by using the Windows interfaceYou can use the Active Directory Users and Computers snap-in to create an RODC account.

To create an RODC account by using the Windows interface

1. Click Start, click Administrative Tools, and then click Active Directory Users and

Computers.

2. Either right-click the Domain Controllers organizational unit (OU) or click the Domain

Controllers OU, and then click Action.

3. Click Pre-create Read-only Domain Controller account.

4. On the Welcome to the Active Directory Domain Services Installation Wizard page, if

you want to modify the default the Password Replication Policy, select Use advanced

mode installation, and then click Next.

5. On the Operating System Compatibility page, review the warning about the default

security settings for Windows Server 2008 domain controllers and then click Next.

6. On the Network Credentials page, under Specify the account credentials to use to

perform the installation, click My current logged on credentials or click Alternate

credentials, and then click Set. In the Windows Security dialog box, provide the user

name and password for an account that can install the additional domain controller. To

install an additional domain controller, you must be a member of the Enterprise Admins

group or the Domain Admins group. When you are finished providing credentials, click

Next.

7. On the Specify the Computer Name page, type the computer name of the server that

will be the RODC.

8. On the Select a Site page, select a site from the list or select the option to install the

domain controller in the site that corresponds to the IP address of the computer on which

you are running the wizard, and then click Next.

88

9. On the Additional Domain Controller Options page, make the following selections, and

then click Next:

DNS server: This option is selected by default so that your domain controller can

function as a DNS server. If you do not want the domain controller to be a DNS

server, clear this option. However, if you do not install the DNS server role on the

RODC and the RODC is the only domain controller in the branch office, users in the

branch office will not be able to perform name resolution when the WAN to the hub

site is offline.

Global catalog: This option is selected by default. It adds the global catalog, read-

only directory partitions to the domain controller, and it enables global catalog search

functionality. If you do not want the domain controller to be a global catalog server,

clear this option. However, if you do not install a global catalog server in the branch

office or enable universal group membership caching for the site that includes the

RODC, users in the branch office will not be able to log on to the domain when the

WAN to the hub site is offline.

Read-only domain controller. When you create an RODC account, this option is

selected by default and you cannot clear it.

10. If you selected the Use advanced mode installation check box on the Welcome page,

the Specify the Password Replication Policy page appears. By default, no account

passwords are replicated to the RODC, and security-sensitive accounts (such as

members of the Domain Admins group) are explicitly denied from ever having their

passwords replicated to the RODC.

To accept the default setting, click Next.

-or-

To add other accounts to policy, click Add. If the accounts will be allowed to have their

passwords replicated to the RODC, click Allow passwords for the account to replicate

to this RODC. If the accounts will be denied from having their passwords replicated to

the RODC, click Deny passwords for the account from replicating to this RODC.

Then, click OK. When you are done adding other accounts, click Next.

When you install the first RODC in a domain, domain group accounts that are required for

RODCs to function are created. Depending on your replication topology, the wizard might

return an error indicating that these group accounts are not available when you try to

install another RODC in the domain. In this case, wait for replication to complete before

you install the additional RODC.

11. In Select Users, Computers, and Groups, type the names of the accounts that you

want to add to the policy, and then click OK.

12. On the Delegation of RODC Installation and Administration page, type the name of

the user or the group who will attach the server to the RODC account that you are

creating. You can type the name of only one security principal.

To search the directory for a specific user or group, click Set. In Select Users,

Computers, or Groups, type the name of the user or group. We recommend that you

89

delegate RODC installation and administration to a group.

This user or group will also have local administrative rights on the RODC after the

installation. If you do not specify a user or group, only members of the Domain Admins

group or the Enterprise Admins group will be able to attach the server to the account.

When you are finished, click Next.

13. On the Summary page, review your selections. Click Back to change any selections, if

necessary.

To save the settings that you selected to an answer file that you can use to automate

subsequent AD DS operations, click Export settings. Type a name for your answer file,

and then click Save.

When you are sure that your selections are accurate, click Next to create the RODC

account.

14. On the Completing the Active Directory Domain Services Installation Wizard page,

click Finish.

After you create the account for the RODC, the user or group to whom you delegated installation

and administration of the RODC (in step 11 in the previous procedure) can run the Active

Directory Domain Services Installation Wizard on the server that will become the RODC. Make

sure that the server is not joined to the domain before you start the wizard.

To attach a server to an RODC account using the Windows Interface

1. Log on as local Administrator to the server that will become the RODC, and then open a

command prompt.


dcpromo /UseExistingAccount:Attach

Note

This command is required to start the second stage of the RODC installation.

After the administrator enters credentials (step 4), the wizard will automatically

detect the name of the server and try to match it to an RODC account that has

been pre-created for it.

3. On the Welcome to the Active Directory Domain Services Installation Wizard page,

click Next, or, if you want to install from media or identify the source domain controller for

AD DS replication, select the Use advanced mode installation check box

4. On the Network Credentials page, type the name of any existing domain in the forest

where you plan to install the additional domain controller. Under Specify the account

credentials to use to perform the installation, click Alternate credentials, and then

click Set. In the Windows Security dialog box, provide the user name and password for

an account that was delegated the ability to install and administer the RODC when the

RODC account was created. When you are finished providing credentials, click Next.

5. On the Select Domain Controller Account page, confirm that the wizard has found an

90

existing RODC account that matches the name of the server, and then click Next.

6. If you selected advanced installation mode, you can specify the following advanced

options:

a. On the Install from Media page, you can provide the location of installation media to

be used to create the domain controller and configure AD DS, or you can choose to

have all data replicated over the network. Note that some data will be replicated over

the network even if you choose to install from media. For information about using this

method to install the domain controller, see Installing AD DS from Media.

b. On the Source Domain Controller page, you can specify a domain controller from

which to replicate the configuration and schema directory partitions (or the entire

Active Directory database if you do not choose to install from media). If you select

This specific domain controller, you can select the domain controller that you want

to provide source replication to create the new domain controller, and then click Next.

7. On the Location for Database, Log Files, and SYSVOL page, type or browse to the

volume and folder locations for the database file, the directory service log files, and the

system volume (SYSVOL) files, and then click Next.

Windows Server Backup backs up the directory service by volume. For backup and

recovery efficiency, store these files on separate volumes that do not contain applications

or other nondirectory files.

8. On the Directory Services Restore Mode Administrator Password page, type and

confirm the restore mode password, and then click Next. This password is used to start

AD DS in Directory Service Restore Mode for tasks that must be performed offline. The

password complexity and length must comply with the domain security policy.

9. On the Summary page, review your selections. Click Back to change any selections, if

necessary.

To save the settings that you selected to an answer file that you can use to automate

subsequent AD DS operations, click Export settings. Type a name for your answer file,

and then click Save.

When you are sure that your selections are accurate, click Next to install AD DS.

10. You can either select the Reboot on completion check box to have the server restart

automatically or you can restart the server to complete the AD DS installation when you

are prompted to do so.

Performing a staged RODC installation by using an answer fileUse the following procedure to create an answer file for each stage of an RODC installation. In

the first stage, you create an RODC account. In the next stage, you attach the server to the

account. In this example, the DNS server and global catalog options are also installed but they

are not mandatory. The site name is mandatory for an RODC installation. If you are adding

91

multiple security principals to the RODC password replication policy, you must specify the

appropriate entry (allowed or denied) on a separate line for each security principal.

For a complete list of unattended installation options, including default values, allowed values,

and descriptions, see CreateDCAccount Operation (http://go.microsoft.com/fwlink/?

LinkId=122101) and UseExistingAccount Operation (http://go.microsoft.com/fwlink/?

LinkId=122102).

Creating the RODC accountUse the following procedure to create the RODC account.


To perform this procedure, you can use any account that has Read and Write privileges for the

text editor application.

To create an answer file for creating an RODC account

1. Open Notepad or any other text editor.


3. Type the following entries, one entry on each line:

; Read-Only Domain Controller Installation

ReplicaDomainDNSName=FullyQualifiedDomainName

DCAccountName=RODCName

; RODC Password Replication Policy

PasswordReplicationDenied=BUILTIN\Administrators

PasswordReplicationDenied="BUILTIN\Server Operators"

PasswordReplicationDenied="BUILTIN\Backup Operators"

PasswordReplicationDenied="BUILTIN\Account Operators"

PasswordReplicationDenied=DomainName\"Denied RODC Password Replication Group"

PasswordReplicationAllowed=DomainName\"Allowed RODC Password Replication

Group"



PasswordReplicationAllowed=User_Name1

PasswordReplicationAllowed=Computer_Name1

DelegatedAdmin=RODCAdministrator

SiteName=SiteName

InstallDNS=Yes

ConfirmGc=Yes

ReplicationSourceDC=SourceDCName

92







distribution.

Use the following table to replace the variables in the answer file with values that are appropriate

for your organization.

Placeholder Description

FullyQualifiedDomainName The fully qualified domain name (FQDN) of the

domain where you are installing the RODC

RODCName The name of the server that will become the

RODC.

Before anyone attempts to attach that server to

the account that you are creating, it must be

named with the name that you specify here and

it must not be joined to the domain.

DomainName The single-label DNS name or the FQDN of the

domain where you are installing the RODC.

GroupName1, GroupName2, User_Name1,

Computer_Name1,…

The name of the security principal that you are

adding to the password replication policy.

The account names must be enclosed within

quotation marks.

When you specify the accounts of mobile

users, also specify the computer accounts,

such as laptop computers, that those users will

use to log on to the RODC.

RODCAdministrator The name of the account to whom you are

delegating installation and administrative right

for the RODC.

You can specify only one user or group. As a

best practice, specify the name of a group.

Then, add to the group the account of any user

that you want to manage the RODC.

SiteName The name of the site where you want to install

the RODC.

SourceDCName The FQDN of the domain controller from which

you replicate the domain information (the

installation partner).

93

After you create the answer file, use the following procedure to automate the creation of the

RODC account.


To perform this procedure, you must be logged on to a domain controller as a member of the

Domain Admins group or the Enterprise Admins group.

To create an RODC account by using an answer file

At the command prompt, type the following, and then press ENTER:

dcpromo.exe /CreateDCAccount /unattend:"Path to answer file"

Attaching a server to an RODC accountUse the following procedure to create an answer file that can be used to attach a server to an

RODC account.

To create an answer file for attaching a server to an RODC account

1. Open Notepad or any other text editor.


3. Type the following entries, one entry on each line:

; Read-Only Domain Controller Installation

ReplicaDomainDNSName=FullyQualifiedDomainName

UserDomain=FullyQualifiedDomainName

UserName=DomainName\User_Name

Password=*

DatabasePath=PathToDatabase

LogPath= PathToLogFiles

SYSVOLPath= PathToSYSVOL

; Set SafeModeAdminPassword to the correct value prior to using the answer file

SafeModeAdminPassword=

; CriticalReplicationOnly=Yes

RebootOnCompletion=Yes



distribution.

Use the following table to replace the variables in the answer file with values that are appropriate

for your organization.

94

Placeholder Description

FullyQualifiedDomainName The FQDN of the domain where you are

installing the RODC. For UserDomain, enter

the domain name for the user name (account

credentials) that will be used to install a domain

controller.

DomainName\UserName The credentials of the user with the rights to

attach the server to the RODC account, in the

Windows NT format.

As a best practice, this user should be a

member of a security group that has been

delegated installation and administrative rights

for the RODC. If you do not specify a user, only

members of the Domain Admins Group or the

Enterprise Admins group can perform the

operation.

PathToDatabase The location of the directory database, for

example, C:\Windows\NTDS.

PathToLogFiles The location of the database log files, for

example, C:\Windows\NTDS.

PathToSYSVOL The location of the SYSVOL shared folder, for

example, C:\Windows\SYSVOL.

After you create the answer file, use the following procedure to automate the operation for

attaching the server to the RODC account. Before you begin this procedure, the server must be

named with the name of the RODC account and it must not be joined to the domain.


Use the following procedure to attach a server to an RODC account. Because the server is not

joined to the domain, log on to the server as the local Administrator.

To attach a server to an RODC account by using an answer file

At the command prompt, type the following, and then press ENTER:

dcpromo.exe /UseExistingAccount:Attach /unattend:"<Path to answer file>"

95

Performing a staged RODC installation by entering installation parameters at the command lineAlthough we recommend that you create an RODC account by using the Windows interface

because it reduces the chance for typing errors, you can use the following procedure to create an

RODC account, using unattended installation parameters, from the command line. If you are

creating an RODC account on a domain controller that is running a Server Core installation of

Windows Server 2008, you cannot use the Windows interface.


To perform this procedure, you must be logged on to a domain controller as a member of the

Domain Admins group or the Enterprise Admins group.

To create an RODC account by entering unattended installation parameters at the command line

1. At a command prompt, type the following, and then press ENTER:

dcpromo /unattend /CreateDCAccount /ReplicaDomainDNSName:<DomainName>

/DCAccountName:<RODCName> /SiteName:<SiteName> /<unattendOption>:<value>

/<unattendOption>:<value> ...

Where:

<DomainName> is the name of the domain where you are creating the RODC

account.

<RODCName> is the name of the RODC account that you want to create.

<SiteName> is the name of the site where you want to create the RODC account.

<unattendOption> is an option in the CreateDCAccount Operation

(http://go.microsoft.com/fwlink/?LinkId=122101) table. Separate each

<option>:<value> pair with a space.

<value> is the configuration instruction for the option

The following example creates an RODC account named RODC10 in the contoso.com

domain in the Default-First-Site-Name site with additional installation options:

dcpromo /CreateDCAccount /ReplicaDomainDNSName: contoso.com

/DCAccountName:RODC10 /SiteName:Default-First-Site-Name

/SourceDC:DC1.contoso.com /PasswordReplicationDenied=BUILTIN\Administrators

/PasswordReplicationDenied="BUILTIN\Server Operators"

/PasswordReplicationDenied="BUILTIN\Backup Operators"

/PasswordReplicationDenied="BUILTIN\Account Operators"

/PasswordReplicationDenied="Contoso\Denied RODC Password Replication Group"

/PasswordReplicationAllowed="Contoso\Allowed RODC Password Replication Group"

/PasswordReplicationAllowed="Group Name1" /PasswordReplicationAllowed="Group

96


Name2" /PasswordReplicationAllowed="User Name1"

/PasswordReplicationAllowed=ComputerName1 /DelegatedAdmin=BranchAdminGroup

2. When you finish typing all the options that are required to create the RODC account,

press ENTER.

After you create the RODC account, perform the following procedure on the server that will

become the RODC to attach that server to the RODC account.


Because the server is not joined to the domain, log on to the server as the local Administrator.

To attach a server to an RODC account by entering unattended installation parameters at the command line

1. At a command prompt, type the following, and then press ENTER:

dcpromo /unattend /UseExistingAccount:Attach

/ReplicaDomainDNSName:<FullyQualifiedDomainName>

/UserDomain:<FullyQualifiedDomainName> /UserName:<DomainName>\<UserName>

/password:* /<unattendOption>:<value> /<unattendOption>:<value> ...

Where:

<FullyQualifiedDomainName> is the FQDN of the domain where you are installing

the RODC. For /UserDomain, enter the domain name for the user name (account

credentials) that will be used to install a domain controller.

<DomainName>\<UserName> is the account credentials of the user with the rights to

attach the server to the RODC account, in the Windows NT format.

<unattendOption> is an option in the UseExistingAccount Operation

(http://go.microsoft.com/fwlink/?LinkId=122102) table. Separate each

<option>:<value> pair with a space.

<value> is the configuration instruction for the option

The following example attaches a server to an RODC account in the contoso.com

domain with additional installation options using the domain credentials of the contoso\

da1 account:

dcpromo /unattend /UseExistingAccount:Attach /ReplicaDomainDNSName: contoso.com

/UserDomain:contoso.com /UserName:contoso\da1 /password:* /databasePath:"e:\

ntds" /logPath:"e:\ntdslogs" /sysvolpath:"g:\sysvol"

/safeModeAdminPassword:FH#3573.cK /rebootOnCompletion:yes

2. When you finish typing all the options that are required to create the RODC account,

press ENTER.

97


Post-Installation Configuration

After your installation of a read-only domain controller (RODC) is complete, we recommend that

you modify the Domain Name System (DNS) client settings on the server. Before installation of

the RODC, you should have configured the DNS client settings so that the RODC points to a

writeable Windows Server 2008 domain controller as its Preferred DNS server. After the RODC is

installed, the IP version 4 (IPv4) address of 127.0.0.1 and IP version 6 (IPv6) address of ::1 are

inserted as additional DNS servers as the client DNS settings for the RODC. To ensure that the

RODC uses its own DNS records when it resolves queries that originate on the RODC, change

the value of Preferred DNS server to 127.0.0.1 for the IPv4 client DNS settings and ::1 for the

IPv6 client DNS settings on the RODC. You can use Network Connections connection in Control

Panel or the Netsh tool to change the IP address.

Membership in the local Administrators group, or equivalent, is the minimum required to

complete this procedure. Review details about using the appropriate accounts and group

memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To change the Preferred DNS server settings on the RODC using Network Connections

1. Log on to the RODC using an account that is a member of the local built-in Administrators

group.

2. Click Start. In Start Search, type ncpa.cpl, and then press ENTER. The Network

Connections dialog box opens.

3. Right-click the primary network interface ConnectionName (by default, this is named

Local Area Connection) for the RODC, and then click Properties.

4. Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.

5. In Preferred DNS server, type the IP address 127.0.0.1.

6. In Alternate DNS server, type the address of the alternate DNS server that you want to

use, typically, the IP address of the nearest writeable domain controller.

7. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, click OK.

8. Click Internet Protocol Version 6 (TCP/IPv6), and then click Properties.

9. In Preferred DNS server, type ::1. If appropriate, in Alternate DNS server, type the IP

address of an alternate DNS server, and then click OK.

10. In the ConnectionNameProperties dialog box, click Close.

To change the Preferred DNS server settings on the RODC using Netsh

1. Log on to the RODC using an account that is a member of the local built-in Administrators

group.

2. Open a Command Prompt. To open a Command Prompt window, click Start, point to All

Programs, click Accessories, and then click Command Prompt.

3. Use the following command to set the Preferred DNS server IP address:

98


netsh interface ipv4|ipv6 set dnsserver name=”<ConnectionName>“ static 127.0.0.1

For example, for the default connection name Local Area Connection, type netsh

interface ipv4 set dnsserver name=”Local Area Connection” static 127.0.0.1, and

then press ENTER. To set ::1 as the Preferred DNS server for IPv6, type netsh interface

IPv6 set dnsserver “Local Area Connection” static ::1, and then press ENTER.

4. To enter an Alternate DNS server, use the following command:

netsh interface ipv4|ipv6 add dnsserver ”<ConnectionName>“ <IPAddress> Index=2.

For example, if you want to configure an RODC by using the default connection with an

Alternate DNS server IPv4 address of 192.168.0.220, type netsh interface ipv4 add

dnsserver ”Local Area Connection” 192.168.0.220 index=2, and then press ENTER.

To configure fe80::260:97ff:fe02:6e8f as the alternate IPv6 DNS server, type netsh

interface ipv6 add dnsserver ”Local Area Connection” fe80::260:97ff:fe02:6e8f

index=2, and then press ENTER.

a. If you want to add additional DNS servers, you can increment the index number.

For example, to add a third DNS server with an IPv4 address of 192.168.0.221, type

netsh interface ipv4 add dnsserver ”Local Area Connection” static

192.168.0.221 index=3, and then press ENTER.

b. If you want to clear a specific DNS server from the list, you can use the command

netsh interface ipv4|ipv6 delete dnsserver “<ConnectionName>” <IPAddress>.

For example, to remove the IPv4 address 192.168.0.220 from the list of addresses in

the Local Area Connection object, type netsh interface ipv4 delete dnsserver

“Local Area Connection” 192.168.0.200, and then press ENTER.

c. You can clear the entire list of DNS server addresses by using the word all instead of

typing an IP address.

For example, to clear all the IPv4 addresses that are listed as DNS servers for Local

Area Connection, type netsh interface ipv4 delete dnsserver “Local Area

Connection” all, and then press ENTER.

Verify installationAfter you have made final configuration adjustments, ensure that the domain controller is

functioning properly. The quickest way to do this is to use the Dcdiag tool at a command prompt.

At a command prompt, type dcdiag /v, and then press ENTER.

Review the command output for errors. As an alternative, you can use the command

dcdiag /v > dctest.txt to output the diagnostic output to a text file named Dctest.txt. You can

then use a text editor (for example, Notepad) to display the results. For example, run

Notepad dctest.txt to open the file. If Notepad is not installed, you can view the file with the

Type command. For example, to view the contents of the Dctest.txt file, run type dctest.txt |

more, which displays one screen of text at a time from the file in a Command Prompt window.

You can use SPACEBAR to advance through the file.

99

If you do not see any errors logged by Dcdiag, the domain controller should be functioning

properly. If you do see errors, attempt to resolve the issues that you discover and look in the

Event Viewer for additional troubleshooting information.

RODC Administration

This topic describes general administration tasks that you might have to perform for read-only

domain controllers (RODCs). The tasks that are covered in this topic apply to any scenario in

which you plan to use an RODC. For any specific scenario, there might be additional

administration tasks that you have to perform in addition to the general tasks described here.

Using remote management tools to administer an RODCAs a best practice, you should not log on directly to a domain controller to perform any

administration tasks. Instead, install administration tools on a trusted workstation where you

perform your other day-to-day work assignments. Then, use the administration tools to connect to

the domain controller remotely from that workstation.

You can use either of the following tools and technologies for remote RODC management:

Microsoft Remote Server Administration Tools (RSAT)

Windows Remote Management (WinRM) protocol and Windows Remote Shell (WinRS)

Using RSATTo remotely manage Windows Server 2008 domain controllers, you can use the Microsoft

Remote Server Administration Tools for Windows Vista. This tool set is available as a download

file at Microsoft Remote Server Administration Tools for Windows Vista (KB941314)

(http://go.microsoft.com/fwlink/?LinkID=95703). So that you can install RSAT, your workstation

must be running Windows Vista with Service Pack 1 (SP1).

If the workstation is running a 64-bit version of Windows Vista, you can use Microsoft Remote

Server Administration Tools for Windows Vista for x64-based Systems. The 64-bit version is

available at Microsoft Remote Server Administration Tools for Windows Vista for x64-based

Systems (KB941314) (http://go.microsoft.com/fwlink/?LinkId=120123).

You can use RSAT to remotely manage servers running either a Server Core installation or a full

installation of Windows Server 2008.

You can also manage Windows Server 2008 domain controllers from another server that runs

Windows Server 2008. To use a server that runs Windows Server 2008 for remote management,

you have to install the Remote Server Administration Tools because they are not installed by

default. To manage domain controllers, you need to install at least the Active Directory Domain

Controller tools. Depending on what other administration you plan to perform, you might also

choose to install Group Policy Management, Distributed File System (DFS) Management, and

100



Windows Server Backup. For more information, see Installing Remote Server Administration

Tools.

Using WinRM and WinRSYou can use WinRM and WinRS to manage remote servers, including RODCs. WinRM is the

Microsoft implementation of the WS-Management protocol. WinRS is a shell tool that relies on

WinRM to execute remote commands.

WinRM and WinRS are especially well suited for managing an RODC that is deployed in a

perimeter network (also known as a DMZ) because they use TCP port 80, which is a standard

Internet services port that most firewalls leave open. These tools are also well suited for branch

office scenarios because they do not require an administrator to log on to an RODC to remotely

manage it.

To use WinRM, install it on the computer that you use for administration and on the remote server

that you want to manage.

Updates for this guide will include scripts and prescriptive guidance to help you use WinRM and

WinRS. In the meantime, see the following resources for more information:

Windows Remote Management (http://go.microsoft.com/fwlink/?LinkId=120126).

Installation and Configuration for Windows Remote Management


How to enable Windows Remote Shell (http://go.microsoft.com/fwlink/?LinkId=120130).

Hey, Scripting Guy! Desktop Management from beyond the Grave


Delegating local administration of an RODCAdministrator Role Separation (ARS) is an RODC feature that you can use to delegate the ability

to administer an RODC to a user or a security group. When you delegate the ability to log on to

an RODC to a user or a security group, the user or group is not added the Domain Admins group

and therefore does not have additional rights to perform directory service operations.

However, the user or group can perform local administration of the server, including any tasks

that can be performed by a member of the Administrators group on a member server. For

example, a delegated RODC administrator can do the following on the RODC:

Install hardware devices, such as network adapters and disk drives

Manage disk drives and other devices

Install software updates and drivers

Stop and start Active Directory Domain Services (AD DS)

Install and remove other server roles and features

View logs in Event Viewer

Manage shares and other applications and services

101





Note

By default, a delegated RODC administrator cannot make updates to SYSVOL

contents. In addition, any updates that are made to the SYSVOL contents on an

RODC are not replicated to other domain controllers because RODCs do not perform

outbound replication.

Steps and best practices for setting up ARSYou can specify a delegated RODC administrator during an RODC installation or after it.

During the RODC installation, you can set the name of the account in the Active Directory Domain

Services Installation Wizard, at the command line, or in an answer file. In the wizard, set the

name of the account on the Delegation of RODC Installation and Administration page, as

shown in the following figure. If you are performing a staged RODC installation, this page appears

when you precreate an RODC account. For more information about precreating an RODC

account, see see Performing a Staged RODC Installation (http://go.microsoft.com/fwlink/?

LinkID=103323)

102



If you are installing an RODC at the command line or by using an answer file, add the

/DelegatedAdmin parameter to specify the delegated RODC administrator.

To specify the delegated RODC administrator after installation, you can use either of the following

options:

Modify the Managed By tab of the RODC account properties in the Active Directory Users

and Computers snap-in, as shown in the following figure. You can click Change to change

which security principal is the delegated RODC administrator. You can choose only one

security principal. Specify a security group rather than an individual user so you can control

RODC administration permissions most efficiently. This method changes the managedBy

attribute of the computer object that corresponds to the RODC to the SID of the security

principal that you specify. This is the recommended way to specify the delegated RODC

administrator account because the information is stored in AD DS, where it can be centrally

managed by domain administrators.

103

Use the ntdsutil local roles command or the dsmgmt local roles command. You can use

this command to view, add, or remove members from the Administrators group and other

built-in groups on the RODC. For more information about syntax and examples for using this

command, see local roles (http://go.microsoft.com/fwlink/?LinkId=120147).

Using ntdsutil or dsmgmt to specify the delegated RODC administrator account is not

recommended because the information is stored only locally on the RODC. Therefore, when you

use ntdsutil local roles to delegate an administrator for the RODC, the account that you specify

does not appear on the Managed By tab of the RODC account properties. As a result, using the

Active Directory Users and Computers snap-in or a similar tool will not reveal that the RODC has

a delegated administrator.

In addition, if you demote an RODC, any security principal that you specified by using ntdsutil

local roles remains stored in the registry of the server. This can be a security concern if you

demote an RODC in one domain and then promote it to be an RODC again in a different domain.

In that case, the original security principal would have administrative rights on the new RODC in

the different domain.

Use a security group instead of individual user accounts

You can only specify one security principal to be the delegated RODC administrator. As a best

practice, you should create a security group for each RODC and assign that group to be the

delegated administrator. Then, you can add individual user accounts to the group, and each user

can manage the RODC.

Using a security group helps you manage administrative permissions on the RODC more

effectively and helps you avoid logging on to the RODC by using privileged account.

For example, suppose that you have two RODCs named RODC1 and RODC2, as shown in the

following table.

Server name RODC1 RODC2

Managed by RODC1Mgrs RODC2Mgrs

Members StanB (the name of a user

account in this branch)

KarenC (the name of another

user account in this branch)

PeterH (the name of a user

account in this branch)

DavidK (the name of another

user account in this branch)

In this example, RODC1Mgrs and RODC2Mgrs are the respective security groups that are the

delegated administrators for each RODC. The membership of each group is comprised of the

appropriate user accounts from the respective branch office.

Typically, a domain administrator can manage an RODC remotely without logging on to the

RODC directly. In the rare case that a domain administrator must log on to an RODC, the

administrator should create a temporary domain user account just for that purpose and add it to

the delegated RODC administrator group account. The administrator can log on to an RODC

104


using that domain user account instead of a domain administrator account and eventually delete

the temporary account afterward for improved security.

Restrict logon with a privileged account in a site that has an RODC

Because you will deploy RODCs in locations where they might be compromised, you should

manage them in the same way as you manage other potentially nonsecure computers. Always

treat an RODC as though it is not secure. You should never log on to it—locally or remotely with

Terminal Services, by using highly privileged credentials—such as Domain Admins or Enterprise

Admins.

An attacker can use a compromised RODC that has a highly privileged account password to

perform malicious operations in the forest. Even use of a smart card cannot mitigate the logon

risk because a compromised RODC would have access to the security context and could use it

maliciously.

It is not necessary for a compromised RODC to have cached the password of a privileged

account to use that account maliciously. In addition, you do not want an administrative

workstation to be authenticated by an RODC that you do not trust. Although you cannot control

which domain controller authenticates the administrative workstation, RODCs do not register

service (SRV) resource records for other sites. As a result, RODCs do not authenticate

workstations from other sites. If the administrative workstation that you log on to is not in a site

with an RODC, it cannot be authenticated by an RODC. Therefore, as a best practice, you should

not log on to any workstation with a privileged account in any site that has an RODC—or log on to

an RODC locally—unless you fully trust the RODC.

Cache the password for the delegated RODC administrator

So that the delegated RODC administrator can log on to the RODC when the wide area network

(WAN) link to the hub site domain controller is not available, the delegated RODC administrator

account password must be cached on the RODC. Note that the delegated RODC administrator

account is not allowed to be cached on an RODC by default. Therefore, you have to modify the

default PRP to allow the password to be cached, cache the password, and the recache it after

every password change for successful logon to the RODC when the WAN is not available or a

writable domain controller cannot be contacted. You must do this for every member of the security

group that you specify as an administrator of the RODC.

Managing passwords and the PRPDepending on your security and service availability requirements for your RODC site, you may

want to change the default PRP. The PRP acts as an access control list (ACL). It determines

whether an RODC is permitted to cache a password.

After the RODC receives an authenticated user or computer logon request, if it does not have the

credentials cached locally, it forwards the logon request to a writable Windows Server 2008

domain controller. The writable domain controller refers to the PRP to determine whether the

105

password for the account should be cached on the RODC. For more information about how the

PRP works, see Credential caching.

You can change the PRP by modifying attributes of an RODC. For more information about

changing the PRP, see Administering the Password Replication Policy.

Default PRPBy default, all RODCs have the same Password Replication Policy (PRP). The default PRP

specifies that no account passwords can be cached on any RODC, and certain accounts are

explicitly denied from being cached on any RODC.

The RODC PRP is determined by two multivalued Active Directory attributes that contain security

principals (users, computers, and groups):

msDS-Reveal-OnDemandGroup, also commonly known as the Allowed List

msDS-NeverRevealGroup, also commonly known as the Denied List

The msDS-Reveal-OnDemandGroup attribute specifies what security principals can have

passwords cached on an RODC. By default, this attribute has one value, which is the Allowed

RODC Password Replication Group. Because this domain local group has no members by

default, no account passwords can be cached on any RODC by default.

The msDS-NeverRevealGroup attribute specifies what security principals are explicitly denied

from having their passwords cached on an RODC. By default, this attribute has the following

values:

Account Operators

Server Operators

Backup Operators

Administrators

Denied RODC Password Replication Group, which is a domain local group that includes the

following:

Enterprise Domain Controllers

Enterprise Read-Only Domain Controllers

Group Policy Creator Owners

Domain Admins

Cert Publishers

Enterprise Admins

Schema Admins

Domain-wide krbtgt account

Modifying the PRPBy using a combination of the Allowed List and the Denied List for each RODC with the domain-

wide password replication groups, you have great flexibility to decide precisely which accounts

106

can be cached on specific RODCs. The following table describes three examples of ways that

you might administer the PRP to manage how passwords are cached on the RODCs that you

deploy. You can customize any of these examples to best suit your needs.

Example Pros Cons

No accounts are cached

(default)

Most secure—users are

authenticated by a writable

domain controller, and they get

their Group Policy from the

RODC for fast policy

processing.

No offline access for anyone—a

WAN is required for logon.

Most accounts are cached Ease of password management

—this option is intended for

customers who care most about

the manageability

improvements of RODC, and

not security.

More passwords are potentially

exposed to an RODC.

Few accounts are cached Enables offline access for those

users who need it, but provides

more security than caching

most accounts.

This method requires more

detailed administration. You

may have to map user and

computers to each branch that

has an RODC. You may also

use tools such as repadmin

/prp to move accounts that

have authenticated to an RODC

to a group that is in the Allowed

List or use Identity Lifecycle

Manager (ILM) to automate that

process.

The following sections explain each example in more detail.

No accounts are cachedThis example provides the most secure option. No passwords are replicated to the RODC, except

for the RODC computer account and its special krbtgt account. However, user and computer

authentication relies on WAN availability. This example has the advantage of requiring little or no

additional administrative configuration from the default settings.

You might choose to add your own security-sensitive user groups to the Denied List. Although no

accounts are cached by default, adding your own security-sensitive user groups to the

Denied List can protect those groups against accidental inclusion in the Allowed List, along with

subsequent caching of their passwords on the RODC.

107

Note that the delegated RODC administrator account is not automatically added to the

Allowed List. As a best practice, add the delegated RODC administrator account to the

Allowed List to ensure that a delegated administrator can always log on to the RODC, regardless

of whether the WAN connection to a writable domain controller is available. For more information,

see Cache the password for the delegated RODC administrator.

Most accounts are cachedThis example is the simplest administrative mode, and it removes the dependency on WAN

availability for user and computer authentication. In this example, you populate the Allowed List

for all RODCs with groups that represent a significant portion of the user and computer

population. The Denied List does not allow security-sensitive user groups, such as Domain

Admins, from having passwords cached. Most other users, however, can have their passwords

cached on demand. You might choose to add your own security-sensitive user groups to the

Denied List.

This configuration is most appropriate in environments where the physical security of the RODC

will not be at risk. For example, you might configure the PRP this way for an RODC that you have

deployed in a secure location primarily to take advantage of its reduced replication and

administration requirements.

Important

You must also add the users' computer accounts to the Allowed list so that those users

can log on at the branch office when the WAN is offline.

Few accounts are cachedThis example restricts the accounts that can be cached. Typically, you define this distinctly for

each RODC—each RODC has a different set of user and computer accounts that it is permitted

to cache. This example is usually for a set of users who work at a particular physical location.

The advantage of this example is that a set of users will be able to log on to the network and be

authenticated by the RODC in the branch office if the WAN is offline. At the same time, the scope

of exposure for passwords is limited by the reduced number of users whose passwords can be

cached.

There is administrative overhead associated with populating the Allowed List and the Denied List

in this example. There is no default automated method for reading accounts from the known list of

security principals who have authenticated against a given RODC, and there is no default method

for populating the Allowed List with those accounts. You can use the repadmin /prp move

command to move these accounts to a group that is in the Allowed List, or you can use scripts or

applications such as ILM to build a process.

Although you can add user or computer accounts directly to the Allowed List, you should instead

create a security group for each RODC, add it to the Allowed List and then add user and

computer accounts to the security group. This way, you can use standard group management

108

tools such as the Active Directory Users and Computers snap-in or the Dsadd or Dsmod

command-line tools to manage which accounts can be cached on the RODC.

The repadmin /prp move command requires that you specify a security group. If the security

group that you specify does not exist, it creates the group and adds it to the Allowed list. For more

information about using repadmin /prp move, see Moving accounts from the Auth2 list to the

Allow list.

As with the previous example, you must also add appropriate computer accounts to the

Allowed List.

Additional tasks and tools for managing passwordsYou can perform the following additional tasks as necessary to manage passwords for an RODC.

Prepopulate the password cache for an RODC

After you initially deploy an RODC, you may want to prepopulate its password cache with the

passwords for user and computer accounts that you want to be able to authenticate to the RODC

when the WAN is offline. Remember that, by default, the credentials of the accounts whose

passwords are allowed to be cached are not replicated to the RODC until the user or computer

authenticates against the RODC. Therefore, if the WAN is not available, these users and

computers will not be able to authenticate unless you prepopulate the password cache. If you

prepopulate the password cache of an RODC with those accounts, the RODC does not rely on

WAN availability to authenticate them.

For example, suppose that you are installing an RODC in a branch office, and you want the users

and computers in that branch office to authenticate to the RODC when the WAN is offline. If you

only add the accounts to the Allowed List, the passwords for those users and computers will be

cached by the RODC as those users attempt to log on. If the WAN is not available when one of

those users first attempts to log on, the authentication request for that user will fail.

By prepopulating the password cache right after the RODC installation, you can ensure that the

passwords for all users and computers in the branch are cached, regardless of when they first

attempt to log on.

You can use Active Directory Users and Computers or repadmin /rodcpwdrepl to prepopulate

the password cache. The WAN link between the RODC and its replication partner must be

available when you perform this task. You cannot prepopulate the password cache during RODC

installation. For more information, see Populate the password cache for an RODC.

View current credentials that are stored on an RODC

You can view whose passwords are stored on an RODC. This can help if you want to reset those

passwords if the RODC is stolen. This can also help you determine if you need to cache an

account that is not yet cached. For example, you can ensure that the delegated RODC

109

administrator account password is cached on an RODC. For more information, see Reviewing

Accounts with Cached Passwords on the RODC.

Review whose accounts have been authenticated to an RODC

Periodically, you should review whose accounts have been authenticated to an RODC. This

information can help you plan updates that you intend to make to the existing PRP. For example,

you can look at which user and computer accounts have authenticated to an RODC so that you

can add some of those accounts to the Allowed List so that they can be authenticated by the

RODC when the WAN is offline.

You can use Active Directory Users and Computers or repadmin /prp to review whose accounts

have been authenticated to an RODC. For more information, see Reviewing Accounts

Authenticated to RODC.

Clear cached passwords that are cached on an RODC if it is stolen

There is no mechanism to erase passwords after they are cached on an RODC. If you want to

clear a password that is stored on an RODC, reset the password in the hub site. This way, the

password that is cached in the branch will no longer be valid for accessing any resources in the

hub site or other branches. In the site that contains the RODC on which the password may have

been compromised, the password will still be valid for authentication purposes until the next

replication cycle, at which time its value that is stored on the RODC will be updated. The new

password will be cached only after the user authenticates with it—or the new password is

prepopulated on the RODC—and if the PRP has not been changed. Simply removing a user or

computer from the Allowed List will not securely ensure that the password cannot be tampered

with in case the RODC gets compromised. In the event that an RODC is compromised, reset the

passwords for all accounts that have cached passwords and then rebuild the RODC.

You can use Active Directory Users and Computers to delete the account for an RODC that has

been stolen. To delete the account, right-click the name of the RODC account in the Domain

Controllers organizational unit (OU), and then click Delete. After you confirm that you want to

delete the RODC account, you can choose to reset the passwords that are cached on it, as

shown in the following figure. As an option, you can also select the Export the list of accounts

that were cached on this read-only domain controller to this file check box to create a list of

user accounts whose passwords must be reset after the RODC account is deleted. That list of

accounts is not available after the RODC account is deleted.

110

You can also use the repadmin /prp command to delete the security principals from the msDS-

AuthenticatedToAccountList attribute or from the msDS-RevealOnDemandGroup attribute

that is associated with the RODC. Note however, that this action only clears the value from the

attribute; it does not clear the cache on the RODC.

Adding attributes to the RODC filtered attribute setThis section explains how to add an attribute to the RODC filtered attribute set (FAS), and then

mark the attribute as confidential. For an example, see Adding Attributes to the RODC Filtered

Attribute Set. The example shows how to use the Ldifde command-line tool to add an attribute

Contoso-App-Password from the Active Directory schema. This attribute is just an example of a

possible secret-like attribute that you can add to a default schema. .

As a best practice, make sure that the forest functional level is Windows Server 2008 if you plan

to configure the RODC FAS. You can be assured that the RODC FAS is not replicated to RODCs

only if the forest functional level is Windows Server 2008. This is because a compromised RODC

can attempt to replicate attributes from the RODC FAS from a Windows Server 2003 domain

controller, which cannot prevent replication from happening. However, by default, RODCs

replicate only with Windows Server 2008 writable domain controllers, which ensures that

attributes in the FAS will not get replicated. If an RODC is stolen without being compromised first,

it will not contain any of the attributes in the FAS.

111

You cannot add system-critical attributes to the RODC FAS. An attribute is system critical if it is

required for AD DS, Local Security Authority (LSA), Security Accounts Manager (SAM), and any

of Microsoft-specific Security Service Providers, such as the Kerberos authentication protocol, to

function properly. A system-critical attribute has a schemaFlagsEx attribute value of

(schemaFlagsEx attribute value & 0x1 = TRUE).

Make sure that the domain controller that holds the schema operations master (also known as

flexible single master operations or FSMO) role is running Windows Server 2008 when you add

attributes to the RODC FAS so that the attributes are verified to not be system critical. If you try to

add a system-critical attribute to the RODC FAS while the schema master is running Windows

Server 2008, the server returns a Lightweight Directory Access Protocol (LDAP) error

"unwillingToPerform" (0x35). The Windows Server 2003 operating system does not use the

RODC FAS. If you try to add a system-critical attribute to the RODC FAS while the schema

master is running Windows Server 2003, the operation will appear to succeed but the attribute will

not actually be added to the set.

To mark an attribute as confidential, you have to remove the Read permission for the attribute for

the Authenticated Users group. Before you mark an attribute as confidential, thoroughly test the

effect that it might have on your applications. For more information about marking attributes as

confidential, see article 922836 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?

LinkID=99814).

If you are certain that you need to add an attribute to the FAS, there is some benefit to adding it

before you install the first RODC in the forest. This way, the attribute never appears on any

RODC at any point in time. However, you can also add any attribute to the FAS after you install

RODCs. AD DS will then dynamically remove that attribute from all RODCs in the forest.

Default RODC FASThe following attributes are configured as part of the RODC FAS. They are marked as

confidential by default to support Credential Roaming and BitLocker Drive Encryption in Windows

Server 2008:

ms-PKI-DPAPIMasterKeys

ms-PKI-AccountCredentials

ms-PKI-RoamingTimeStamp

ms-FVE-KeyPackage

ms-FVE-RecoveryGuid

ms-FVE-RecoveryInformation

ms-FVE-RecoveryPassword

ms-FVE-VolumeGuid

ms-TPM-OwnerInformation

112



Installing Remote Server Administration Tools

This section describes how to install the Active Directory Domain Services Tools that are part of

the Remote Server Administration Tools (RSAT). These tools are required to fully manage a

Windows Server 2008 domain controller from a non-domain-controller computer. You can install

these tools on a Windows Server 2008 member server or a Windows Vista with SP1 member

workstation. You can install different types of tools to manage different types of server roles. As a

best practice, you should install tools only for the server roles that you plan to manage remotely.

This procedure explains how to install the Active Directory Domain Services Tools so you can

remotely manage domain controllers.

Membership in the built-in Administrators group, group, or equivalent, is the minimum required

to complete these procedures. Review details about using the appropriate accounts and group

memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To install Active Directory Domain Services Tools on a server that runs Windows Server 2008

1. Click Start, and then double-click Server Manager.

2. If the User Account Control dialog box appears, confirm that the action it displays is

what you want, and then click Continue. If you are logged on with an account that is not

a member of the built-in Administrators group, you may be required to provide

administrator credentials and then click OK.

3. Under Features Summary, click Add Features.

4. Double-click Remote Server Administration Tools, double-click Role Administration

Tools, double-click Active Directory Domain Services Tools, and then click Next.

5. Click Install.

Restart the server to complete the installation.

To install Active Directory Domain Services Tools on a Windows Vista SP1 domain member computer

1. You must be running at least Windows Vista with SP1 on the member workstation. You

can then download the RSAT tools from the Microsoft Web site. For download information

and installation information, see article 941314 in the Microsoft Knowledge Base


Important

If the Windows Server 2003 Administration Tools are installed, you must uninstall

them before installing RSAT.

2. After you have downloaded and installed the appropriate RSAT package for your platform

from the Microsoft Web site, click Start, click Control Panel, click Programs, and then

113



click Turn Windows features on or off.


what you want, and then click Continue. If you are logged on with an account that is not

a member of the built-in Administrators group, you may be required to provide

administrator credentials, and then click OK.

4. Expand the following: Remote Server Administration Tools, Role Administration

Tools, and Active Directory Domain Services Tools.

5. Select Active Directory Domain Controller Tools, as shown in the following figure.

Selecting the Active Directory Domain Controller Tools

6. Click OK.

Displaying Administrative ToolsIf you installed RSAT on Windows Vista with SP1 and you want to access the tools from the Start

menu, you may have to configure the computer to display the tools.

To configure the Start menu to display the Administrative Tools shortcut

1. Right-click Start, and then click Properties.

2. On the Start Menu tab, click Customize.

3. In the Customize Start Menu dialog box, scroll down to System administrative tools,

114

and then click Display on the All Programs menu and the Start menu.

4. Click OK.

The Administrative Tools shortcut on the Start menu will have links to the graphical

administration tools for Active Directory Domain Services (AD DS). The command line

tools, such as Dsquery and Repadmin, will also be available at a Command Prompt.

Administering the Password Replication Policy

This topic describes the steps for viewing, configuring, and monitoring the Password Replication

Policy (PRP) and password caching for read-only domain controllers (RODCs).

Viewing the PRPYou can view the PRP in a graphical user interface (GUI) by using the Active Directory Users and

Computers snap-in or in a Command Prompt window by using the Repadmin tool. The following

procedures describe how to view the PRP.

Note

You can perform the following procedures on any Windows Server 2008 domain

controller or any computer in the forest or a trusted forest that has the Active Directory

Domain Controller Tools from the Remote Server Administration Tools (RSAT) installed.

For more information about RSAT, see RODC Administration.

Any domain user can view the PRP.

Note

If you are managing an Active Directory domain from a different forest, security identifier

(SID) filter quarantining must be configured to allow for external administrative

authentication, which may not be desirable from a security standpoint. In addition, if

selective authentication is enabled, the domain controller that is targeted for management

must be allowed for authentication.

To view the PRP using Active Directory Users and Computers

1. Open Active Directory Users and Computers. To open Active Directory Users and

Computers, click Start. In Start Search, type dsa.msc, and then press ENTER.

2. Ensure that you are connected to the correct domain. To connect to the appropriate

domain, in the details pane, right-click the Active Directory Users and Computers object,

and then click Change Domain.

3. Expand Domain Controllers, right-click the RODC account object for which you want to

115

modify the PRP, and then click Properties.

4. Click the Password Replication Policy tab. An example is shown in the following

illustration.

RODC PRP

To view the PRP using Repadmin

1. Open a Command Prompt window. To open a Command Prompt window, click Start,

point to All Programs, click Accessories, and then click Command Prompt.

2. To view the accounts that are configured in the PRP, use the command repadmin /prp

view <hostname> allow|deny. Substitute the actual host name or fully qualified domain

name (FQDN) of the appropriate RODC for hostname in the command, and then type

either allow or deny to the see the accounts that are allowed or not allowed to have their

passwords cached on the RODC, respectively. The following examples show how to view

116

the accounts that are configured in the PRP that applies to an RODC with host name

RODC2 in the domain hq.cpandl.com:

a. To view the accounts that are allowed to have their passwords cached on the RODC,

type repadmin /prp view rodc2.hq.cpandl.com allow, and then press ENTER.

b. To view the accounts that are denied from having their passwords cached on the

RODC (also known as the Deny list), type repadmin /prp view rodc2.hq.cpandl.com

deny, and then press ENTER.

Note

For more information, see Repadmin /prp (http://go.microsoft.com/fwlink/?

LinkId=120184).

Reviewing the accounts that are authenticated to an RODCYou should periodically review the accounts that have been authenticated to an RODC. This

information can help you plan updates that you intend to make to the existing PRP. For example,

you may want to review which user and computer accounts have authenticated to an RODC so

that you can add those accounts to the Allowed List.

Important

You will probably see more accounts in the Accounts that have been authenticated to

this Read-only Domain Controller list than will have passwords cached. Although you

may see accounts of writeable domain controllers or members of the Domain Admins

group in the list of authenticated accounts, it does not necessarily indicate that those

accounts authenticated to the domain through the RODC. Instead, it means that the

RODC in one way or another verified the credentials of those accounts. All default

administrative accounts and domain controllers are denied explicitly or through their

membership from having their passwords cached. If there are additional accounts that

you want to make sure are not cached, include them in the Deny list or make them

members of the Denied RODC Password Replication Group. The Deny list comprises of

the accounts that are specifically denied in the PRP from caching their credentials on the

RODC.

Caution

When you view and access the PRP through Active Directory Users and Computers, be

sure to target the console to a Windows Server 2008 writeable domain controller.

Changes and tracking information are updated first on the writeable domain controller

and then replicated to the RODC.

Any domain user can view accounts that have authenticated to the RODC.

To view authenticated accounts using Active Directory Users and Computers

117



1. Open Active Directory Users and Computers. To open Active Directory Users and


2. Ensure that you are connected to a writeable domain controller running Windows

Server 2008 in the correct domain. To connect to the appropriate domain or domain

controller, in the details pane, right-click the Active Directory Users and Computers

object, and then click Change Domain or Change Domain Controller, respectively.

3. Click Domain Controllers.

4. In the details pane, right-click the RODC computer account, and then click Properties.

5. Click the Password Replication Policy tab.

6. Click Advanced.

7. In the drop-down list, click Accounts that have been authenticated to this Read-only

Domain Controller, as shown in the following illustration.

Accounts that are authenticated to the RODC

To view the authenticated accounts using Repadmin

118



2. Run the command repadmin /prp view <hostname> auth2. Substitute the actual host

name of the RODC that you want to query. For example, if you want to review the list of

authenticated accounts for RODC2 in the hq.cpandl.com domain, type repadmin /prp

view rodc2.hq.cpandl.com auth2, and then press ENTER.

Clearing the authenticated accounts listIn addition to reviewing the list of authenticated users, you may decide to periodically clean up the

list of accounts that are authenticated to the RODC. Cleaning up this list may help you more

easily determine the new accounts that have authenticated through the RODC.

Membership in the Domain Admins group of the domain in which the RODC is a member, or

equivalent, is the minimum required to complete this procedure. Review details about using the

appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To clear the authenticated accounts list

1. Open an elevated Command Prompt window using the credentials of a Domain Admin.

To do this, click Start. In Start Search, type runas /user:<domainName>\

<domainAdminAccountUser> cmd, and then press ENTER. Replace <domainName> with the

domain name, and replace <domainAdminUser> with the name of a user account that is a

member of the Domain Admins group in that domain.

2. To clear all entries from the list, run the command repadmin /prp delete <hostname>

auth2 /all. Substitute the actual host name of the RODC that you want to clear. For

example, if you want to clear the list of authenticated accounts for RODC2, type repadmin

/prp delete rodc2 auth2 /all, and then press ENTER.

Configuring the PRPYou can configure the PRP in the GUI by using the Active Directory Users and Computers snap-in

or from a Command Prompt window by using the repadmin command. You can use the following

procedures to configure the PRP.

Important

Although there is a default security group named Allowed RODC Password Replication

Group, by default this group grants its members the ability to cache passwords on any

RODC in the domain. As a security best practice, you should create separate security

groups for each RODC to allow the caching of passwords on only that RODC and then

prepopulate the groups with the appropriate accounts.

Membership in the Domain Admins group of the domain in which the RODC is a member, or

equivalent, is the minimum required to configure the PRP for an RODC.

119


To configure the PRP using Active Directory Users and Computers

1. Open Active Directory Users and Computers as a member of the Domain Admins group.

To open Active Directory Users and Computers as a member the of Domain Admins

group, click Start. In Start Search, type runas /user:<domain>\<username>, and then

press ENTER. Substitute the actual domain name for <domain>, and type the name of a

user account that is a member of the Domain Admins group for <username>. Enter the

account password when you are prompted. Type dsa.msc, and then press ENTER.

Close the Command Prompt window.

Ensure that you are connected to a writeable domain controller running Windows



object, and then click Change Domain or Change Domain Controller, respectively.

2. Click Domain Controllers, and in the details pane, right-click the RODC computer

account, and then click Properties.


4. The Password Replication Policy tab lists the accounts that, by default, are defined in

the Allowed List and the Deny list on the RODC. To add other groups that should be

included in either the Allow list or the Deny list, click Add.

c. To add other accounts that will have credentials cached on the RODC, click Allow

passwords for the account to replicate to this RODC.

d. To add other accounts that are not allowed to have credentials cached on the RODC,

click Deny passwords for the account from replicating to this RODC.

Note

Accounts that are denied from caching credentials on the RODC can still use

the RODC for domain logon, but the RODC will contact another domain

controller to verify the account logon credentials and it will not cache those

credentials for subsequent logons.

1. Click OK.

2. In the Select Users, Computers, or Groups dialog box, under Enter the object names

to select, type the account name that you want to add, click Check Names to resolve

the account name, and then click OK. You can enter multiple account names at the same

time by separating them with a semicolon.

Note

You may experience some latency between authorizing a user to cache their

password and the user actually being allowed to cache the password. You can

reduce the latency by purging the Kerberos ticket cache on the domain controller

that you are modifying. To purge the ticket cache, run the command klist -li 3e7

purge from an elevated command prompt on the writeable domain controller.

However, running this command will purge all Kerberos tickets that are issued to

the local system and may temporarily interrupt other services that are running on

120

the writeable domain controller.

To configure the PRP using Repadmin


To open an elevated Command Prompt window using the credentials of a Domain Admin,

click Start. In Start Search, type runas /user:<domainName>\

<domainAdminAccountUser> cmd, and then press ENTER. Replace <domainName>

with the domain name, and replace <domainAdminUser> with the name of a user

account that is a member of the Domain Admins group in that domain.

2. Run the command repadmin /prp add|delete <hostname> allow|deny <AccountLdapPath>.

Replace <hostname> with the actual host name of the applicable RODC, and then type the

Lightweight Directory Access Protocol (LDAP) path to the account that you want to

include for <AccountLdapPath>. For example, if you want to configure an account named

RODC2users from a top-level organizational unit (OU) named West in the domain

hq.cpandl.com to the PRP for the RODC computer with a hostname of RODC2, use one

of the following commands:

Note

To find the LDAP distinguished name of a directory object from the command

line, you can use the dsquery command. For example, if you want to find the

distinguished name of a group that has “RODC” as part of its name from a

computer in the local domain, you can run the command dsquery group –name

*RODC*. The asterisks around “RODC” indicate that any number of characters

can come before or after the letters RODC. If instead you want to find the

distinguished name of a computer or user, substitute either the word computer

or the word user (respectively) for the word group in the command. For more

information about dsquery command syntax, see Dsquery


e. To allow the account RODC2users to be cached on RODC2, run the command

repadmin /prp add rodc2.hq.cpandl.com allow

cn=RODC2users,ou=west,dc=hq,dc=cpandl,dc=com.

f. To remove the account from the Allowed List, run the command repadmin /prp

delete rodc2.hq.cpandl.com allow cn=RODC2users,ou=west,dc=hq,dc=cpandl,dc=com.

g. To prevent the account from being cached, run the command repadmin /prp add

rodc2.hq.cpandl.com deny cn= RODC2users,ou=west,dc=hq,dc=cpandl,dc=com.

h. To remove the account from the Deny list, run the command repadmin /prp delete

rodc2.hq.cpandl.com deny cn=RODC2users,ou=west,dc=hq,dc=cpandl,dc=com.

121


Moving accounts from the Auth2 list to the Allow listThe Repadmin tool has one capability that the Active Directory Users and Computers snap-in

does not have when it comes to allowing accounts to cache passwords. You can use a single

repadmin command to create a security group that allows members to cache passwords and

prepopulate that group with accounts from the list of accounts that were authenticated by the

RODC (also known as the Auth2 list). If you have already created a security group that is used to

allow accounts to cache their passwords, you can specify that group as the group to which the

accounts will be added. If you have not created a security group, a new group will be created for

that purpose in the default Users container of the domain in which the RODC is a member. You

can use the following procedure to use the repadmin /prp move command to move accounts

from the Auth2 to the Allow list. The Allow list comprises the accounts that have been given the

Allow permission in the PRP to cache their credentials on the RODC.

Note

When you use the repadmin /prp move command to copy accounts from the Auth2 list

to the Allow list on the RODC, all accounts in the Auth2 list are moved (you cannot select

individual accounts). The Allow list is the list of accounts that are specifically granted

Allow permissions to cache their credentials on the RODC. Accounts that are specifically

denied (either directly or through group membership) from having their passwords

cached will not be copied from the Auth2 list to the Allow list.

Membership in Domain Admins, or equivalent, is the minimum required to complete this

procedure. Review details about using the appropriate accounts and group memberships at


To move accounts from the Auth2 list to the Allow list using Repadmin



click Start. In Start Search, type runas /user: <domainName>\




2. Run the command repadmin /prp move<hostname> <GroupName>. Substitute the actual

name of the RODC for <hostname> and the actual name of the security group for

<GroupName>. If you do not want to clear the list of accounts that have authenticated to the

RODC, include the /noauth2cleanup command. You can also specify that only user

accounts or only computer accounts be transferred by using the /users_only or

/comps_only parameters, respectively.

For example, to move the current list of only the users from RODC2 to the Allowed Lit,

type Repadmin /prp move rodc2 /users_only.

122


Note

You cannot selectively move entries from the Auth2 list to the Allow list using the

repadmin /prp move command. However, when you have created an appropriate group,

you can use Active Directory Users and Computers, Dsadd, and similar tools to add

users or computers to that group.

Reviewing PRP resultant policyYou can use the Resultant Policy tab in the Advanced Password Replication Policy dialog

box for an RODC to determine whether certain accounts are allowed to cache their passwords or

not. This can be useful if you want to make sure that certain accounts, which should be able to

authenticate by using an RODC when a connection to a writeable domain controller is not

available, are cacheable on the RODC. You can also use this feature to make sure that sensitive

accounts, which should not be cached on the RODC, are not cacheable.

Membership in Domain Admins, or equivalent, is the minimum required to complete this

procedure. Review details about using the appropriate accounts and group memberships at


To determine whether an account is allowed to cache its password

1. Open Active Directory Users and Computers as a member of Domain Admins. To Open

Active Directory Users and Computers as a member of Domain Admins, click Start. In

Start Search, type runas /user:<domain>\<username>, and then press ENTER.

Substitute the actual domain name for <domain>, and then type the name of a user

account that is a member of the Domain Admins group for <username>. Type the

account password when you are prompted. Type dsa.msc, and then press ENTER.

Close the Command Prompt window.



and then click Change Domain..




6. Click Advanced.

7. Click the Resultant Policy tab.

8. Click Add.

9. In the Select Users or Computers dialog box, under Enter the object names to select,

type the account name that you want to add, click Check Names to resolve the account

name, and then click OK. To enter multiple account names at the same time, separate

the account names with semicolons.

123


Reviewing accounts with cached passwords on the RODCIn addition to periodically reviewing the accounts that have been authenticated to the RODC, you

should also check the accounts that have passwords cached on the RODC. Verify that only the

appropriate account passwords are cached. You can use Active Directory Users and Computer or

Repadmin to perform this task.

Important

When a network connection to a writeable domain controller is not available, a user is

able to log on through an RODC only if the passwords of both the user account and the

computer account (of the workstation that the user is accessing) are cached on the

RODC.

Any domain user can view the accounts with cached passwords.

Note

If you find an account with a cached password that should not be in the list, ensure that

the account is added to the Deny list and then change the account’s password. You may

also want to further investigate the situation to determine whether additional security

issues occurred.

To view accounts that have cached passwords on an RODC using Active Directory Users and Computers

1. Open Active Directory Users and Computers. To Open Active Directory Users and




and then click Change Domain..




6. Click Advanced.

7. In the drop-down list, click Accounts whose passwords are stored on this Read-only

Domain Controller, as shown in the following illustration.

Accounts that are cached on the RODC

124

To view accounts with cached passwords on an RODC using Repadmin



2. Run the command repadmin /prp view <hostname> reveal. Insert the actual host name of

the RODC for <hostname>. For example, to see the accounts with cached passwords on

an RODC with the host name RODC2 in the domain contoso.com, type repadmin /prp

view rodc2.contoso.com reveal.

Important

If you have a large number of accounts cached, the repadmin /prp view

<hostname> reveal command might return only a subset of the accounts. For

more information, see Repadmin /PRP might return only a subset of accounts.

125

Prepopulating the password cache for an RODCYou can prepopulate the password cache for an RODC with the passwords of user and computer

accounts that you plan to authenticate to the RODC. To prepopulate the password cache of the

RODC is to submit entries into the password cache by using the Prepopulate button, as opposed

to waiting for the password cache to be populated automatically as users log on. When you

prepopulate the RODC password cache, the RODC replicates and caches the passwords for

users and computers before their accounts attempt to log on to the computers that are

authenticated by the RODC.

Prepopulating the password cache helps ensure that a user can log on to the network using the

RODC, even when a link to a writeable domain controller is not available. For example, suppose

that a user who used to work in a data center transfers to a branch office with his computer. The

RODC contacts the writable domain controller in the data center. If the PRP allows it, the RODC

caches the password. However, if the wide area network (WAN) link is offline when the user

attempts to log on, the logon attempt fails because the RODC has not cached the password for

the account.

To avoid this problem, you can prepopulate the password cache of the RODC in the branch office

with the password of the user and his computer. This makes it unnecessary for the RODC to

replicate the password from the writeable Windows Server 2008 domain controller over the WAN

link.

In addition, prepopulating the password cache is a good idea if you build an RODC in a central

location—for example, in a data center—before you transport the RODC to the branch office.

When you prepopulate the password cache with the users and computers who will log on in the

branch office, the RODC can authenticate those accounts without contacting a writeable

Windows Server 2008 domain controller over the WAN link.

You can prepopulate the password cache for an RODC by using the Active Directory Users and

Computers snap-in or by using the Repadmin command-line tool.

Note

You can prepopulate the cache only for accounts that the PRP allows to be cached. If you

try to prepopulate a password of an account that the PRP does not allow to be cached,

the operation fails. Also, there can be latency between the RODC and the writeable

domain controller after PRP permission changes are implemented. If you recently

allowed an account permission to cache its password on an RODC, you may not

immediately be able to prepopulate the password cache. You can reduce the latency by

purging the Kerberos ticket cache on the domain controller that you are modifying. To

purge the ticket cache, run the command klist -li 3e7 purge from an elevated Command

Prompt on the writeable domain controller. However, running this command will purge all

Kerberos tickets that are issued to the local system and may temporarily interrupt other

services that are running on the writeable domain controller.

Membership in Domain Admins, or equivalent, is the minimum required to complete these

procedures. Review details about using the appropriate accounts and group memberships at


126


To prepopulate the password cache for an RODC by using Active Directory Users and Computers

1. Open Active Directory Users and Computers as a member of Domain Admins. To open

Active Directory Users and Computers as a member of Domain Admins, click Start. In

Start Search, type runas /user:<domain>\<username>, and then press ENTER.

Substitute the actual domain name for <domain>, and type the name of a user account

that is a member of the Domain Admins group for <username>. Type the account

password when you are prompted. Type dsa.msc, and then press ENTER. Close the

Command Prompt window.

2. Ensure that you are connected to a writeable domain controller running Windows



object, and then click Change Domain or Change Domain Controller, respectively..





7. Click Advanced.

8. Click Prepopulate Passwords.

9. Type the name of the accounts whose passwords you want to prepopulate in the cache

for the RODC, and then click OK.

10. When you are asked if you want to send the passwords for the accounts to the RODC,

click Yes.

To prepopulate the password cache for an RODC by using Repadmin



click Start. In Start Search, type runas /user: <domainName>\




2. Run the command

Repadmin /rodcpwdrepl <hostnameRODC> <hostnameWDC> <User1LdapPath>

<Computer1LdapPath> <User2LdapPath> <Computer2LdapPath>, where:

i. <hostnameRODC> is the host name or fully qualified domain name (FQDN) of the target

RODC’s password cache that you want to prepopulate. If you are running the

command from outside the target domain, use the FQDN.

j. <User1LdapPath> is the LDAP distinguished name of the first user account password

that you want to prepopulate.

k. <Computer1LdapPath> is the LDAP distinguished name of the first computer account

127

password that you want to populate. You must add the computer accounts of the

users or they will not be able to log on.

l. <User2LdapPath> is the LDAP distinguished name of the second user account

password that you want to populate.

m. <Computer2LdapPath> is the LDAP distinguished name of the second computer

account password that you want to prepopulate. You must add the computer

accounts of the users or they will not be able to log on.

n. <hostnameWDC> is the host name or FQDN of the writable Windows Server 2008

domain controller that is the replication partner of the RODC. If you are running the

command from outside the target domain, use the FQDN.

For example, assume that you want to prepopulate the password cache for an RODC named

RODC2 in the domain hq.cpandl.com. You want to use the writeable domain controller named

WS2008A to transfer the passwords for a user account for Mike Danseglio (MikeDan) and his

computer named MDVista1. The MikeDan account is in a top-level organizational unit (OU)

named B1Users, and the MDVista1 account is in the default Computers container. To accomplish

all this, run the following command:

repadmin /rodcpwdrepl rodc2.hq.cpandl.com ws2008a.hq.cpandl.com “cn=mikedan,ou=b1users,

dc=hq,dc=cpandl,DC=com” cn=mdvista1,cn=Computers,dc=hq,dc=cpandl,dc=com

See AlsoRODC Administration

Adding Attributes to the RODC Filtered Attribute Set

This topic includes procedures for adding an attribute to the filtered attribute set (FAS) for a read-

only domain controller (RODC) and marking the attribute as confidential data. You can perform

these procedures to exclude specific data from replicating to RODCs in the forest. Because the

data is not replicated to any RODCs, you can be assured that the data will not be revealed to an

attacker who manages to successfully compromise an RODC. In most cases, adding an attribute

to the RODC FAS is completed by the developer of the application that added the attribute to the

schema.

Determine and then modify the current searchFlags value of the attribute

Verify that an attribute is added to the RODC filtered attribute set.

128

Determine and then modify the current searchFlags value of an attributeTo add an attribute to an RODC FAS, you must first determine the current searchFlags value of

the attribute that you want to add, and then set the following values for searchflags:

To add the attribute to the RODC FAS, set the 10th bit to 0x200.

To mark the attribute as confidential, set the 7th bit to 0x080.

For example, if the attribute that you want to add is indexed and no other bits are set, the current

searchflags value is 0x001 (or 1, as stated in decimal format). If you set the 10th bit of the

attribute to 0x200 (512) and the 7th bit to 0x080 (128), the new searchFlags value is 0x281 (or

641). In the following procedure, which uses a fictitious attribute named Contoso-App-

Password, no other bits are set for searchFlags. Therefore, the current value is 0.

This example uses Ldifde.exe to determine the current searchFlags value and modify it.

Ldifde.exe is a command-line tool that can create, modify, and delte directory objects. It is

included in the Active Directory Domain Controller Tools. For more information about installing

Active Directory Domain Controller Tools, see Installing Remote Server Administration Tools.

To perform the following procedure, you must be a member of the Schema Admins group.

Determine and then modify the current searchFlags value of an attribute

1. Click Start, right-click Command Prompt, and then click Run as administrator.


ldifde –d CN= Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain> –f

en_ldif –l searchflags

where <domain> is the distinguished name of your forest root domain.

3. Verify that the output of the file named en_ldif appears as follows:

dn: CN= Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain>

changetype: add

searchFlags: 0

4. Copy the contents of the output file to a new file named en-fas.ldif.

5. Modify the new file, en-fas.ldif, so that it appears as follows, and then save it:

dn: CN= Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain>

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

replace: searchFlags

searchFlags: 640

-

Note

129

Be sure to include the terminator "-" character, or the following procedure will not

work. If you are updating multiple schema objects at the same time, add an

empty line between each object.

6. Type the following command, and then press ENTER to import the modified en-fas.ldif

file:

ldifde –i -f en-fas.ldif

Verify that an attribute is added to the RODC FASYou can use this procedure to verify that an attribute is added to the RODC FAS.

To perform this procedure, you can be any authenticated user.

To verify that an attribute is added to the RODC FAS

1. Click Start, click Administrative Tools, and then click ADSI Edit.


what you want, and then click Continue.

3. Right-click ADSI Edit, and then click Connect to.

4. Click Select a well known Naming Context, click Schema, and then click OK.

5. In the console tree, double-click Schema, and then click the

CN=Schema,CN=Configuration,DC=<domain> container.

6. In the details pane, right-click CN= Contoso-App-Password, and then click Properties.

7. In the list of attributes, verify that the Confidential and RODC_Filtered flags are set.

Appendix A: Technical Reference Topics

This appendix includes supplemental information that can help organizations plan a read-only

domain controller (RODC) deployment:

Password changes on an RODC

DNS updates for clients that are located in an RODC site

User and Computer Credentials

How the authentication process works on an RODC

How the Windows Time Service Works on an RODC

Password changes on an RODCUsers change their passwords on a regular basis as specified by the Default Domain policy or a

fine grained password policy. After each authentication attempt that is serviced by an RODC, the

130

RODC performs an RSO operation to replicate the account credentials if it does not have the

current credentials stored locally. In a site that has an RODC and no writable domain controller,

one of two actions can occur when users try to change their passwords:

The password change request is sent directly to a writable domain controller.

In this case, the password change is written locally and then forwarded by the writable

domain controller to the domain controller that holds the primary domain controller (PDC)

emulator operations master (also known as flexible single master operations or FSMO) role in

the domain. This is the same behavior as in Windows Server 2003.

The password change request is sent to the RODC, which in turn forwards it to a writable

Windows Server 2008 domain controller.

The next steps are the same as what would occur if the password change happened directly

on the writable domain controller, as explained above.

If the password of a user is changed directly on a writeable domain controller, then when any

RODC that has the old password for that user performs a normal replication cycle that includes

that password update, it has the effect of making it appear as if the password for that user is no

longer present. (Although the old password is still present in the database on the RODC, the

metadata associated with the password attributes mark it as absent. Only on the next occasion

that the user logs on by using the RODC will the new password be replicated to the RODC by an

RSO operation. For more information about how an account password is allowed to be cached,

see Credential caching.

In some other cases, a newly changed password is replicated from the writable domain controller

to the RODC synchronously as part of the password change operation. In other words, a best

effort is made to replicate the password change prior to returning to the client requesting the

change. This is slightly different than the RSO behavior after a successful forwarded

authentication at the RODC. In that case, the RSO is queued and is therefore asynchronous.

Whether the RODC attempts to replicate the new password without waiting for the replication

schedule depends on how the password change is made. The following table describes how the

RODC handles replication of various types of password changes. These changes include

password changes that can be triggered by selection of the User must change password at

next logon setting on a user account, routine password expiration, and unprompted password

change. For all the types of situations that are described in the table, assume that the workstation

is in the same site as the RODC. Also, replication occurs only if the user account is cacheable on

the RODC. For more information about caching, see Credential caching.

Type of password change operation How the RODC replicates the password change

User account password change using

Ctrl+Alt+Del on a computer running

Windows Vista® or Windows Server 2008

This password change method typically uses

Kerberos. Specifically, the

NetUserChangePassword function calls into the

Negotiate security package, which on

Windows Vista or Windows Server 2008 will try

the Kerberos change password protocol in most

131


cases.

The RODC does not initially replicate the new

password as an individual change. Instead, the

password is nulled out on the RODC (that is,

the link between the password attribute value

and its memory address is removed; the

password itself is unchanged and remains

stored in memory) when scheduled replication

occurs from the writable domain controller.

The next time that the user logs on at the

RODC, the authentication is forwarded to the

writable domain controller. If the Password

Replication Policy (PRP) allows the password

to be cached on the RODC, the RODC

replicates the new password as an individual

change after authentication succeeds.

User account password change using

Ctrl+Alt+Del on a computer running

Windows XP, Windows Server 2003, or

Microsoft Windows 2000

This password change method uses NTLM,

which in turn calls in to the SAM password

change protocol.

By default, password change requests that are

initiated from Windows XP and

Windows Server 2003 clients locate a writable

domain controller to perform the password

change. Therefore, the RODC has no

knowledge of the password change and does

not immediately attempt to perform an RSO

operation to get the new password. The RODC

acquires the passwords for cacheable users

when they log on at the RODC.

You can apply a cumulative hotfix to these client

computers if they are in a site where an RODC

services the logon attempts. For Windows XP

computers, see Update for Windows XP

(KB944043) on the Microsoft Download Center


For Windows Server 2003 computers, see

Update for Windows Server 2003 (KB944043)

on the Microsoft Download Center


If you apply the hotfix, this behavior changes to

132




the following:

The clients locate the closest domain controller,

which happens to be the RODC, and send the

password change request to the RODC. The

RODC forwards the request to a writable

domain controller.

After forwarding the password change request

to the writable domain controller, the RODC

attempts to replicate in the updated password

using the RSO mechanism.

User account password change using LDAP This password change method can be used by

some forms or by administrative scripts that

reset passwords. For example, Outlook Web

Access has a form that lets users change their

domain password. The form is implemented on

Microsoft Internet Security and Acceleration

(ISA) Server 2006. It uses LDAP over Secure

Sockets Layer (SSL) to transfer the user name,

old password, and new password to the domain

controller in a secure manner.

The password change happens directly on a

writable domain controller. Therefore, the

RODC has no knowledge of the password

change, and it does not attempt to perform an

RSO operation to get the new password.

The next time that the user logs on at the


writable domain controller. If the PRP allows the

password to be cached on the RODC, the

RODC replicates the new password as an

individual change after authentication

succeeds.

For more information about password changes

using LDAP, see article 269190 in the Microsoft

Knowledge Base


Computer account password change on a

computer running any version of Windows

Computer account password changes are

performed over the Netlogon secure channel. If

the client computer has a secure channel to the

133



RODC, the RODC forwards the password

update to the writable domain controller. The

RODC then attempts to replicate the new

password using an RSO operation. For the

client computer to be able to establish a secure

channel with the RODC, its current credentials

must be cached on the RODC.

If the client computer does not have a secure

channel with the RODC, it attempts the

password change on a writable domain

controller. (This always happens if the client

computer account is not cached on the RODC.)

The next time that the computer logs on at the


writable domain controller. If the PRP allows the

password to be cached on the RODC, the

RODC replicates the new password as an

individual change after authentication

succeeds.

DNS updates for clients that are located in an RODC siteWhen a client attempts a dynamic update, it sends a start of authority (SOA) query to its preferred

DNS server. Typically, clients are configured to use the DNS server in their branch site as their

preferred DNS server. The RODC does not hold a writeable copy of the DNS zone. Therefore,

when it is queried for the SOA record, it returns the name of a writable Windows Server 2008

domain controller that hosts the Active Directory–integrated zone, just as a secondary DNS

server handles updates for zones that are not Active Directory–integrated zones. After it returns

the name of a writable Windows Server 2008 domain controller to the client, the RODC waits a

certain amount of time, as explained below, and then it attempts to replicate the updated DNS

object in Active Directory from the DNS server that it referred the client to through an RSO

operation.

Note

For the DNS server on the RODC to perform an RSO operation of the DNS record

update, a DNS server that runs Windows Server 2008 must host writeable copies of the

zone that contains the record. That Windows Server 2008 DNS server must register a

name server (NS) resource record for the zone. The Windows Server 2003 Branch Office

Guide recommended restricting name server (NS) resource record registration to a

134

subset of the available DNS servers. If you followed those guidelines and you do not

register at least one writable Windows Server 2008 DNS server as a name server for the

zone, the DNS server on the RODC attempts to perform the RSO operation with a DNS

server that runs Windows Server 2003. That operation will fail and generate a 4015 Error

in the DNS event log of the RODC, and replication of the DNS record update will be

delayed.

More specifically, the SOA query triggers the DNS server on the RODC to put an entry in the

remotePollList, which is an internal queue on each DNS server. The entry includes the following:

The object to be replicated

The source domain controller to replicate from

A time stamp

The time stamp is set to a time in the future that is equal to the current time plus a replication

delay. The replication delay is controlled by a registry setting named

DsRemoteReplicationDelay. By default, the value of this setting is 30 seconds.

The internal queue (remotePollList) is processed at regular intervals. The queue-processing

interval is controlled by a registry setting named DSPollingInterval. By default, the value is

three minutes.

Important

DsPollingInterval controls all Active Directory polling, not just RODC RSO handling. If

you change this value, be aware that it will affect more than just RODC RSO operations.

When the DNS server processes the queue, it attempts to replicate only objects whose time

stamp is less than current time. Therefore, the delay between the time that the RODC refers the

client to an authoritative DNS server and then attempts to replicate in is determined by the

following:

1. The next time that the DNS server processes the queue

2. Whether the remote replication delay that is set on the entry in the queue has elapsed

If you use the default values for the registry settings, the amount of time before the RODC

attempts to replicate the DNS update is a minimum of 30 seconds and a maximum of

210 seconds.

You can modify the values of these registry settings to reduce the amount of time before the

RODC attempts to replicate the DNS update. The minimum value for the

DsRemoteReplicationDelay setting is 5 seconds. The minimum value for the DSPollingInterval

setting is 30 seconds. If you use the minimum values, the amount of time before the RODC

attempts to replicate the DNS update is a minimum of 5 seconds and a maximum of 35 seconds.

The following table lists some additional registry entries that are related to the RSO operations

that are performed for DNS updates on an RODC. These registry entries are stored in the

following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

135

Registry entry Minimum value Maximum value Default value

EnableRSOForRODC Either True or

False

True

MaximumRodcRsoQueueLength 1 1000000 300

MaximumRodcRsoAttemptsPerCycle 1 1000000 100

DsRemoteReplicationDelay 5 3600 30

To modify any of the registry entries that are related to the RSO operations for DNS updates on

an RODC, use the Dnscmd.exe command-line tool to set the appropriate parameter. For

example, suppose that you add a member server in a branch office with an RODC, and the

member server runs a service that registers records in DNS. To help reduce the time that it takes

for clients in the branch to locate the new member server by looking up its IP address in DNS,

you can run the following command to change the value of DsRemoteReplicationDelay to 10:

dnscmd <server>.<domain>.<com> /Config /DsRemoteReplicationDelay 10

Where <server> is the name of the RODC and <domain>.<com> is the name of your domain.

User and computer credentialsCredentials consist of approximately twelve attributes that may not be present for all accounts.

User and computer account credentials typically include the five attributes in the following table.

Attribute name Description

ATT_UNICODE_PWD The Windows NT hash of user’s password

ATT_DBCS_PWD The LAN Manager (LM) hash of the user’s

password (deprecated)

ATT_NT_PWD_HISTORY Password history for ATT_UNICODE_PWD

ATT_LM_PWD_HISTORY Password history for ATT_DBCS_PWD

ATT_SUPPLEMENTAL_CREDENTIALS Optional key material computed by

authentication packages when a user changes

a password

136

How the authentication process works on an RODCThis section explains how the authentication process works when you use a read-only domain

controller (RODC) for authentication. The processes for a computer account authenticating to the

domain, a user logging on to the domain, and a user attempting to access a resource through an

RODC are described.

The scenario used to discuss the processes described in this section is as follows:

The accounts, resources, and objects described in this section are assumed to be in a single

Active Directory domain.

A network user named Bob Kelly has a user account named BobKelly.

Bob Kelly’s workstation is named BKCOMPUTER.

BKCOMPUTER is located in a site in AD DS named Branch1.

RODC1 is an RODC for the domain, and it is the only domain controller located in Branch1.

The Password Replication Policy (PRP) allows the passwords for BKCOMPUTER and

BobKelly to be cached on RODC1.

The account passwords for BKCOMPUTER and BobKelly are not yet cached on RODC1.

WDC1 is a writeable domain controller, and it is running Windows Server 2008.

WDC1 is located in a site in AD DS named Hub.

The scenario is depicted in the following illustration.

Scenario showing some security principals involved in the RODC authentication process

Note

This document uses terminology that is specific to the Kerberos authentication process.

For an overview of how Kerberos authentication works, see Kerberos Explained


137


Computer account authentication using an RODCDomain member computers must authenticate to the domain. When computer accounts are

located in sites that are serviced by an RODC, they will attempt to authenticate through the

RODC. The following figure and steps describe the process that occurs when BKCOMPUTER

authenticates to the domain for the first time to request a ticket-granting ticket (TGT). Because

RODC1 is advertised as the Kerberos Key Distribution Center (KDC) for the site, BKCOMPUTER

uses RODC1 as the KDC. (The KDC is a network service that supplies session tickets and

temporary session keys that are used in the Kerberos V5 authentication protocol.)

BKCOMPUTER authenticates to the domain

BKCOMPUTER authenticates to the domain

1. BKCOMPUTER prepares a Kerberos authentication service request (KRB_AS_REQ) and

sends it to RODC1.

2. RODC1 receives the KRB_AS_REQ from BKCOMPUTER. RODC1 checks its local

database to see if the account password for BKCOMPUTER is cached. Because the

password is not cached, RODC1 cannot authenticate BKCOMPUTER.

3. RODC1 forwards the KRB_AS_REQ from BKCOMPUTER to a writeable domain

controller running Windows Server 2008, which is a computer named WDC1 in this

scenario.

4. WDC1 receives the KRB_AS_REQ and is able to authenticate BKCOMPUTER using its

full copy of the Active Directory database.

5. WDC1 generates a Kerberos authentication service response (KRB_AS_REP) for

BKCOMPUTER and sends it to RODC1.

6. RODC1 performs the following two actions:

138

a. Requests that WDC1 replicate the credentials for BKCOMPUTER to its replica of the

Active Directory database.

b. Forwards the KRB_AS_REP to BKCOMPUTER.

1. WDC1 checks the PRP and determines that BKCOMPUTER is allowed to cache its

account password on RODC1.

2. The credentials for BKCOMPUTER are replicated to RODC1 and BKCOMPUTER is

added to the list of Accounts whose passwords are stored on this Read-only

Domain Controller (also known as the Revealed List, or the msDS-RevealedList

attribute) of RODC1.

3. RODC1 caches the account password for BKCOMPUTER.

At the conclusion of this process, BKCOMPUTER has a TGT that is signed with the domain key

and its account credentials are cached on RODC1.

Initial user logon process using an RODCWhen Bob logs on to the domain using BKCOMPUTER, the TGT must be retrieved from the

domain controller and then a service ticket allowing BobKelly to use BKCOMPUTER must be

obtained. The TGT retrieval process, as well as the process for obtaining a service ticket, is

described in the following illustrations and steps.

TGT retrieval process

TGT retrieval process

1. Bob attempts to log on using BKCOMPUTER.

2. Because RODC1 is advertised as the KDC for the site, BKCOMPUTER prepares a TGT

139

request (KRB_AS_REQ) and sends it to RODC1.

3. RODC1 receives the KRB_AS_REQ from BKCOMPUTER. RODC1 checks its local

database and does not have the account password for BobKelly stored locally; therefore,

it cannot authenticate BobKelly.

4. RODC1 forwards the KRB_AS_REQ to WDC1 (a writeable domain controller).

5. WDC1 receives the KRB_AS_REQ and is able to authenticate BobKelly using its full

copy of the Active Directory database.

6. WDC1 signs a TGT using the domain krbtgt account and sends the KRB_AS_REP to

RODC1.

7. RODC1 then performs the following two actions:

c. Requests that WDC1 replicate the credentials for BobKelly to its replica of the

Active Directory database.

d. Forwards the KRB_AS_REP for BobKelly to BKCOMPUTER.

1. WDC1 checks the PRP and determines that BobKelly is allowed to cache its account

password on RODC1.

2. The credentials for BobKelly are replicated to RODC1, and BobKelly is added to the

Revealed List.

3. RODC1 caches the account password for BobKelly.

At the conclusion of this process, the BKCOMPUTER and BobKelly accounts have TGTs that are

signed with the domain key and both accounts have cached credentials on RODC1. However,

before Bob can use BKCOMPUTER, his user account (BobKelly) must obtain a service ticket.

The following procedure describes the acquisition of a service ticket for BobKelly using RODC1.

Service ticket acquisition

140

Service ticket acquisition

1. BKCOMPUTER transmits a Kerberos ticket-granting service (TGS) request

(KRB_TGS_REQ) for BobKelly to RODC1 along with the TGT that was issued by WDC1.

2. RODC1 cannot decrypt the TGT because it does not know the password of the krbtgt

account that writeable domain controllers use to encrypt the TGT. RODC1 therefore

forwards the KRB_TGS_REQ to WDC1.

3. WDC1 receives and deciphers the KRB_TGS_REQ and replies with a Kerberos TGS

response (KRB_TGS_REP) to RODC1.

4. Because RODC1 has cached BobKelly’s credentials, it is able to satisfy requests for

service tickets. Therefore, after receiving a KRB_TGS_REP from WDC1, RODC1 returns

an error message to BKCOMPUTER, instead of a Service Ticket.

5. BKCOMPUTER discards the TGT that was previously issued by WDC1 after receiving

the error message from RODC1. Then, BKCOMPUTER sends another KRB_AS_REQ to

RODC1.

6. RODC1 receives the KRB_AS_REQ. Because BobKelly’s credentials are cached,

RODC1 uses its own krbtgt account to encrypt the TGT.

7. RODC1 then sends a KRB_AS_REP with the new TGT to BKCOMPUTER.

8. BKCOMPUTER sends another KRB_TGS_REQ (including the new TGT issued by

RODC1) to RODC1.

9. RODC1 receives the KRB_TGS_REQ and is able to decrypt the TGT this time. Because

BKCOMPUTER credentials are cached locally, RODC1 generates and sends a

KRB_TGS_REP with the service ticket to BKCOMPUTER for BobKelly.

At the conclusion of this process, BobKelly is logged on to BKCOMPUTER and has a service

ticket to use BKCOMPUTER that was issued by RODC1. Both BobKelly and BKCOMPUTER

account credentials are cached on RODC1. WDC1 has recorded that it revealed the credentials

of BKCOMPUTER and BobKelly to RODC1.

Subsequent user logons after credentials are cached on the RODCAfter the credentials for a user account and the credentials for the workstation to which the user

logs on are cached on an RODC, the RODC can process the logon request without contacting a

writeable domain controller. The process for allowing subsequent access of BKCOMPUTER for

BobKelly using RODC1 for authentication is described by the following illustration and steps.

141

BobKelly logs on after credentials are cached on RODC1

BobKelly logs on after credentials are cached on RODC1

1. Bob attempts to log on using BKCOMPUTER.

2. Because RODC1 is advertised as the KDC for the site, BKCOMPUTER sends a

KRB_AS_REQ to RODC1.

3. RODC1 receives the KRB_AS_REQ from BKCOMPUTER and is able to authenticate

BobKelly using its local copy of the Active Directory database, because the credentials for

BobKelly and BKCOMPUTER are cached locally.

4. RODC1 creates the KRB_AS_REP, including a TGT signed with the krbtgt account of

RODC1, and sends it to BKCOMPUTER.

5. BKCOMPUTER stores the TGT in a ticket cache that is associated with Bob’s logon

session. BKCOMPUTER then prepares a KRB_TGS_REQ for BobKelly and sends it to

RODC1.

6. RODC1 is able to decrypt the TGT in the KRB_TGS_REQ from BKCOMPUTER because

the TGT was encrypted by the krbtgt account on RODC1. Because the credentials for

BKCOMPUTER are stored locally, RODC1 creates a KRB_TGS_REP, which includes the

service ticket.

7. RODC1 sends the KRB_TGS_REP to BKCOMPUTER, where it is stored in a ticket

cache that is associated with Bob’s logon.

Bob’s logon session now includes a TGT as well as a service ticket that allows use of

BKCOMPUTER, which were both provided by RODC1. Bob is now able to begin working at

BKCOMPUTER.

142

Caution

For an RODC to authenticate a logon request locally, both the user and computer

credentials must be cached locally. If the user’s credentials are cached, but the computer

credentials are not cached, the RODC cannot provide a service ticket for the user to log

on to the computer. If a network outage prevents the RODC from contacting a writeable

domain controller running Windows Server 2008, the RODC will not be able to provide a

service ticket for the computer account and the user logon will fail.

Resource access using authentication by an RODCWhen Bob needs to access a resource on a server in another site, his account requires a service

ticket that allows access to that server. The process for BobKelly to obtain a service ticket to

access a server named FileServ in the Hub site is described by the following illustration and

steps.

BobKelly accesses a resource on a server in a different site

BobKelly accesses a resource on a server in a different site

1. Bob attempts to access a resource on FileServ by using BKCOMPUTER.

2. BKCOMPUTER sends a Kerberos application server request (KRB_AP_REQ) for

FileServ to RODC1.

3. RODC1 can read the TGT in the KRB_AP_REQ, but it does not have the credentials for

FileServ cached locally. Therefore, it forwards the request to a writeable domain

controller running Windows Server 2008, which in this example is WDC1.

4. WDC1 can decrypt the TGT that was created by RODC1. However, because writeable

domain controllers do not trust TGTs that are issued by RODCs, WDC1 performs a

143

separate authentication on the KRB_AP_REQ.

5. After authenticating the request, WDC1 sends a Kerberos application server response

(KRB_AP_REP), including a service ticket for FileServ, to RODC1.

6. RODC1 forwards the KRB_AP_REP to BKCOMPUTER.

7. BKCOMPUTER is now able to make a connection to FileServ to allow Bob to access

resources to which his account has been granted access.

FileServ credentials are not cached on RODC1, but Bob has access to the resources for which

his account has been granted access on FileServ.

How the Windows Time Service Works on an RODCReliable time synchronization is required for Kerberos authentication. Client computers can

synchronize time from any domain controller, including an RODC. An RODC can synchronize

time only from a writable domain controller that runs Windows Server 2008. When a domain

controller answers time synchronization requests from clients, it is considered to be a “time

source.”

When a client computer attempts to synchronize time, the following sequence occurs on the client

computer:

The Windows Time service (W32time), using Netlogon, requests a domain controller that

matches a set of criteria. For an overview of the criteria, see Keeping the Domain on Time


The Windows Time service performs scoring for all the domain controllers that are returned

by the search requests. Multiple requests are made to locate an optimal time source.

When the Windows Time service chooses a time source, it attempts to synchronize with that time

source. Time synchronization on a domain is designed to operate securely to prevent tampering

with the responses that the time source sends.

When a client computer attempts to synchronize its local clock with the clock on the time source,

the client sends out a time synchronization request. This request contains a security identifier for

the client computer, which the domain controller uses to generate a signature for the response.

When the client computer receives the response, the client computer validates the signature to

ensure that the response did in fact come from the domain controller.

When a client computer attempts to synchronize with a time source, the following steps occur:

The Windows Time service requests a relative ID (RID) from NetLogon, based on the location

of the time source.

Note

The RID that NetLogon returns can be either the RID for the local computer account

or the RID of a Trusted Domain Object (TDO), when the time source belongs to

another forest. A TDO is used when the time source is located in different forest than

144


the client computer because the time source does not possess the required secret for

a RID in a separate forest.

The Windows Time service adds the RID to the request (along with other values) and sends

the request to the time source.

When the domain controller receives the request:

The client computer uses NetLogon to create a signature based on the secret associated RID

that is contained in the request. When the client computer receives the response from the

time source, it uses this signature to verify the identity of the time source as being a domain

controller.

The domain controller performs the necessary additional processing (according to Request

for Comments (RFC) 1305), and it sends the response to the client computer.

When the client computer receives the response:

The client computer uses NetLogon to generate a signature based on the secret associated

with the RID that was sent in the original request. This signature is generated in the same

way that the domain controller generated the signature before it sent the response.

The client computer compares the signature it generated to the signature in the response

from the domain controller. If the two signatures match, the client computer accepts the

response.

RODCs pose a special challenge to this authentication mechanism because an RODC may or

may not possess the required secrets to generate a proper signature. Therefore, request

processing on an RODC occurs in the following way:

The RODC receives the request from the client computer.

The Netlogon service verifies that the RODC has the computer password cached for the

account whose RID is specified and attempts to sign the request.

If the client account password is cached on the RODC:

The Netlogon service signs the response by adding the signature that NetLogon

generates to the authentication field in the response.

The RODC sends the signed response over the network to the client computer.

If the client account password is not cached:

The Netlogon service is not able to generate a signature for the response, and it informs

the Windows Time service that it cannot generate a signature.

The RODC adds an entry to the “chaining table.” The purpose of the chaining table is to

allow the RODC to “remember” requests that it forwarded to a writable domain controller

so that it will be able to forward the response to the client computer that made the original

request. The chaining table contains the following fields:

IP Address: The IP address (either IP version 4 (IPv4) or IP version 6 (IPv6)) of the client computer that sent the request.

RID: The RID that is contained in the request.

OriginateTimestamp: The time stamp on the client computer indicating when the client computer sent the request. This field, along with the RID, is critical to matching

145

the response with the proper entry in the chaining table. The {RID, OriginateTimestamp} pair uniquely identifies a request that a particular client sends at a particular time.

ArrivalTime: The time stamp, according to the RODC, indicating when the request arrived.

The RODC forwards a request over the network to the writable domain controller that it is

currently using as a time source. The RODC always forwards time synchronization requests

to the time source that it is currently using.

On the writable domain controller, processing of the request occurs as it normally would.

From the perspective of the writable domain controller, this appears to be a legitimate time

synchronization request from the RODC.

Over the network, the writable domain controller sends a Network Time Protocol (NTP)

response back to the RODC.

The RODC receives the response from the writable domain controller. An RODC always

attempts to match a response to an entry in the chaining table. The response from the

writable domain controller contains both the RID and the OriginateTimestamp value, which

the RODC matches to an entry in the chaining table.

If an entry is found, the RODC forwards the request to the IP address in the chaining

table.

If an entry is not found, the RODC assumes that the RODC itself sent a request to the

writable domain controller, and the RODC processes the response accordingly.

Security mechanisms that are related to the Windows Time service on an RODCThere are a number of security mechanisms that are built into the Windows Time service chaining

mechanism. These security mechanisms are designed to prevent various types of attacks that

can be made against an RODC.

Limited entry lifetime: Entries that are added to the chaining table are considered to be

“expired” after 16 seconds. Entries are not cleaned up from the chaining table; instead, they

are checked when a new request or response is received. At the beginning of every request

or response process, the RODC checks the chaining table for expired entries, and those

entries are removed. If a response from the writable domain controller is received after the

entry is removed, the response is discarded. The value of 16 seconds is part of the

implementation, and it is not adjustable. This value was chosen because 16 seconds is the

maximum lifetime of an NTP request, according to the NTP specification (RFC 1305).

Acceptance-only forwarding: Responses are forwarded to a client computer only if a matching

entry is found in the chaining table. In this way, an attacker cannot “force” time responses to a

client through the RODC.

146

Per-RODC threshold: The size of the chaining table is adjustable, but it cannot grow beyond

a specified limit. This restricts the RODC to allowing only a set number of outstanding

requests at a given time, which prevents the chaining table from saturating the memory of the

RODC. If a request is received when the table is full, the request is discarded.

Per-client threshold: By default, a client computer is limited to a maximum of four outstanding

time synchronization requests at any given time. This prevents a single client computer from

saturating the chaining table and preventing other clients from making time-synchronization

requests. If a request is received when the client computer has reached its per-client limit, the

request is discarded.

The following are additional issues that are related to how the Windows Time service works on

RODCs that can affect RODC planning and deployment:

RODCs are restricted to synchronize with only Windows Server 2008 domain controllers. The

chaining mechanism has special requirements that only a Windows Server 2008 domain

controller can satisfy. If the chaining table is disabled, the RODC is allowed to synchronize

with any domain controller, but it will be not be able to answer time synchronization requests

from client computers.

RODCs are restricted from synchronizing with other RODCs.

RODCs are restricted from synchronizing with domain controllers outside their own domain.

Registry entries that are specific to the Windows Time service forwarding mechanism on an RODCAll entries in the following table are located in the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\

NtpServer

Entry name (data type) Description Default value Minimum

value

Maximum

value

ChainEntryTimeout

(REG_DWORD)

Specifies the

maximum amount

of time (in

seconds) that an

entry can remain

in the chaining

table before being

considered

“expired.” Entries

that are marked

as expired may be

removed when the

next request or

4 4 16

147

response is

processed on the

RODC.

ChainMaxEntries

(REG_DWORD)

Specifies the

maximum number

of entries that are

allowed in the

chaining table.

The chaining table

grows and shrinks

dynamically as

requests are

received and

responses are

forwarded

(respectively), but

it never grows

beyond the

maximum size. If

the table is full

and no expired

entries can be

removed, any

incoming requests

are discarded.

128 128 1024

ChainMaxHostEntries

(REG_DWORD)

Description:

Specifies the

maximum number

of entries that are

allowed in the

chaining table for

a particular IP

address. If a

request is

received and the

chaining table

already contains

the maximum

number of entries

for that IP

address, the

request is

4 4 16

148

discarded.

ChainDisable

(REG_DWORD)

Disables the

chaining

mechanism,

allowing an RODC

to synchronize

with any domain

controller but

preventing any

hosts from

synchronizing with

the RODC. A

value of 0

represents

FALSE; any other

value represents

TRUE.

0 (FALSE,

chaining is not

disabled)

Appendix B: Events That Are Related to RODCs

The following events can be logged for various operations read-only domain controllers (RODCs).

In some cases, you may have to change the diagnostic event logging level to see the event. For

more information about changing the diagnostic event logging level, see How to configure Active

Directory diagnostic event logging in Windows Server 2003 and in Windows 2000 Server


Event ID: 2116

Severity: Error

Message: The Install-From-Media promotion of a Read-Only DC cannot start because the

specified source database is not allowed. Only databases from other RODCs can be used for

IFM promotion of a RODC.

Event ID: 2117

Severity: Error

Message: The Install-From-Media promotion of a DC cannot start because the specified

source database is from a Read-Only DC. Only databases from other DCs can be used for

IFM promotion of a DC.

149


Event ID: 2800

Severity: Information

Message: The caller made a replication-caching request for a security principal in the writable

directory partition that has been denied.

Directory partition: %n%1

Security Principal requested: %n%2

Event ID: 2801


Message: Couldn't find a LH writable PDC for the domain.

Event ID: 2802


Message: Configuration settings indicate that this Read-only Domain Controller should be

installed in site %1, but this site doesn't contain a site settings object.

Event ID: 2803


Message: During read only DC promotion setting options on site object %1 failed.

Event ID: 2804


Message: Creating state objects for Read-only Domain Controller.

Event ID: 2805


Message: Replicating secrets for Read-only Domain Controller.

Event ID: 2806


Message: While promoting Read-only Domain Controller, failed to create the state objects.

Event ID: 2807


Message: While promoting Read-only Domain Controller, failed to update the SPNs on the

computer object.

Event ID: 2808


Message: While promoting Read-only Domain Controller, failed to create secondary krbtgt

account.

Event ID: 2809


Message: While promoting Read-only Domain Controller, failed to create krbtgt link.

150

Event ID: 2810


Message: While promoting Read-only Domain Controller, failed to replicate the secrets from

the helper DC_TERM_ABBR.

Event ID: 2811


Message: Failed to cache a write referral list on Read Only DC.

Event ID: 2812


Message: A write request was received at the Read Only DC. Failed to generate write referral

to a writable DC. Write request received from client %3

Event ID: 2813


A write request was received at the Read Only DC. The Read Only DC has generated a

referral to writable DC %1.

Write request received from client %2 for object %3. The write request was made by the user

%4.

Event ID: 2814


Message: Failed to replicate single object (the krbtgt account) from PDC to Helper DC_TERM

Event ID: 2815


Message: Failed to replicate single object secret (for the krbtgt account) from PDC to Helper

DC_TERM

Event ID: 2816


Message: Failed to cache a write referral list for PDC on Read Only DC.

Event ID: 2823


Message: While promoting Read-only Domain Controller, failed to set the reveal on demand

and/or never reveal groups.

Event ID: 2824


Message: Checking state objects for Read-only Domain Controller.

Event ID: 2829


151

Message: While promoting Read-only Domain Controller, the expected state objects could

not be found.

Event ID: 2831


Message: The Directory Service is no longer configured to host the following read-only

application directory partition. An attempt to remove the partition failed.

Application directory partition:%n%1

This operation will be tried again later.

Event ID: 2832


Message: The Directory Service is no longer configured to host the following read-only

application directory partition.

Application directory partition:%n%1

The objects in this directory partition will be removed from the AD_TERM database on the

directory service.

Event ID: 2834

Severity: Error

Message: The local directory service was prompted to add a writable replica of the following

directory partition. The local directory service is read-only and cannot add a writable replica of

any partition.

Directory partition:%n%1

Network address:%n%2

Options:%n0x%3

Event ID: 2835

Severity: Warning

Message: The local directory service has detected an incorrect serverReference value on the

following server object.

Server object:%n%1

Expected value:%n%2

Event ID: 2837


Message: While promoting a Read-only Domain Controller, failed to update the DNS

hostname on the server object.

Event ID: 2838


Message: While promoting a Read-only Domain Controller, failed to update the operating

system version information on the computer object.

152

Event ID: 2843

Severity: Error

Message: The Knowledge Consistency Checker was unable to locate a replication

connection for the read-only local directory service. A replication connection with the

following option must exist in the forest for correct FRS system behavior.

Additional Data: Option: %n%1

User Action: Restore the original replication connection for the local directory service instance

on a writable directory service instance.

Logging level: 0

Event ID: 2844

Severity: Warning

Message: The Knowledge Consistency Checker located a replication connection for the local

read-only directory service, but the source server is not responsive or not replicating. A new

source server will be chosen and a writable directory service instance will be updated.

Additional Data: Connection: %n%1

Source Server: %n%2

Logging level: 2

Event ID: 2845

Severity: Error


read-only directory service, but the source server is not responsive or not replicating. A new

suitable source server was not found from the current replication partners. This operation will

be retried.


Source Server: %n%2

Event ID: 2846



read-only directory service, but the connection's schedule is not accurate. A new schedule

was found from a current replication partner. It will be updated in the forest.


Current Partner Connection: %n%2

Logging level: 2

Event ID: 2847

Severity: Error


read-only directory service and attempted to update it remotely on the following directory

service instance. The operation failed. It will be retried.

153

Event ID: 2853

Severity: Error

Message: While promoting a Read-only Domain Controller (RODC), failed to create a

connection object for the RODC.

Logging level: 1

Event ID: 2854

Severity: Error

Message: The local directory service was prompted to add a partial-attribute set read-only

replica (global catalog options) of the following directory partition. The local directory service

is a read-only domain controller and cannot add a partial-attribute set replica of any partition.



Options:%n0x%3

Event ID: 2855

Severity: Error

Message: The local directory service was prompted to add an unknown replica type of the

following directory partition. The local directory service is a read-only domain controller and

cannot add unknown replica types.



Options:%n0x%3

Event ID: 2872

Severity: Error

Message: The domain controller is trying to replicate the following NC from the following

read-only domain controller. Replication with source as read-only domain controller is not

allowed to proceed.

Naming Context:%n%1

Server:%n%2

These additional events can be logged in other logs or on other servers.

Event ID: 1645


Message: Active Directory did not perform an authenticated remote procedure call (RPC) to

another domain controller because the desired service principal name (SPN) for the

destination domain controller is not registered on the Key Distribution Center (KDC) domain

controller that resolves the SPN.

Destination domain controller:%n%1

SPN:%n%2

154

User Action: Verify that the names of the destination domain controller and domain are

correct. Also, verify that the SPN is registered on the KDC domain controller. If the destination

domain controller has been recently promoted, it will be necessary for the local domain

controller’s computer account data to replicate to the KDC before this computer can be

authenticated.

Note

This event is logged on a domain controller that runs Windows Server 2003, if the

domain controller is a global catalog server and an RODC is in the same site. This

configuration is not recommended but could be a temporary situation during an

upgrade of a site.

Event ID: 1699


Message: This event is registered in the Directory Service log on the writable domain

controller that is the replication partner of an RODC when the RODC attempts a replicate

single object (RSO) operation to cache a password for an account that is not allowed to be

cached on the RODC.

Event ID: 4015

Severity: Error

Message: This event is registered in the DNS event log on the RODC when it tries an RSO

operation against a Windows Server 2003 DNS server. This event happens if only Windows

Server 2003 DNS servers have registered name server (NS) records for that zone.

Event ID: 4768


Message: This event is registered in the Security log after a successful logon. This event is

logged on both the RODC and its replication partner.

Appendix C: List of Acronyms Used in this Guide

This list includes some of the acronyms that are commonly used in discussion about RODCs:

ACL: access control list

ARS: administrator role separation

CAR: control access right

DN: distinguished dame

DNS: Domain Naming System

155

DMZ: demilitarized zone

FAS: Filtered Attribute Set

FAZ: Find Authoritative Zone

PRP: Password Replication Policy

RODC: read-only domain controller

156