A read-only domain controller (RODC) holds a read-only copy of the AD DS database and, by default, no account passwords. It’s designed for branch offices with poor physical security, few users, slow links to the hub and little local IT expertise.
What an RODC does and doesn’t do
- Read-only database: changes must be made on a writable DC and replicate to the RODC. Replication is unidirectional: hub DCs never replicate from an RODC.
- No passwords by default: only accounts allowed by the Password Replication Policy (PRP) are cached.
- RODC filtered attribute set: attributes in this set (credential-like application data) never replicate to any RODC. It’s configured on the schema master; system-critical attributes can’t be added. Attributes in the set should also be marked confidential.
- Own krbtgt account: each RODC has its own
krbtgt_<number>account for cryptographic isolation of the tickets it issues, managed automatically at promotion and demotion. - Administrator role separation: a delegated user or group gets local administrator rights on that RODC only, without being a member of Domain Admins.
- No FSMO roles: operations masters must write to the database, so RODCs can’t hold them.
- DNS and GC: both are selected by default during RODC installation. Without a local DNS server, branch name resolution fails when the WAN is down; without a GC (or universal group membership caching for the site), branch users can’t sign in when the WAN is down.
Staged (delegated) installation
A staged installation splits deployment in two:
- A Domain Admin pre-creates the RODC account in ADAC or Active Directory Users and Computers (Pre-create a read-only domain controller account on the Domain Controllers OU), or with
Add-ADDSReadOnlyDomainControllerAccount. This sets the name, site, PRP and the delegated administrator, a single user or (recommended) a group. - At the branch, the delegated administrator attaches a server that is not joined to the domain by promoting it with Use existing RODC account (
Install-ADDSDomainController -UseExistingAccount).
The first RODC in a forest requires adprep /rodcprep, which needs Enterprise Admins credentials.
Password Replication Policy
The Password Replication Policy (PRP) controls which accounts’ credentials an RODC may cache. Accounts that are denied, or simply not listed, are never cached; if such a user can’t reach a writable DC, they can’t use AD DS resources. Default PRP:
| Account or group | Default setting |
|---|---|
| Administrators | Deny |
| Server Operators | Deny |
| Backup Operators | Deny |
| Account Operators | Deny |
| Denied RODC Password Replication Group | Deny |
| Allowed RODC Password Replication Group | Allow |
- The Allowed RODC Password Replication Group is domain-wide and empty by default; add branch users and computers (or groups) here, or to the RODC’s own allowed list (
msDS-RevealOnDemandGroup). - The Denied RODC Password Replication Group contains highly privileged accounts such as Domain Admins by default. Deny always wins, and removing its default members exposes administrator passwords to RODCs. Figure 1.2 shows how the denied and allowed lists combine.
- During installation, the PRP page appears only with Use advanced mode installation; the PowerShell equivalents are
-AllowPasswordReplicationAccountNameand-DenyPasswordReplicationAccountName. Get-ADDomainControllerPasswordReplicationPolicylists the allowed or denied list of an RODC (it errors against a writable DC);repadmin /prpreports from a writable DC and can show which accounts have been revealed to (cached on) an RODC.- An RODC caches only what the PRP allows. If it caches passwords for accounts outside the policy, a common cause is that the Enterprise Read-only Domain Controllers group or the RODC has been granted Replicating Directory Changes All on the domain, which makes it replicate secrets like a writable DC.
Common trap: Adding branch users to the Allowed RODC Password Replication Group while one of their groups is in the Denied group - deny takes precedence, so their passwords are still never cached and they can’t sign in when the WAN fails.
Common trap: Joining the branch server to the domain before attaching it to a pre-created RODC account - the server used for the second stage of a staged installation must not be domain-joined.