Download - 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
(http://go.microsoft.com/fwlink/?LinkID=89032)
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
(http://go.microsoft.com/fwlink/?LinkID=89024)
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
(http://go.microsoft.com/fwlink/?LinkID=89026)
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
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
(http://go.microsoft.com/fwlink/?LinkID=47965).
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.
Administrative credentials
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.
3. Insert the Windows Server 2008 DVD into the CD or DVD drive.
4. Click Start, right click Command prompt, and then click Run as administrator.
5. Type the following command, and then press ENTER:
D:\sources\adprep\adprep /domainprep /gpprep
Where D: is the drive letter of your CD or DVD drive.
6. Allow the operation to complete, and then allow the changes to replicate throughout the
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.
Administrative credentials
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.
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.
4. Type the following command, and then press ENTER:
D:\sources\adprep\adprep /rodcprep
Where D: is the drive letter of your CD or DVD drive.
5. Allow the operation to complete, and then allow the changes to replicate throughout the
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
Issue Affects … Impact Workaround
join fails computers
in the
RODC site
(perimeter
network
scenario)
an RODC is available but a writable
domain controller is not available,
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
an RODC is available but a writable
domain controller is not available,
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
an RODC is available but a writable
domain controller is not available,
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
Issue Affects … Impact Workaround
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
Issue Affects … Impact Workaround
(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?
(http://go.microsoft.com/fwlink/?LinkID=119624).
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
(http://go.microsoft.com/fwlink/?LinkID=114419).
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
(http://go.microsoft.com/fwlink/?LinkId=100501).
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
(http://go.microsoft.com/fwlink/?LinkId=100506).
For more information about DsGetDcName, see DsGetDcName Function
(http://go.microsoft.com/fwlink/?LinkId=100509).
For more information about serverless binding, see Serverless Binding and RootDSE
(http://go.microsoft.com/fwlink/?LinkId=67638).
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
(http://go.microsoft.com/fwlink/?LinkId=93254).
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
Windows Server 2003 domain
controller is deployed in the site
with an RODC and the WAN is
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
which domain controller is
contacted.
However, offline authentication
fails if the account is not cached
55
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
Windows Server 2003 domain
controller is deployed in the site
with an RODC and the WAN is
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
which domain controller is
contacted.
LDAP read operations and write
operations work, regardless of
which domain controller is
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
(http://go.microsoft.com/fwlink/?LinkId=120013).
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
(http://go.microsoft.com/fwlink/?LinkID=114418).
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
(http://go.microsoft.com/fwlink/?LinkId=113173).
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
(http://go.microsoft.com/fwlink/?LinkId=113459).
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
(http://go.microsoft.com/fwlink/?LinkID=120013).
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
(http://go.microsoft.com/fwlink/?LinkID=26093).
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.
Administrative credentials
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.
2. Type the following command, and then press ENTER:
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=GroupName2
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.
2. Type the following command, and then press ENTER:
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.
Administrative credentials
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.
2. On the first line, type [DCINSTALL], and then press ENTER.
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=GroupName1
PasswordReplicationAllowed=GroupName2
PasswordReplicationAllowed=User_Name1
PasswordReplicationAllowed=Computer_Name1
DelegatedAdmin=RODCAdministrator
SiteName=SiteName
InstallDNS=Yes
ConfirmGc=Yes
ReplicationSourceDC=SourceDCName
92
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.
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.
Administrative credentials
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.
2. On the first line, type [DCINSTALL], and then press ENTER.
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
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.
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.
Administrative credentials
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.
Administrative credentials
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.
Administrative credentials
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
(http://go.microsoft.com/fwlink/?LinkId=120127).
How to enable Windows Remote Shell (http://go.microsoft.com/fwlink/?LinkId=120130).
Hey, Scripting Guy! Desktop Management from beyond the Grave
(http://go.microsoft.com/fwlink/?LinkId=120131).
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
(http://go.microsoft.com/fwlink/?LinkID=116179).
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.
3. 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.
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
Computers, click Start. In Start Search, type dsa.msc, and then press ENTER.
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
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. 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
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.
2. Click Domain Controllers, and in the details pane, right-click the RODC computer
account, and then click Properties.
3. Click the Password Replication Policy tab.
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
1. Open an elevated Command Prompt window using the credentials of a Domain Admin.
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
(http://go.microsoft.com/fwlink/?LinkId=120196).
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
http://go.microsoft.com/fwlink/?LinkId=83477.
To move accounts from the Auth2 list to the Allow list using Repadmin
1. Open an elevated Command Prompt window using the credentials of a Domain Admin.
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 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
http://go.microsoft.com/fwlink/?LinkId=83477.
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.
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. 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. 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
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. 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 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
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. 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
http://go.microsoft.com/fwlink/?LinkId=83477.
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
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. Click Domain Controllers.
5. In the details pane, right-click the RODC computer account, and then click Properties.
6. Click the Password Replication Policy tab.
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
1. Open an elevated Command Prompt window using the credentials of a Domain Admin.
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 /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.
2. Type the following command, and then press ENTER:
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.
2. If the User Account Control dialog box appears, confirm that the action it displays is
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
Type of password change operation How the RODC replicates the password change
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
(http://go.microsoft.com/fwlink/?LinkId=120318).
For Windows Server 2003 computers, see
Update for Windows Server 2003 (KB944043)
on the Microsoft Download Center
(http://go.microsoft.com/fwlink/?LinkId=120317).
If you apply the hotfix, this behavior changes to
132
Type of password change operation How the RODC replicates the password change
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
RODC, the authentication is forwarded to 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
(http://go.microsoft.com/fwlink/?LinkId=119599).
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
Type of password change operation How the RODC replicates the password change
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
RODC, the authentication is forwarded to 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
(http://go.microsoft.com/fwlink/?LinkId=120374).
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
(http://go.microsoft.com/fwlink/?LinkId=119970).
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
(http://go.microsoft.com/fwlink/?LinkId=120551).
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
Severity: Information
Message: Couldn't find a LH writable PDC for the domain.
Event ID: 2802
Severity: Information
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
Severity: Information
Message: During read only DC promotion setting options on site object %1 failed.
Event ID: 2804
Severity: Information
Message: Creating state objects for Read-only Domain Controller.
Event ID: 2805
Severity: Information
Message: Replicating secrets for Read-only Domain Controller.
Event ID: 2806
Severity: Information
Message: While promoting Read-only Domain Controller, failed to create the state objects.
Event ID: 2807
Severity: Information
Message: While promoting Read-only Domain Controller, failed to update the SPNs on the
computer object.
Event ID: 2808
Severity: Information
Message: While promoting Read-only Domain Controller, failed to create secondary krbtgt
account.
Event ID: 2809
Severity: Information
Message: While promoting Read-only Domain Controller, failed to create krbtgt link.
150
Event ID: 2810
Severity: Information
Message: While promoting Read-only Domain Controller, failed to replicate the secrets from
the helper DC_TERM_ABBR.
Event ID: 2811
Severity: Information
Message: Failed to cache a write referral list on Read Only DC.
Event ID: 2812
Severity: Information
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
Severity: Information
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
Severity: Information
Message: Failed to replicate single object (the krbtgt account) from PDC to Helper DC_TERM
Event ID: 2815
Severity: Information
Message: Failed to replicate single object secret (for the krbtgt account) from PDC to Helper
DC_TERM
Event ID: 2816
Severity: Information
Message: Failed to cache a write referral list for PDC on Read Only DC.
Event ID: 2823
Severity: Information
Message: While promoting Read-only Domain Controller, failed to set the reveal on demand
and/or never reveal groups.
Event ID: 2824
Severity: Information
Message: Checking state objects for Read-only Domain Controller.
Event ID: 2829
Severity: Information
151
Message: While promoting Read-only Domain Controller, the expected state objects could
not be found.
Event ID: 2831
Severity: Information
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
Severity: Information
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
Severity: Information
Message: While promoting a Read-only Domain Controller, failed to update the DNS
hostname on the server object.
Event ID: 2838
Severity: Information
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
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
suitable source server was not found from the current replication partners. This operation will
be retried.
Additional Data: Connection: %n%1
Source Server: %n%2
Event ID: 2846
Severity: Information
Message: The Knowledge Consistency Checker located a replication connection for the local
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.
Additional Data: Connection: %n%1
Current Partner Connection: %n%2
Logging level: 2
Event ID: 2847
Severity: Error
Message: The Knowledge Consistency Checker located a replication connection for the local
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.
Directory partition:%n%1
Network address:%n%2
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.
Directory partition:%n%1
Network address:%n%2
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
Severity: Information
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
Severity: Information
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
Severity: Information
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