Read-Only Domain Controller Security: Placing, Delegating and Protecting RODCs

A read-only domain controller is only as safe as its Password Replication Policy and the permissions on its computer object, and both drift quietly after deployment. Read-only domain controllers (RODCs) exist so that branch offices, factories and other sites with limited physical security can authenticate users locally without holding a full writable copy of Active Directory. That design limits what a stolen server exposes, but it adds its own controls: which passwords may be cached, who administers the box locally, a separate krbtgt account for each RODC, and attributes that an attacker can change to turn a branch server into a route to the whole domain. This guide covers placing, configuring, delegating, monitoring and recovering RODCs. It goes deeper than the AD Domain Controller Hardening Guide, which covers writable DC baselines, and is written for Active Directory engineers, identity architects and security operations teams.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The Password Replication Policy is the security boundary. Microsoft describes the PRP as an access control list that decides which passwords an RODC may cache; the Denied List always wins over the Allowed List.
• Protect RODC computer objects as Tier Zero. Anyone who can edit an RODC's allow list, deny list or managedBy attribute can make it cache privileged credentials, so control of the object is control of the domain.
• Cache as few passwords as possible. Cache only the users and computers of that site, through site-specific groups, and never administrators or service accounts with domain-wide rights.
• Delegate local administration without domain rights. Administrator role separation lets branch staff patch and maintain the server without becoming Domain Admins, but the delegated group itself must be tightly controlled.
• Plan the stolen-RODC response before you need it. Cached passwords cannot be erased from a lost server; you delete its account, reset every cached credential, export the list and rebuild.

How identity and access work in an RODC

An RODC holds every Active Directory object and attribute that a writable DC holds, except account passwords and the attributes in the RODC filtered attribute set. No change can be made to its database: LDAP clients that try to write receive a referral to a writable DC, and replication is one way, so writable partners never pull changes from an RODC. This unidirectional model applies to AD DS and SYSVOL; Microsoft notes that other DFS Replication shares on the same server remain bidirectional. DNS on an RODC is read-only and does not accept direct client updates.

Credential caching and the Password Replication Policy

By default an RODC caches no user or computer passwords apart from its own computer account and its own krbtgt account. When a user without a cached password logs on, the RODC forwards the authentication to a writable DC. If the account passes the PRP, the RODC can then request and cache that password, and serve later logons itself. The PRP is stored on each RODC computer account in four attributes:

The defaults are deliberately restrictive. The Allowed RODC Password Replication Group has no members. The Denied RODC Password Replication Group contains Enterprise Domain Controllers, Enterprise Read-Only Domain Controllers, Group Policy Creator Owners, Domain Admins, Cert Publishers, Enterprise Admins, Schema Admins and the domain krbtgt account, and the default Denied List adds Administrators, Server Operators, Backup Operators and Account Operators. Built-in groups cannot be nested into the two PRP groups because those are domain local groups, which is why they appear directly on the Denied List.

Choosing a caching model

For most organisations the site-specific model is the right answer: one group per RODC (or per site) added to that RODC's Allowed List, populated with the users and workstations based there, reviewed against msDS-AuthenticatedToAccountList. Accounts listed for caching can be prepopulated so users can log on even before their first online logon. Small organisations with good links often run the no-cache default; large estates need automation to keep group membership aligned with HR data.

The per-RODC krbtgt account

Each RODC has its own krbtgt account and key, linked to the RODC computer object through the msDS-KrbTgtLink attribute. The RODC signs the TGTs it issues with this key. A TGT signed by another DC is forwarded to a writable DC. Because the key is unique, a stolen RODC does not expose the domain krbtgt, and a writable DC that receives a ticket issued by an RODC checks the account against that RODC's PRP before trusting it. Rotating an RODC's krbtgt is therefore separate from the domain krbtgt rotation covered in the AD Domain Controller Hardening Guide.

Admin roles and privileged access

Administrator role separation lets you give a branch user or group local administrative rights on one RODC without any domain rights or rights on other DCs. The delegated administrator can install drivers and updates, restart services and perform local maintenance, but is not a member of Domain Admins or the built-in Administrators group. During promotion it is set with the delegated administrator option, and the same principal is recorded in the RODC computer object's managedBy attribute.

• Delegate to a group, not a person: a site-specific "RODC admins" group makes joiners and leavers a membership change rather than an RODC reconfiguration.
• Keep delegated admins out of the Allowed List: a local administrator on the RODC can reach every secret cached there, so caching their own privileged accounts adds nothing but risk.
• Treat the delegated group as sensitive: local admin on an RODC is not domain admin, but it does expose the RODC's krbtgt key and cached passwords. Who can change that group's membership matters as much as who is in it.
• Who can edit the computer object: write access to managedBy, msDS-RevealOnDemandGroup or msDS-NeverRevealGroup, ownership, or GenericAll or GenericWrite over the object is a path to domain compromise. SpecterOps found such rights are often left with local IT teams after provisioning. See the Active Directory Delegation guide for designing delegation that avoids this.
• Who can edit the allow-list group: anyone able to add members to a group on an RODC's Allowed List decides which passwords the RODC may cache. Restrict that right to Tier Zero administrators.

Staged deployment as a privilege boundary

Staged installation splits the work: a Domain Admin pre-creates the RODC account (Add-ADDSReadOnlyDomainControllerAccount, shown in Active Directory Administrative Center as an Unoccupied Domain Controller Account) with its site, DNS and global catalog options, PRP and delegated administrator fixed at that point. The delegated branch administrator can then attach the server, which must have the same name, using Install-ADDSDomainController with -UseExistingAccount. Staging requires adprep /rodcprep to have run in the forest. This keeps domain-level decisions with Tier Zero while allowing local staff to build the hardware. Microsoft warns against storing the Directory Services Restore Mode password in scripts or command lines, because it gives logon to the DC in DSRM.

Integrations, API tokens and service accounts

RODCs change how applications and non-human identities behave at a site, and service accounts are the most common reason someone widens the PRP.

• Applications that write: an AD-integrated application at the branch must follow LDAP referrals to write and must tolerate write outages when the hub is unreachable. Applications that cannot do this are not a reason to deploy a writable DC in an insecure site; fix the application or host it centrally.
• Service accounts: only cache a service account if a service at that site must start during a WAN outage, and only if the account has no rights beyond that site. Accounts with domain-wide rights, SPNs used across many servers, or membership of privileged groups belong in the Denied RODC Password Replication Group. Group managed service accounts are preferable because their passwords rotate automatically. See the AD service accounts with SPNs guide.
• Computer accounts: cache workstation and member server accounts for the site so machines can authenticate offline. Computer passwords rotate every 30 days by default, which limits how long a stolen copy stays useful.
• Management agents: backup, monitoring and endpoint agents on the RODC run with local system rights and can read cached secrets. Treat their vendors and update channels as part of the RODC's trust boundary and keep their own credentials out of the Allowed List.
• RODC filtered attribute set: applications that store credential-like data in custom attributes (keys, passwords) can add those attributes to the filtered set so they never replicate to RODCs. System-critical attributes cannot be added, and the change is made on the schema master.

Logging and detection

Microsoft notes that at default log settings no replication event shows that a password was cached on an RODC, so detection depends on watching configuration and the tracking attributes rather than waiting for an alert.

You can list each RODC's krbtgt link with repadmin /showattr filtered on msDS-KrbTgtLink, and enumerate PRP attributes with an LDAP query from a management host. Feed both into a weekly drift report. Attack path tools such as BloodHound and PingCastle highlight dangerous rights over RODC objects; see the BloodHound and Active Directory Attack Path Guide and the Active Directory Security Monitoring and Event IDs Guide.

Abuse paths to detect

Hardening baseline

1. Decide whether you need an RODC at all. If the site has a reliable link and can tolerate logons failing during an outage, no DC may be the lowest risk option. Deploy an RODC only where local authentication is required and a writable DC cannot be physically secured.
2. Prepare the forest. Run adprep /rodcprep once, make sure a writable DC is available to every RODC site, and confirm the domain and forest functional levels meet Microsoft's stated prerequisites.
3. Stage, do not hand out Domain Admin. Pre-create each RODC account with its site, PRP and delegated administrator group, then let the branch team attach the server.
4. Set the PRP per RODC. Add one site-specific group to the Allowed List, keep the default Denied List, and add every Tier Zero and domain-wide service account to the Denied RODC Password Replication Group. Prepopulate the site's users and computers if offline logon is needed.
5. Lock down the object. Remove ownership and write rights on RODC computer objects and allow-list groups from anyone outside Tier Zero, including the delegated branch group.
6. Harden the host. Apply the same baseline as writable DCs (patching, Credential Guard where supported, no browsing, no unneeded roles), encrypt the volumes holding the AD database and system, and restrict console and remote access. The writable DC baseline is in the AD Domain Controller Hardening Guide.
7. Turn on auditing. Enable directory service changes auditing on writable DCs, collect 1699 and 4768, and schedule the msDS-RevealedList report.
8. Test, then document rollback. Pilot one site, unplug its WAN link in a maintenance window to confirm offline logon works for intended users only, and record how to revert the Allowed List if users are locked out (adding a user to the site group and prepopulating restores service without widening the policy).

Responding to a lost or compromised RODC

There is no way to erase cached passwords from a server you no longer control. Microsoft's procedure is to delete the RODC computer account from the Domain Controllers OU on a writable DC. The Deleting Domain Controller dialog offers three options: reset all passwords for user accounts cached on the RODC (selected by default), export the list of cached accounts to a file (selected by default), and reset all passwords for computer accounts cached on it (not selected by default). Select all three: computer resets mean those machines must be rejoined, but they close the window an attacker would otherwise have. Then review whether anyone could have changed the PRP before the theft, check msDS-RevealedList history in your reports for privileged accounts, and rebuild the RODC from a clean install. If a Tier Zero account was ever cacheable, treat it as a domain compromise and follow the Active Directory Domain Compromise Response Playbook.

Common misconfigurations

• Adding users directly or using broad groups on the Allowed List: adding Domain Users to every RODC "to stop helpdesk calls" turns each branch server into a copy of most of the domain's passwords.
• Trusting the default groups instead of the attributes: the protection comes from the actual msDS-NeverRevealGroup values on each RODC. If someone removed the Denied group from one RODC, the default group membership no longer helps. Audit each RODC, not the template.
• Privileged accounts outside the default denied groups: custom admin groups, helpdesk groups with reset rights, backup service accounts and tier 1 server admins are not in the Denied RODC Password Replication Group unless you add them.
• Branch IT owning the RODC object: whoever created the object or holds GenericAll over it can edit the PRP. Provisioning scripts that leave these rights behind are a common path found in assessments.
• No rehearsed loss procedure: organisations that lose a branch server often delete the account without the reset options, or forget computer accounts, leaving cached credentials valid for weeks.

Framework mapping

Practitioner checklist

• Inventory every RODC and unoccupied RODC account, with its site, delegated administrator group and krbtgt link.
• Export msDS-RevealOnDemandGroup and msDS-NeverRevealGroup for every RODC and confirm no Tier Zero principal can be cached.
• Add custom admin, helpdesk and domain-wide service account groups to the Denied RODC Password Replication Group.
• Replace broad Allowed List entries with one site-specific group per RODC and review it against msDS-AuthenticatedToAccountList quarterly.
• Remove ownership, GenericAll, GenericWrite and write access to managedBy and PRP attributes from anyone outside Tier Zero.
• Enable directory service changes auditing and alert on Event 5136 for PRP attributes, managedBy and PRP group membership.
• Schedule a weekly msDS-RevealedList report and treat any privileged account in it as an incident.
• Encrypt RODC volumes and record the physical location and custodian of each server.
• Write and rehearse the stolen-RODC procedure with all three reset and export options selected.
• Track key metrics: number of cached accounts per RODC, privileged accounts cacheable (target zero), non-Tier Zero principals with control of RODC objects (target zero), time from loss report to account deletion.

Standards and references

• Microsoft Learn: Install an Active Directory Read-Only Domain Controller
• Microsoft Learn: Password Replication Policy
• Microsoft Learn: AD DS Read-Only Domain Controllers
• Microsoft Learn: RODC Frequently Asked Questions
• Microsoft Learn: Securing Accounts After an RODC Is Stolen
• SpecterOps: At the Edge of Tier Zero, The Curious Case of the RODC
• MITRE ATT&CK: Golden Ticket
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: AD Domain Controller Hardening Guide · Active Directory Delegation · Active Directory ACL and Delegation Hygiene Guide · PingCastle Active Directory Assessment Guide