Content of this page:
- 1 - What is a read-only domain controller (RODC)?
- 2 - How to install and configure a RODC
- 3 - How to create an unattendend answer file for a domain controller (DC) promotion
- 4 - How to control a RODC credential caching and password replication
- 5 - How to check whether a user's password is, or can be, stored on a specific RODC
- 6 - Why shouldn't I use a domain-administrator account to log on to a read-only domain controller 
- 7 - How do I remove a cached password from a read-only domain controller (RODC)?
- 8 - To unlock an account, you need to re-establish read-write DC connectivity. The read-write DC will
        replicate a 0 lockoutTime value back to the RODC and unlock the account.

1. WHAT IS A READ-ONLY DOMAIN CONTROLLER (RODC)?
An RODC is a new domain controller (DC) mode in Windows Server 2008. It lets you store an Active Directory (AD) domain database read-only copy on the DC, but it has much more functionality than just a database read-only copy. The main features of an RODC are as follows:
* A read-only AD Domain Services (AD DS) database--Applications that need only database read access can use the RODC; however, any database changes must be made to a read-writable DC (RWDC), then
replicated back to the RODC.
  * Unidirectional replication--The RODC can't spread misinformation to the rest of the domain, even if a change is made on the RODC. This reduces the risk of a system-wide assault and reduces the complexity
of the replication structure.
  * Filtered attribute set configuration--A filtered attribute set isn't replicated to any RODC in the forest. If an RODC is compromised and the set modified, a Server 2008 RWDC won't replicate the values. A
Windows Server 2003 DC would. If possible, it?s best to have your forest function level set as Server 2008 so that Server 2003 servers won't be allowed in the forest in which they could compromise the
data. It?s also important to note that you can't add system-critical attributes to the RODC filtered attribute set.
  * Limited credential caching--An RODC doesn't store user or computer credentials (except for the RODC's computer account). When the RODC receives an authentication request, it forwards it to an
RWDC. The RODC then requests a copy of the credential so that it can service the request itself in the future. If the password-replication policy allows credential caching, the credential details will be
cached and the RODC can service logon requests (until the credentials change).
  * Separation of administrator capabilities--An RODC can designate users as server administrators without granting any domain or other DC permissions.
  * Read-only DNS--An RODC DNS doesn't allow client updates, nor does it register name-service resource records.
  * Two-stage RODC installation--The first installation stage is completed by a credentialed administrator. He or she creates an AD DS account for the RODC, with all the RODC's distributed AD database
information, such as its DC account name and its site location. Then, the admin can designate which users or groups can finish the second installation stage, usually completed at the remote location. Stage
two installs AD DS on the RODC and attaches the server to its AD DS account.

An RODC can replicate only from a Server 2008 RWDC, so no replication from Windows Server 2003 DCs or other Windows Server 2008 RODCs is possible.

2. HOW TO INSTALL AND CONFIGURE A READ-ONLY DOMAIN CONTROLLER
You create an RODC in Windows Server 2008 the same way you install a normal domain controller (DC), except you enable the RODC option in Additional Domain Controller Options. For a full Server 2008 installation, click Start, typedcpromoand press Enter. Doing so starts the Active Directory Domain Services Installation wizard. In the Additional Domain Controller Options dialog box, select the ?Read-only domain controller (RODC)? option.
When you select the RODC option, the system will prompt you to enter the group or users you want to have local administrator permissions. This RODC designation won?t give those groups or users
any privileges on the writable DCs.
If you perform an advanced-mode promotion, you can also configure the initial password- replication policy. Otherwise, you can configure the policy later.


3. HOW TO CREATE AN UNATTEND ANSWER FILE FOR A DOMAIN CONTROLLER (DC) PROMOTION
The Dcpromo answer file is a text file with a number of parameters that depend on the promotion or demotion type. A list of options is possible, but the best Windows Server 2008 alternative is to just run Dcpromo on a Server 2008 server and specify all the required options. Then, on the last screen, click Export Settings. Doing so will return a text file with the unattended-answer-file content needed to automate the Dcpromo action.
Note that you need to enter a SafeModeAdminPassword, and you might also want to set the server-promotion account password, unless you enter the password during the promotion process. The following code is an automatically generated Dcpromo answer file for a new RODC in an existing domain.

; DCPROMO unattend file (automatically generated by dcpromo)
; Usage:
; dcpromo.exe
/unattend:C:\Users\Administrator\Documents\rodccreate.txt
;
; You may need to fill in password fields prior to using the unattend
file.
; If you leave the values for "Password" and/or
"DNSDelegationPassword"
; as "*", then you will be asked for credentials at runtime.
;
[DCInstall]
; Read-Only Replica DC promotion
ReplicaOrNewDomain=ReadOnlyReplica
ReplicaDomainDNSName=savilltech.net
SiteName=Branch
InstallDNS=Yes
ConfirmGc=Yes
CreateDNSDelegation=No
UserDomain=savilltech.net
UserName=savilltech.net\administrator
Password=*
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\SYSVOL"
; Set SafeModeAdminPassword to the correct value prior to using the
unattend file
SafeModeAdminPassword=ENTERHERE
; Run-time flags (optional) ; CriticalReplicationOnly=Yes
; RebootOnCompletion=Yes

  To use the answer file, add the /unattend switch, as follows:

  dcpromo.exe /unattend:C:\temp\answerfile.txt

4. HOW TO CONTROL A READ-ONLY DOMAIN CONTROLLER'S (RODC'S) CREDENTIAL CACHING AND PASSWORD REPLICATION
By default, an RODC won't cache any user or computer passwords. You can change this policy through each RODC's unique Password Replication Policy (PRP).

To change the PRP, go to the RODC's Computer Properties and access the Password Replication Policy tab. Click the Allowed RODC Password Replication option to get the Add Groups, Users and Computers dialog box. Next, select the ?Allow passwords for the account to replicate to this RODC? check box.

Certain members of core groups, such as administrators and server operators, are denied by default, and denied status will always take preference over allowed status. Only those users' designated in the Allowed RODC Password Replication Group can have their credentials stored.

A typical policy would create a group for each branch office with an RODC, and add users in that branch office. Then the administrator would allow password replication for that branch-office group.

5. HOW TO CHECK WHETHER A USER'S PASSWORD IS, OR CAN BE, STORED ON A SPECIFIC READ-ONLY DOMAIN CONTROLLER (RODC)
Go to the RODC's Computer Properties window. Access the Password Replication Policy tab, and click Advanced. The computer will display the accounts that currently have their passwords stored on the RODC.

An administrator can use the Prepopulate Passwords button in the Advanced Password Replication Policy dialog box to set up accounts and passwords in advance of users logging on for the first time.

You can use utilities such as Proactive Password Auditor to confirm stored passwords. Accounts that aren't allowed password replication will be empty. The utility can also empty an RODC's memory.

6. Why shouldn't I use a domain-administrator account to log on to a read-only domain controller
   
The fact that it's an RODC isn't the crucial factor. RODCs typically aren't secure because they're in branch offices or somewhere else exposed to physical attack.

RODCs expressly deny caching domain-administrator account credentials. You should use your administrator credentials only on secure terminals. Someone that controls a box can run a keylogger to capture plain-text passwords, hijack the session with local control, or configure a bad policy to run at logon.

The best practice is to never log on to an RODC as a full domain administrator, and never access an RODC by remote desktop protocol (RDP) as a domain administrator. Instead, use Windows Remote Shell or Windows Remote Management to run RODC commands, or use Microsoft Management Console (MMC) in remote mode. Otherwise, you could give away credentials from a compromised box. This rule of thumb not only applies to RODCs but also to any potentially unsecure box.

You should decide how practical these options are for your environment. It's far easier to use RDP to access a remote box than run remote commands and MMC snap-ins.

7. How do I remove a cached password from a read-only domain controller?
You can't. There's no way to directly remove a password from an RODC. To achieve the same result, you can remove the password from the RODC's cache, as follows. First, delete the user from the list of users whose credentials the RODC is allowed to cache; then, reset the password. At the next replication cycle, the RODC will see that the user's password has changed and that it no longer has permission to cache the user's credentials. The RODC will remove the user's credentials from its cache.

8. Why doesn't the read-only domain controller (RODC) GUI show that it locked a user's account after the user entered an incorrect password too many times?
By design, RODCs lock user-account access after a designated number of failed password-entry attempts to prevent accounts from being hacked when RODCs lose read-write-DC connectivity. Typically, read-write DCs update multiple attributes with the lockout status. However, RODCs only update the user account's lockoutTime attribute, which reflects the time the account was locked out. The lockoutTime
attribute is stored in NT System Time format, which you can convert to normal time with the w32tm /ntte <value> command.
The RODC checks the lockoutTime attribute when a logon attempt is started. If the current time minus the lockoutTime value is less than the lockout-duration configured in the security policy, the RODC won't
let the user log in.
The GUI tools look at the UserAccountControl attribute-not the lockoutTime attribute-to determine if an account is locked, which is why the GUI tools fail to show the user-account's locked status.
To unlock an account, you need to re-establish read-write DC connectivity. The read-write DC will replicate a 0 lockoutTime value back to the RODC and unlock the account.