How to Set Up Windows Server 2016 Read-Only Domain Controller

A Read-Only Domain Controller (RODC) is a special type of Domain Controller introduced in Windows Server 2008 that holds a read-only copy of the Active Directory database. RODCs are designed for deployment in locations where physical security cannot be guaranteed, such as branch offices, edge sites, or remote data centers. Because the RODC does not store writable directory data and by default caches only limited credentials, the risk from physical compromise is significantly reduced compared to a full writable DC.

Key Features of RODCs

RODCs provide several security advantages. The Active Directory database on an RODC is read-only — no changes can be written to it directly. All changes must be made on a writable DC and then replicated to the RODC. The RODC does not replicate outward; replication flows only from writable DCs to the RODC. The Password Replication Policy (PRP) controls which user and computer account credentials are cached on the RODC. By default, almost no credentials are cached, meaning credential theft from the RODC yields minimal value to an attacker. The RODC also hosts a read-only DNS zone for local name resolution.

Prerequisites

Before deploying an RODC, ensure the following conditions are met. The domain functional level must be Windows Server 2003 or higher. All writable DCs must be running Windows Server 2003 or later. At least one writable DC running Windows Server 2008 or later must be accessible for replication. The forest must have been prepared with adprep /rodcprep if it was originally created before Windows Server 2008. The domain functional level should be Windows Server 2016 for the full feature set.

Preparing the Forest (if upgrading from older forests)

If the forest was created on Windows Server 2003 and has been upgraded, you may need to run forest preparation for RODCs:

adprep /rodcprep

This command modifies permissions on DNS application partitions to allow RODCs to replicate DNS zones. Run it once per forest from a machine with Schema Admin rights.

Pre-Staging an RODC Account

Pre-staging allows you to create the RODC computer account in Active Directory before the server is physically set up at the branch. This also lets you delegate installation to a non-admin user at the remote location. In Active Directory Users and Computers, right-click the Domain Controllers OU and select Pre-create Read-only Domain Controller account. Follow the wizard to specify the RODC name, site, DNS, and Global Catalog options, configure the Password Replication Policy, and optionally delegate installation rights to a specific user or group.

Add-ADDSReadOnlyDomainControllerAccount -DomainControllerAccountName "RODC-NYC" -DomainName "corp.local" -SiteName "NYC" -AllowPasswordReplicationAccountName "RODC_Allowed_PRP" -DenyPasswordReplicationAccountName "RODC_Denied_PRP" -Credential (Get-Credential)

Installing the RODC Role

On the server at the branch office, first install the Active Directory Domain Services role:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Then promote the server to an RODC using the pre-staged account:

Install-ADDSDomainController -DomainName "corp.local" -ReadOnlyReplica $true -SiteName "NYC" -InstallDns:$true -Credential (Get-Credential) -SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force)

If a pre-staged account was not created, the wizard can create one during promotion, but this requires Domain Admin credentials at the remote site — something that defeats the purpose of pre-staging in many scenarios.

Configuring the Password Replication Policy

The Password Replication Policy determines which accounts’ credentials may be cached on the RODC. The default policy denies caching for all highly privileged accounts. To add accounts to the allowed list, open Active Directory Users and Computers, right-click the RODC computer account, and select Properties. Navigate to the Password Replication Policy tab and add the groups or users whose passwords should be cached. Typically, add the security group that contains users and computers in that branch office.

Add-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-NYC" -AllowedList "NYC_Branch_Users","NYC_Branch_Computers"

Viewing Cached Credentials

To see which credentials are currently cached on an RODC:

Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-NYC" -AuthenticatedAccounts | Select-Object Name, ObjectClass

To view accounts whose credentials have been revealed (cached) on the RODC:

Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-NYC" -RevealedAccounts | Select-Object Name, ObjectClass

Administrator Role Separation

RODCs support delegated local administration. You can assign a domain user as the local administrator of an RODC without giving them any privileges on the rest of the domain. This allows a trusted person at a branch site to manage the RODC locally (rebooting, managing local services, etc.) without having Domain Admin rights.

Set-ADAccountControl -Identity "RODC-NYC" -Partition "DC=corp,DC=local"
dsmod computer "CN=RODC-NYC,OU=Domain Controllers,DC=corp,DC=local" -msl "CN=BranchAdmin,OU=NYC,DC=corp,DC=local"

Handling RODC Compromise

If an RODC is physically stolen or compromised, the impact is limited but you should act quickly. First, identify all credentials cached on the compromised RODC using the Revealed Accounts list. Then reset the passwords for all those accounts. Remove and delete the RODC computer account from Active Directory, which also forces a reset of the RODC’s own secrets. Only the accounts in the Revealed list need password resets — not the entire domain.

Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-NYC" -RevealedAccounts | ForEach-Object {
    Set-ADAccountPassword -Identity $_.SamAccountName -Reset -NewPassword (ConvertTo-SecureString "TempP@ss!$(Get-Random)" -AsPlainText -Force)
}

Best Practices

Always use pre-staged accounts when deploying RODCs to branch offices and delegate installation to local staff rather than sending Domain Admin credentials. Keep the PRP as restrictive as possible, caching only the accounts of users and computers at that specific site. Never place highly privileged accounts (Domain Admins, Enterprise Admins) in the allowed PRP list. Store the RODC computer account’s DSRM password securely. Monitor RODCs for replication health the same as writable DCs.

RODCs are an excellent solution for environments where physical DC security cannot be guaranteed. Proper configuration of the Password Replication Policy and delegation model turns a potentially dangerous remote site into a manageable, low-risk authentication point.