How to Set Up a Read-Only Domain Controller (RODC)

A Read-Only Domain Controller (RODC) is designed for locations where you need local authentication but can’t guarantee the physical security of the server. Typically a branch office, a retail site, or anywhere a full writable DC would be a liability if the hardware were stolen or tampered with. An RODC holds a read-only copy of the AD database and, critically, caches only the credentials you explicitly allow it to, so a compromised RODC doesn’t hand over every password in the domain.

• RODCs require at least one writable Windows Server 2008 or later DC already in the domain
• By default, an RODC caches no user passwords at all. You control exactly what it’s allowed to cache via the Password Replication Policy
• RODCs can’t originate changes to AD. All writes are forwarded to a writable DC
• Ideal for branch offices with poor physical security or unreliable WAN links back to the main site
• You can delegate local admin rights on an RODC without granting any domain-level privileges

Step 1: Pre-create the RODC account (optional but recommended)

For branch deployments where a non-admin will be doing the physical install, pre-stage the RODC computer account from a writable DC. This lets you configure the Password Replication Policy and delegate installation rights before the physical server ever touches the domain:

Open Active Directory Users and Computers, right-click the Domain Controllers OU, and choose “Pre-create Read-only Domain Controller account.” Work through the wizard, specifying the server name and which user or group is allowed to complete the installation on-site.

Step 2: Configure the Password Replication Policy

This is the setting that actually makes an RODC safe to deploy in a low-security location. On the account’s Password Replication Policy tab, add only the users and groups whose credentials should be cached locally. Typically just the staff based at that branch. Everyone else authenticates through the RODC but their credentials are never stored on it, so physical theft of the server doesn’t expose domain-wide passwords.

A sensible default is to explicitly deny caching for high-privilege groups (Domain Admins, Enterprise Admins, Schema Admins) even though they’re excluded by default. Being explicit here avoids surprises if someone changes the default policy later.

Step 3: Install the RODC role

If you pre-staged the account, run this on the target server to complete the installation and attach it to the pre-created account:

Install-ADDSDomainController -DomainName "yourdomain.com" -ReadOnlyReplica -SiteName "BranchOffice" -InstallDns

PowerShell will prompt for a Delegated Administrator account (the local admin for this RODC only) and the Directory Services Restore Mode password. Once it completes and replication finishes, confirm the RODC shows up correctly in Sites and Services under the right site.

Step 4: Delegate local administration

One of the more underused features of RODCs is delegated local administration. You can let a branch office IT contact manage the RODC locally (patching, restarts, local troubleshooting) without giving them any domain-level rights at all. Configure this via Set-ADComputer -Identity RODC01 -PrincipalsAllowedToDelegateToAccount or through the “Managed By” tab, depending on your Windows Server version.

When an RODC isn’t the right fit

RODCs aren’t a good fit for sites that host applications requiring writable DC access (some LOB apps write directly to AD), and they add complexity if your branch offices are well-secured server rooms with reliable WAN links back to head office, in that case a standard writable DC or just relying on the WAN link may be simpler. Use RODCs specifically where physical security is the concern, not as a default branch office pattern.

For official guidance, see Microsoft’s Windows Server documentation.