Planning and Deploying Read-Only Domain Controllers

Microsoft Corporation Published: June 2008

Abstract
A 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..................................................................1 Abstract....................................................................................................................................1 Contents..........................................................................................................................................3 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.................................................20 Advantages That an RODC Can Provide to an Existing Deployment.............................................22 Security...................................................................................................................................22 Manageability..........................................................................................................................23 Scalability...............................................................................................................................24 Prerequisites for Deploying an RODC............................................................................................25 Prepare a Windows 2000 or Windows Server 2003 Forest Schema for a Domain Controller That Runs Windows Server 2008.......................................................................................................26 Prepare a Windows 2000 or Windows Server 2003 Domain for a Domain Controller That Runs Windows Server 2008................................................................................................................27 Prepare a Forest for a Read-Only Domain Controller.....................................................................28 Known Issues for Deploying RODCs.............................................................................................29 Apply the RODC compatibility pack or plan a workaround for any known issue..........................29

Client operating system updates.................................................................................................34 Group Policy tools can apply updates inadvertently to SYSVOL on an RODC............................34 Adprep /rodcprep will log an error if the infrastructure master for an application directory partition is not available........................................................................................................................35 Applications can fail to register SPNs in a site with an RODC.....................................................36 Repadmin /PRP might return only a subset of accounts.............................................................36 RODC Placement Considerations..................................................................................................36 Placing RODCs with site link bridging.........................................................................................37 Placing RODCs without site link bridging....................................................................................38 How Operations in a Branch Site with an RODC Are Affected When the WAN Is Not Available......43 Client operations........................................................................................................................44 Application operations................................................................................................................45 Planning for Application Compatibility with RODCs........................................................................46 Directory-enabled applications.............................................................................................47 Impact of RODC on directory-enabled applications..............................................................48 Problem 1: Inefficient or failed Read operations...................................................................49 Problem 2: Failed Write operations......................................................................................49 Problem 3: Failed Write-Read-Back operations....................................................................50 Testing application compatibility for RODCs............................................................................50 Step 1: Set up the test environment.....................................................................................50 Step 2: Categorize the applications......................................................................................51 Step 3: Test your application................................................................................................52 Step 4: Fix broken or inefficient applications........................................................................53 Sites with Multiple Domain Controllers...........................................................................................53 Placing an RODC and a writable domain controller from the same domain in the same site.......53 Placing multiple RODCs from the same domain in the same site................................................54 Placing an RODC and a domain controller (writable or read-only) from different domains in the same site................................................................................................................................55 RODC Installation..........................................................................................................................57 Choosing whether to upgrade an existing domain controller or install a new domain controller...57 Upgrading an existing domain controller..................................................................................57 Known issues for upgrading domain controllers...................................................................59 Installing a new domain controller...........................................................................................60 Choosing whether to install the Server Core or the Full installation options and using BitLocker. 60 Using the Server Core installation for RODCs......................................................................61 Considerations for installing Server Core and upgrading domain controllers.....................62 Using BitLocker on RODCs.................................................................................................62 Using virtualization.....................................................................................................................63 Installing writable domain controllers..........................................................................................65 Installing RODCs........................................................................................................................65 Staged installation...................................................................................................................65

Direct installation.....................................................................................................................67 Installing AD DS from Media..........................................................................................................67 Direct Installation Method..............................................................................................................69 Performing a Staged RODC Installation.........................................................................................80 Performing a staged RODC installation by using the Windows interface.....................................81 Performing a staged RODC installation by using an answer file..................................................85 Creating the RODC account....................................................................................................85 Attaching a server to an RODC account..................................................................................87 Performing a staged RODC installation by entering installation parameters at the command line ...............................................................................................................................................89 Post-Installation Configuration.......................................................................................................90 Verify installation........................................................................................................................92 RODC Administration.....................................................................................................................93 Using remote management tools to administer an RODC...........................................................93 Using RSAT............................................................................................................................93 Using WinRM and WinRS.......................................................................................................94 Delegating local administration of an RODC...............................................................................94 Steps and best practices for setting up ARS............................................................................95 Use a security group instead of individual user accounts.....................................................97 Restrict logon with a privileged account in a site that has an RODC.....................................97 Cache the password for the delegated RODC administrator................................................98 Managing passwords and the PRP.............................................................................................98 Default PRP............................................................................................................................99 Modifying the PRP..................................................................................................................99 No accounts are cached........................................................................................................100 Most accounts are cached....................................................................................................101 Few accounts are cached.....................................................................................................101 Additional tasks and tools for managing passwords..................................................................102 Prepopulate the password cache for an RODC..................................................................102 View current credentials that are stored on an RODC........................................................102 Review whose accounts have been authenticated to an RODC.........................................102 Clear cached passwords that are cached on an RODC if it is stolen..................................103 Adding attributes to the RODC filtered attribute set...................................................................104 Default RODC FAS...............................................................................................................105 Installing Remote Server Administration Tools..............................................................................106 Displaying Administrative Tools.................................................................................................107 Administering the Password Replication Policy............................................................................108 Viewing the PRP......................................................................................................................108 Reviewing the accounts that are authenticated to an RODC.....................................................110

Clearing the authenticated accounts list....................................................................................112 Configuring the PRP.................................................................................................................112 Moving accounts from the Auth2 list to the Allow list.................................................................114 Reviewing PRP resultant policy................................................................................................115 Reviewing accounts with cached passwords on the RODC.......................................................116 Prepopulating the password cache for an RODC......................................................................118 See Also...................................................................................................................................121 Adding Attributes to the RODC Filtered Attribute Set....................................................................121 Determine and then modify the current searchFlags value of an attribute.................................121 Verify that an attribute is added to the RODC FAS....................................................................123 Appendix A: Technical Reference Topics......................................................................................123 Password changes on an RODC..............................................................................................123 DNS updates for clients that are located in an RODC site........................................................127 User and computer credentials.................................................................................................129 How the authentication process works on an RODC.................................................................129 Computer account authentication using an RODC................................................................130 Initial user logon process using an RODC.............................................................................132 Subsequent user logons after credentials are cached on the RODC.....................................134 Resource access using authentication by an RODC..............................................................135 How the Windows Time Service Works on an RODC................................................................136 Security mechanisms that are related to the Windows Time service on an RODC.................139 Registry entries that are specific to the Windows Time service forwarding mechanism on an RODC................................................................................................................................140 Appendix B: Events That Are Related to RODCs.........................................................................142 Appendix C: List of Acronyms Used in this Guide.........................................................................148

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 guide

The 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 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 guides

The 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. 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, 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 9

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 RODCand therefore no changes originate from RODCsother 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 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.

10

 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. 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. 11

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

Read-only SYSVOL
The 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 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. 12

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 RODC

There 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 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 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. 13 Failed logon 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.

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 FAS
RODCs 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 are using Active Directoryintegrated 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 14

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 cannotusing the RODC accountread 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. 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 15

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 credentiallike data. For procedures that show how to add an attribute to the RODC FAS, see RODC Administration.

Credential caching
As 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 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 16

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 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. 17

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-RevealOnDemandGroup 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 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

18

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 msDSAuthenticatedToAccountList. 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 msDSAuthenticatedToAccountList 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 RODC

This 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. 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. 19

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 controllerincluding other RODCsor perform any other 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 20

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. 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. RODCs contain a complete 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.

All read and write operations are possible on a writable domain controller.

Data replication between domain controllers

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. Writable domain controllers contain a complete copy of the directory database, including credentials for all accounts.

Data that is stored in the database

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

Only domain administrators can manage writable domain controllers.

21

Characteristic

RODC

Writable domain controller

software updates, performing offline defragmentation and backups, and so on.

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.

Security
The 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 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 ticketgranting 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.

22

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.

Manageability
The 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. 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

23

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.

Scalability
The 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. 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 largescale 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. 24

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 changesnot the entire fileswhen 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. 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 25

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 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.

26

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. 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 27

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.

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 Directoryintegrated 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. 28

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 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 issue
For 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.

29

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. 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 There is no Windows XP member computers to apply workaround for this IPsec policies from RODCs fail with issue. Win32 error 8219 (ERROR_POLICY_OBJECT_NOT_FOU ND). The same member computers can successfully apply policy from writable domain controllers. You may encounter 30

Issue

Affects

Impact

Workaround

this scenario when network connectivity for IPsec clients has been limited to Active Directory sites that contain RODCs but no writable domain controllers. 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) Client computers in the RODC site (perimeter network scenario) Client computers in the RODC site (perimeter network scenario) 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 join fails

In a perimeter network scenario where 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). 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.

There is no workaround for this issue

Domain join using RODC in the perimeter network fails.

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 31

Issue

Affects

Impact

Workaround

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 account. 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 computer that runs Windows Vista or Windows Server 200 8. 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.

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.

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

There is no workaround for this issue.

32

Issue

Affects

Impact

Workaround

marked as unpublished. 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. Active Directory Service Interfaces (ADSI) in Windows XP and Windows Server 20 03 requests a remote writable domain controller instead of a local RODC. 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.

Client computers in the RODC site (branch office scenario)

ADSI calls from Windows XP and Windows Server 2003 client computers 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.

Ensure that these client computers 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. There are two possible workarounds for this issue: Ensure that only domain controllers running Windows Server 2008 are present in the site that is closest to the RODC site. Disable automatic site coverage on domain 33

Domain controllers running Windows Server 20 03 perform automatic site coverage for sites with RODCs.

Windows Server 200 3 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.

Issue

Affects

Impact

Workaround

controllers running Windows Server 2003.

Client operating system updates

Unless 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 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 RODC

It 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.

34

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. 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 available
If 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

35

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).

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

If 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 accounts

If 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 36

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 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 bridging

If 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.

37

Site topology where Bridge all site links is enabled

Placing RODCs without site link bridging

In the following illustration, Sites A, B, and C have site links AB and BC 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.

38

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.

39

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.

40

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.

41

Create a site link bridge

Add a writable domain controller running Windows Server 2008 in the intermediary site (site B).

42

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

43

Client operations
The 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 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. 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 unlock after the duration 44

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.

Unlock a locked account

An account that is locked out on an RODC can be unlocked manually from any writable domain controller.

Operation

WAN online

WAN offline

has elapsed and the correct password is presented for logon.

Application operations
WAN 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 Authentication Password change LDAP read

Password cached Password not cached

X X X

Application targets a writable domain controller Application does not target a writable domain

Ineff

LDAP read

45

Operation

Operation condition

WAN online

WAN offline

controller (default) LDAP write Application targets a writable domain controller Application does not target a writable domain controller (default) and can chase a referral Application does not target a writable domain controller (default) and cannot chase a referral X

LDAP write

LDAP write

ADSI read ADSI write

Ineff

X X

Planning for Application Compatibility with RODCs

Because most Active Directoryenabled 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 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 46

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

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. 47

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). 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 48

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 operationsas ADSI applications do by defaultthe 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 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

49

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 WriteRead-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 RODCs

Before 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. 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. 50

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 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. 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 51

Read-Write application

Application type

Description

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.
Type of application Test Expected result

Read application Read-Write application

Disconnect the writable domain controller. Disconnect the writable domain controller, and then reconnect it.

All directory operations should pass. 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 readonly.

Write-Read-Back application

Disconnect the writable domain controller.

All directory operations should fail.

52

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. 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 site
This 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 53

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 cached to the writable Windows Server 2008 domain controller.

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 and if the user authenticates to RODC. This can result in inconsistent and undesirable behavior. LDAP read operations and write operations work, regardless of which domain controller is contacted. Password changes fail if the RODC is contacted. 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. 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

Placing multiple RODCs from the same domain in the same site
One 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 54

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 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 site
As 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.

55

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 domainin 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). 4. RODC1 returns the referral ticket-granting ticket (TGT) to the client computer (computer1). 56

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 controller
To 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 controller

Although 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 controller. You cannot make a Windows Server 2003 domain controller an RODC during the upgrade.

57

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.

58

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). 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 59

(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 controller

Many 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 BitLocker
Windows 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). 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. 60

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. 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. 61

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. 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 62

and Trusted Platform Module Recovery Information (http://go.microsoft.com/fwlink/? LinkId=120069).

Using virtualization
Server 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: 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 63

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 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). 64

Installing writable domain controllers

The 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 RODCs
There 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. 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 installation
Windows 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 65

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. 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 66

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 installation
If 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. 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 67

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 Creates installation media for an RODC into folder %s

Read-only domain controller

Create RODC %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 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 68

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 mediaon 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.

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 69

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

3. Review the information on the Operating System Compatibility page, and then click Next. Operating System Compatibility page

70

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

71

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

72

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

73

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

74

9. On the Specify Password Replication Policy page, click Add. Specify Password Replication Policy page

75

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

76

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 Next.

77

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

78

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 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> 79

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 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 80

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 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 interface

You 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 81

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. 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, readonly 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. -orTo 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 82

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 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 precreated 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 83

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 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.

84

Performing a staged RODC installation by using an answer file

Use 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 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 account

Use 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 85

SiteName=SiteName InstallDNS=Yes ConfirmGc=Yes ReplicationSourceDC=SourceDCName 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 RODCName

The fully qualified domain name (FQDN) of the domain where you are installing the RODC 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 GroupName1, GroupName2, User_Name1, Computer_Name1,

The single-label DNS name or the FQDN of the domain where you are installing the RODC. 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. 86

Placeholder

Description

SourceDCName

The FQDN of the domain controller from which you replicate the domain information (the installation partner).

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 account

Use 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. 87

Use the following table to replace the variables in the answer file with values that are appropriate for your organization.
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. 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.

DomainName\UserName

PathToDatabase PathToLogFiles PathToSYSVOL

The location of the directory database, for example, C:\Windows\NTDS. The location of the database log files, for example, C:\Windows\NTDS. 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>"

88

Performing a staged RODC installation by entering installation parameters at the command line
Although 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 Name2" /PasswordReplicationAllowed="User Name1" /PasswordReplicationAllowed=ComputerName1 /DelegatedAdmin=BranchAdminGroup

89

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.

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 90

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:
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. 91

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 installation
After 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. 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.

92

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 RODC

As 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 RSAT
To 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 Windows Server Backup. For more information, see Installing Remote Server Administration Tools.

93

Using WinRM and WinRS

You 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 RODC

Administrator 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 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

94

are not replicated to other domain controllers because RODCs do not perform outbound replication.

Steps and best practices for setting up ARS

You 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)

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:

95

 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.

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 builtin 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 96

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 Managed by Members RODC1 RODC1Mgrs StanB (the name of a user account in this branch) KarenC (the name of another user account in this branch) RODC2 RODC2Mgrs 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 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 97

an RODC as though it is not secure. You should never log on to itlocally or remotely with Terminal Services, by using highly privileged credentialssuch 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 RODCor log on to an RODC locallyunless 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 PRP

Depending 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 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.

98

Default PRP
By 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 PRP

By using a combination of the Allowed List and the Denied List for each RODC with the domainwide password replication groups, you have great flexibility to decide precisely which accounts 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

Most secureusers are

No offline access for anyonea 99

Example

Pros

Cons

(default)

authenticated by a writable WAN is required for logon. domain controller, and they get their Group Policy from the RODC for fast policy processing. Ease of password management this option is intended for customers who care most about the manageability improvements of RODC, and not security. Enables offline access for those users who need it, but provides more security than caching most accounts. More passwords are potentially exposed to an RODC.

Most accounts are cached

Few accounts are cached

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 cached

This 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. 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.

100

Most accounts are cached

This 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 cached

This example restricts the accounts that can be cached. Typically, you define this distinctly for each RODCeach 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 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.

101

Additional tasks and tools for managing passwords

You 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 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.

102

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 itor the new password is prepopulated on the RODCand 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.

103

You can also use the repadmin /prp command to delete the security principals from the msDSAuthenticatedToAccountList 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 set

This 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. 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 104

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 FAS

The 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

105

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 click Turn Windows features on or off. 106

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 Tools

If 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, and then click Display on the All Programs menu and the Start menu. 107

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 PRP

You 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 modify the PRP, and then click Properties. 4. Click the Password Replication Policy tab. An example is shown in the following 108

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 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 109

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 RODC

You 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 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. 110

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 Readonly Domain Controller, as shown in the following illustration. Accounts that are authenticated to the RODC

To view the authenticated accounts 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> 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. 111

Clearing the authenticated accounts list

In 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 PRP

You 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. 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. 112

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 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 113

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 h. To remove the account from the Deny list, run the command repadmin

/prp add

rodc2.hq.cpandl.com deny cn= RODC2users,ou=west,dc=hq,dc=cpandl,dc=com. /prp delete rodc2.hq.cpandl.com deny cn=RODC2users,ou=west,dc=hq,dc=cpandl,dc=com.

Moving accounts from the Auth2 list to the Allow list

The 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 114

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. 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 policy

You 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. 115

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.

Reviewing accounts with cached passwords on the RODC

In 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.

116

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 accounts 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 Readonly Domain Controller, as shown in the following illustration. Accounts that are cached on the RODC

117

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.

Prepopulating the password cache for an RODC

You 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 118

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 locationfor example, in a data centerbefore 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. 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 119

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 RODCs 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 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 120

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 Also
RODC 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 readonly 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.

Determine and then modify the current searchFlags value of an attribute

To 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. 121

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 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

122

Verify that an attribute is added to the RODC FAS

You 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 RODC

Users 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 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. 123

 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 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. 124

Type of password change operation

How the RODC replicates the password change

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 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. 125

Type of password change operation

How the RODC replicates the password change

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 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 126

Type of password change operation

How the RODC replicates the password change

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 site

When 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 Directoryintegrated zone, just as a secondary DNS server handles updates for zones that are not Active Directoryintegrated 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 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. 127

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 Registry entry EnableRSOForRODC MaximumRodcRsoQueueLength MaximumRodcRsoAttemptsPerCycle DsRemoteReplicationDelay Minimum value Either True or False 1 1 5 1000000 1000000 3600 Maximum value Default value True 300 100 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.

128

User and computer credentials

Credentials 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 ATT_UNICODE_PWD ATT_DBCS_PWD ATT_NT_PWD_HISTORY ATT_LM_PWD_HISTORY ATT_SUPPLEMENTAL_CREDENTIALS Description The Windows NT hash of users password The LAN Manager (LM) hash of the users password (deprecated) Password history for ATT_UNICODE_PWD Password history for ATT_DBCS_PWD Optional key material computed by authentication packages when a user changes a password

How the authentication process works on an RODC

This 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 Kellys 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.

129

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).

Computer account authentication using an RODC

Domain 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.)

130

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: 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. 131

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 RODC

When 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 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. 132

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

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 BobKellys credentials, it is able to satisfy requests for 133

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 BobKellys 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 RODC

After 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. BobKelly logs on after credentials are cached on RODC1

134

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 Bobs 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 Bobs logon. Bobs 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. Caution For an RODC to authenticate a logon request locally, both the user and computer credentials must be cached locally. If the users 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 RODC

When 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.

135

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 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 RODC

Reliable time synchronization is required for Kerberos authentication. Client computers can synchronize time from any domain controller, including an RODC. An RODC can synchronize time

136

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 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.

137

 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 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

138

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 RODC
There 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. 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 timesynchronization requests. If a request is received when the client computer has reached its perclient 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. 139

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 RODC
All entries in the following table are located in the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\Ntp Server Entry name (data type) ChainEntryTimeout (REG_DWORD) Description Default value Minimum value 4 Maximum value 16

Specifies the 4 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 response is processed on the RODC. Specifies the 128 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

ChainMaxEntries (REG_DWORD)

128

1024

140

beyond the maximum size. If the table is full and no expired entries can be removed, any incoming requests are discarded. ChainMaxHostEntries (REG_DWORD) Description: 4 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 discarded. Disables the 0 (FALSE, chaining chaining is not mechanism, disabled) 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. 4 16

ChainDisable (REG_DWORD)

141

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. 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 142

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. 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 143

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 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 144

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. 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. 145

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. 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 146

Message: The domain controller is trying to replicate the following NC from the following readonly 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 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 controllers 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.

147

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 DMZ: demilitarized zone FAS: Filtered Attribute Set FAZ: Find Authoritative Zone PRP: Password Replication Policy RODC: read-only domain controller

148