Learn Active Directory - Read-Only Domain Controllers (RODC)

#Introduction

In episode 18 we built AD CS and understood how certificates strengthen digital trust inside a domain. In episode 19 we move to a problem companies with many offices often face: how do we serve authentication in small, remote branch offices with minimal IT staff?

Placing a writable domain controller (DC) in a branch looks like a sensible answer. But if that branch has no secure server room, the DC could be stolen. If the branch is run by non-IT staff, its local admin could abuse the database. This is where the Read-Only Domain Controller (RODC) was born.

#The Branch Office Problem

Three classic challenges make branch offices unsuitable for writable DCs:

• Slow or unreliable WAN connectivity — without a local DC, domain logon can take tens of seconds when the link to HQ is problematic.
• Low physical security — the DC sits in a small closet or storage room; anyone could steal its hard disk.
• Staff without IT competence — if local people get admin access to the DC, they could modify the directory or leak data.

The RODC is a DC designed for these three scenarios. The analogy: an RODC is like a read-only copy of a document stored in a remote location, while the original master stays at headquarters. In the remote location, people can read the document to work, but can't modify its contents.

#What Is an RODC

An RODC is a domain controller holding a read-only copy of the Active Directory database. All changes still happen on writable DCs, then replicate to the RODC one-way. An RODC is never a local source of change — if a user needs a password change, the RODC forwards it to a writable DC.

Some important facts about RODCs:

• Can be a Global Catalog and hold AD-integrated DNS (read-only mode).
• Cannot hold FSMO roles.
• Replication is one-way only: from a writable DC to the RODC.
• User passwords are only stored on an RODC if allowed by the Password Replication Policy.

#Key RODC Features

An RODC isn't just a "read-only DC". Four features make it safe for remote locations:

• Credential caching — passwords aren't stored arbitrarily; only allowed accounts have their passwords cached so they can log on when the link is down.
• Administrator role separation — a local RODC admin only manages that server itself, with no rights over other DCs or the domain.
• Filtered attribute set — sensitive attributes (e.g. certain data on service accounts) can be filtered so they never replicate to the RODC.
• Read-only DNS — AD-integrated DNS zones replicate one-way, so the zones can't be changed through the RODC.

#RODC vs Writable DC

The point: you sacrifice write capability at the branch location for security. The trade-off is worth it — because branch offices don't need to change data, they only need to serve logons.

#Password Replication Policy (PRP)

The Password Replication Policy determines which accounts' passwords may be stored (cached) on the RODC. This is the RODC's most distinguishing feature.

• Denied list — by default contains sensitive accounts like Domain Admins, Enterprise Admins, Schema Admins, and the krbtgt account. Their passwords will never exist on the RODC.
• Allowed list — regular accounts (e.g. branch users and computers) that need to log on when the link is down.

The PRP analogy is a guest list at a guard post: only people on the list may leave their access cards at the location. A thief who steals the RODC only gets passwords from that list — not the domain admin password.

Managing the PRP via PowerShell:

Add-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-Branch1" -AllowedList "Domain Users"
Add-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-Branch1" -DeniedList "Domain Admins","Enterprise Admins"
Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-Branch1"

#RODC Installation (Staged Installation)

RODC installation uses staged installation: the RODC account is prestaged first on a writable DC, then the branch server only needs to be promoted. The benefit: a branch representative without domain rights can complete the installation without seeing admin credentials.

Prestage the RODC account at the central DC:

Add-ADReadOnlyDomainControllerAccount -DomainControllerName "RODC-Branch1" -SiteName "Branch-1" -DomainName "corp.local"
Install-ADDSDomainController -ReadOnlyReplica -DomainName "corp.local" -SiteName "Branch-1" -Credential (Get-Credential)

After promotion, verify that one-way replication is running with repadmin /replsummary and check DC availability from a branch client with nltest /dsgetdc:corp.local.

#Managing an RODC

Once running, there are several routines to watch:

• Monitor the credential cache — use Get-ADDomainControllerPasswordReplicationPolicyUsage to see which accounts have passwords stored on the RODC. The fewer, the safer.
• Apply RODC-specific GPOs — restrict local logons, disable unnecessary services, and apply a strict password policy to RODC admin accounts.
• Separate RODC admin accounts — never use a domain admin account to log into an RODC; create a dedicated account with rights only on that server.

#Conclusion

In this episode you understand why the RODC is the right choice for branch offices:

• An RODC holds a read-only database with one-way replication from a writable DC.
• Credential caching is limited by the Password Replication Policy — sensitive accounts are never cached.
• Administrator role separation prevents branch staff from gaining domain rights.
• Staged installation lets non-IT staff promote a server without admin credentials.

The RODC is the bridge between the need for local service and the security demands of locations that can't be fully guarded. In episode 20, we step outside the on-premises network walls: Azure AD Connect and hybrid identity — syncing local identities to Microsoft Entra ID so one identity works in the cloud world. See you there!