How to Configure a Read-Only Domain Controller (RODC) on Windows Server 2012 R2

How to Configure a Read-Only Domain Controller (RODC) on Windows Server 2012 R2

A Read-Only Domain Controller (RODC) is a domain controller variant introduced in Windows Server 2008 that holds a read-only copy of the Active Directory database. RODCs are designed for deployment in branch offices or locations where physical security of the server cannot be guaranteed. Because the NTDS.dit on an RODC contains only a limited, controlled set of credentials (no passwords by default) and cannot originate any changes to the directory, the risk from physical compromise of the hardware is significantly reduced. This guide covers the prerequisites, installation, and configuration of an RODC on Windows Server 2012 R2.

Prerequisites

The following conditions must be met before deploying an RODC:

The forest functional level must be at least Windows Server 2003. The domain functional level must be at least Windows Server 2003. At least one writable domain controller running Windows Server 2008 or later must be reachable from the RODC location. The adprep /rodcprep command must have been run in the forest if upgrading from an older schema. Windows Server 2012 R2 automatically runs adprep during the DCPROMO process when needed. The account installing the RODC must be a Domain Admin, or the RODC computer account must be pre-created and delegated to a local administrator.

Import-Module ActiveDirectory

Stage 1 — Pre-Creating the RODC Account

Pre-staging the RODC computer account allows a local administrator (non-Domain Admin) to complete the actual server promotion at the branch office. This is a key security advantage of the RODC deployment model:

# Pre-create the RODC account from a writable DC at HQ
Add-ADDSReadOnlyDomainControllerAccount `
    -DomainControllerAccountName "DC-BRANCH-01" `
    -DomainName "contoso.com" `
    -SiteName "Branch-Office-01" `
    -DelegatedAdministratorAccountName "contosobranchadmin" `
    -InstallDns `
    -NoGlobalCatalog:$false `
    -Credential (Get-Credential) `
    -Confirm:$false

The -DelegatedAdministratorAccountName parameter specifies a non-Domain Admin account that is permitted to complete the RODC promotion and manage the resulting DC locally.

Stage 2 — Installing AD DS on the RODC Server

On the Windows Server 2012 R2 machine at the branch office, install the AD DS role before promotion:

# Install the AD DS role
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Stage 3 — Promoting the Server to RODC

Promote the server to an RODC using the Install-ADDSDomainController cmdlet with the -ReadOnlyReplica flag. If the account was pre-staged, the server will attach to the pre-created account:

Install-ADDSDomainController `
    -DomainName "contoso.com" `
    -ReadOnlyReplica `
    -SiteName "Branch-Office-01" `
    -InstallDns:$true `
    -ReplicationSourceDC "DC-LON-01.contoso.com" `
    -SafeModeAdministratorPassword (ConvertTo-SecureString "DSRM-P@ss2024!" -AsPlainText -Force) `
    -Force

If not pre-staging, use Domain Admin credentials:

Install-ADDSDomainController `
    -DomainName "contoso.com" `
    -ReadOnlyReplica `
    -SiteName "Branch-Office-01" `
    -Credential (Get-Credential "contosoAdministrator") `
    -InstallDns:$true `
    -SafeModeAdministratorPassword (ConvertTo-SecureString "DSRM-P@ss2024!" -AsPlainText -Force) `
    -Force

Configuring the Password Replication Policy

The Password Replication Policy (PRP) is the most important RODC-specific configuration. It controls which account credentials are cached on the RODC. There are two groups by default: the Allowed RODC Password Replication Group (accounts allowed to cache) and the Denied RODC Password Replication Group (accounts explicitly denied caching, which takes precedence). Sensitive accounts like Domain Admins, Enterprise Admins, and Schema Admins are pre-populated in the Denied group.

# Add branch office users to the Allowed PRP group
Add-ADGroupMember -Identity "Allowed RODC Password Replication Group" `
    -Members @("BranchUser1","BranchUser2","BranchPC-01$")

# View the current Allowed PRP group members
Get-ADGroupMember "Allowed RODC Password Replication Group"

# View the Denied PRP group members
Get-ADGroupMember "Denied RODC Password Replication Group"

# Check which accounts have their credentials cached on a specific RODC
Get-ADDomainControllerPasswordReplicationPolicy -Identity "DC-BRANCH-01" `
    -AuthenticatedAccounts

Best practice is to create a dedicated group for each RODC location containing only the users and computers at that branch, then add that group to the Allowed PRP group:

# Create a branch-specific group
New-ADGroup -Name "RODC-Branch01-CachedAccounts" `
    -GroupScope DomainLocal `
    -GroupCategory Security `
    -Path "OU=Groups,OU=Branch01,OU=Contoso,DC=contoso,DC=com"

# Add branch users and computers to the group
Add-ADGroupMember -Identity "RODC-Branch01-CachedAccounts" `
    -Members @("BranchUser1","BranchUser2","BranchPC-01$","BranchPC-02$")

# Add the group to the Allowed PRP
Add-ADGroupMember -Identity "Allowed RODC Password Replication Group" `
    -Members "RODC-Branch01-CachedAccounts"

Prepopulating the Password Cache

To ensure branch users can authenticate against the RODC even when the WAN link to HQ is down, prepopulate the credentials cache before the link goes down:

# Prepopulate credentials for allowed accounts
Invoke-ADDSDomainControllerPasswordReplicationPolicyAudit `
    -DCAccountName "DC-BRANCH-01" `
    -RevealSecrets

# Manually trigger password caching via repadmin
repadmin /rodcpwdrepl DC-BRANCH-01 DC-LON-01 contosoBranchUser1

Administering the RODC Locally

The delegated administrator account specified during pre-staging can manage local server functions on the RODC without being a Domain Admin. However, the RODC cannot originate changes — all AD writes must go to a writable DC. The RODC acts as a local authenticator for cached accounts when the WAN link is unavailable.

# Verify RODC configuration
Get-ADDomainController -Identity "DC-BRANCH-01" |
    Select-Object HostName, Site, IsReadOnly, IsGlobalCatalog,
    IPv4Address, OperatingSystem

RODC Filtered Attribute Set

Some sensitive attributes should never replicate to an RODC (such as private keys or application-specific secrets). The RODC Filtered Attribute Set (FAS) lists attributes that are stripped out during replication to RODCs. Schema Admins can add custom attributes to the FAS:

# View attributes in the RODC Filtered Attribute Set
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -Filter {searchFlags -band 512} -Properties lDAPDisplayName, searchFlags |
    Select-Object lDAPDisplayName, searchFlags

Monitoring RODC Replication

# Check replication status for the RODC
repadmin /showrepl DC-BRANCH-01

# View cached accounts on the RODC
Get-ADDomainControllerPasswordReplicationPolicy -Identity "DC-BRANCH-01" `
    -RevealedAccounts

# Force replication to the RODC
repadmin /syncall DC-BRANCH-01 /AdeP

Summary

Read-Only Domain Controllers on Windows Server 2012 R2 provide a secure way to extend domain authentication services to branch offices and locations with limited physical security. The combination of a read-only AD database, a controlled Password Replication Policy, and the ability to delegate local administration without granting Domain Admin rights makes the RODC an ideal solution for distributed environments. Proper PRP configuration — using dedicated groups per RODC and prepopulating credentials — is the key to ensuring reliable authentication during WAN outages while minimising the risk of credential exposure if the RODC hardware is compromised.