Read-only domain controllers: getting the Password Replication Policy right

How an RODC works

An RODC holds a read-only copy of the directory but, by default, without account passwords. When a user authenticates against it, the RODC forwards the request to a writable controller. If the Password Replication Policy (PRP) allows it, the account's secret is then cached locally, so authentication keeps working even if the link to the central site goes down. If an RODC is stolen, only the cached secrets are exposed.

Allowed and denied groups

The PRP relies on two attributes of the RODC computer object: msDS-RevealOnDemandGroup (allowed accounts) and msDS-NeverRevealGroup (denied accounts). By default they reference two domain groups:

• Allowed RODC Password Replication Group, empty at installation;
• Denied RODC Password Replication Group, which contains among others Domain Admins, Enterprise Admins, Schema Admins, domain controllers and the krbtgt account.

Deny always wins over allow. The most sensitive built-in groups (Administrators, Account Operators, Server Operators, Backup Operators) are also in each RODC's deny list. Best practice is to create one allowed group per branch, containing only that site's users and computers, rather than filling the global allowed group.

What we often find during audits

• Domain Users added to the allowed list "to make it work", which amounts to caching the whole domain;
• privileged admin or service accounts missing from the deny list because they are not members of any group protected by default;
• accounts manually removed from the denied group to fix a one-off incident;
• RODCs whose msDS-RevealedList (secrets actually cached) and msDS-AuthenticatedToAccountList (accounts that authenticated) nobody ever reviews.

Explicitly add your custom admin groups, sensitive service accounts and every tier 0 account to the deny list.

Each RODC's own krbtgt account

Every RODC has its own krbtgt_ account followed by a number. The tickets it issues are signed with that key, which writable controllers recognise and handle cautiously. This separation limits the impact of a compromised RODC. Remember to reset these accounts periodically, just like the main krbtgt, and to delete orphaned krbtgt accounts left by former RODCs.

Delegated administrators and branch office risks

The managedBy attribute of the RODC object designates a user or group that gets local administration rights on the server, with no rights on the domain. This is administrator role separation. The group must still be treated as sensitive: a local administrator of the RODC can reach the cached secrets. Avoid placing privileged domain accounts in it, as they would then expose their own credentials on a less protected server.

What an audit checks

• the contents of each RODC's allowed and denied lists;
• privileged accounts among the secrets actually cached;
• who holds the managedBy attribute and what other privileges they have;
• when the RODC-specific krbtgt accounts were last reset.