1.3 Read-Only Domain Controllers (RODCs) & Password Replication Policies

Read-Only Domain Controllers (RODCs) & Password Replication Policies

Branch offices, retail stores, and remote industrial facilities frequently require local directory authentication and DNS services to support business operations during wide-area network (WAN) outages. However, these remote facilities often lack physically secured server rooms, dedicated HVAC, and professional on-site IT personnel. Deploying a traditional writable domain controller in an insecure branch exposes the entire Active Directory forest to catastrophic credential harvesting and directory tampering if the server is stolen or physically compromised.

To address this security challenge, Windows Server provides Read-Only Domain Controllers (RODCs). An RODC hosts a read-only replica of the AD DS database, enforces strict Password Replication Policies (PRPs), and relies exclusively on unidirectional inbound replication.

---

1. RODC Architecture & Physical Security Perimeter

An RODC acts as a hardened perimeter outpost that delivers core directory services to branch clients without holding the keys to the entire corporate forest.

+-----------------------------------------------------------------------------+
|                     RODC SECURITY PERIMETER ARCHITECTURE                    |
|                                                                             |
|   [CORPORATE HEADQUARTERS]                      [REMOTE BRANCH OFFICE]      |
|   +--------------------------+                  +-------------------------+ |
|   | Writable DC (RWDC)       |                  | Read-Only DC (RODC)     | |
|   | - Read/Write NTDS.dit    |                  | - Read-Only NTDS.dit    | |
|   | - Stores ALL Passwords   | ====(WAN RPC)===>| - Stores NO Passwords   | |
|   | - Evaluates PRP Requests |  (Unidirectional |   by default            | |
|   | - Global Catalog         |     Inbound)     | - Read-Only DNS         | |
|   +--------------------------+                  | - Delegated Local Admin | |
|                                                 +-------------------------+ |
+-----------------------------------------------------------------------------+

Core Architectural Properties of RODCs:

1. Read-Only Directory Partitions: The Domain, Configuration, Schema, and application DNS partitions stored on an RODC cannot be modified locally. Any LDAP write request (LDAP ADD, MODIFY, or DELETE) sent by a client or application to an RODC returns an LDAP referral pointing the client to a writable domain controller (RWDC) at headquarters.
2. Unidirectional Inbound Replication: The RODC replicates directory updates inbound from writable domain controllers across the WAN. The RODC never replicates directory changes outbound to any other domain controller. Consequently, even if an attacker gains physical access and modifies the RODC database using offline raw disk editors, those malicious changes can never propagate to the rest of the Active Directory enterprise.
3. Read-Only DNS: The DNS Server role running on an RODC hosts read-only Active Directory-integrated DNS zones. The RODC does not permit direct dynamic DNS updates from clients; instead, it proxies or refers dynamic registration requests to a writable DNS server at headquarters.

---

2. Password Replication Policies (PRP) Mechanics

By default, an RODC does not store any user or computer account password hashes. When an RODC is provisioned, Active Directory creates a Password Replication Policy (PRP) that acts as an access control list (ACL) determining which credentials may be cached on the local branch server.

+-----------------------------------------------------------------------------+
|                   PASSWORD REPLICATION POLICY (PRP) MATRIX                  |
|                                                                             |
|   [DENIED LIST] (Takes Absolute Precedence)                                 |
|   -----------------------------------------------------------------------   |
|   - Domain Admins                                                           |
|   - Enterprise Admins                                                       |
|   - Schema Admins                                                           |
|   - Builtin\Administrators & Builtin\Account Operators                      |
|   - Builtin\Server Operators & Builtin\Backup Operators                     |
|   - Denied RODC Password Replication Group (Custom high-privilege accounts) |
|                                                                             |
|   [ALLOWED LIST] (Evaluated only if NOT Denied)                             |
|   -----------------------------------------------------------------------   |
|   - Allowed RODC Password Replication Group (Branch users & branch computers|
|     explicitly assigned to this specific branch location)                   |
+-----------------------------------------------------------------------------+

[!IMPORTANT] The PRP Precedence Rule: Deny entries always override Allow entries. If a user account is explicitly added to the Allowed RODC Password Replication Group but is also a member of Domain Admins (or any other group in the Denied list), the writable DC will strictly reject password caching for that user on the RODC.

---

3. Credential Caching Workflow & Kerberos Authentication

Understanding how an RODC handles branch authentication requests during online and offline WAN conditions is vital for enterprise network design and exam success.

+-----------------------------------------------------------------------------+
|                  RODC KERBEROS AUTHENTICATION FLOW (ONLINE)                 |
|                                                                             |
|   [BRANCH CLIENT]             [BRANCH RODC]             [HEADQUARTERS RWDC] |
|          |                          |                            |          |
|   (1)    |--- AS-REQ (Kerberos) --->|                            |          |
|   Initial|                          |--- (2) Proxies AS-REQ ---->|          |
|   Login  |                          |        over WAN            |          |
|          |                          |                            |          |
|          |                          |                            | (3) RWDC |
|          |                          |                            | Validates|
|          |                          |                            | & Checks |
|          |                          |                            | PRP      |
|          |                          |<-- (4) Returns TGT + ------|          |
|          |                          |        Password Hash       |          |
|          |                          |        (if Allowed)        |          |
|          |                          |                            |          |
|   (5)    |<-- Returns Kerberos TGT -| [Caches Hash Locally]      |          |
|   Auth OK|    signed by RODC krbtgt |                            |          |
+-----------------------------------------------------------------------------+

Step-by-Step Authentication Lifecycle:

1. First-Time Branch User Logon (Online WAN):

   • A branch workstation transmits a Kerberos Authentication Service Request (AS-REQ) to the local RODC.
   • Because the user's password hash is not yet stored on the RODC, the RODC cannot validate the pre-authentication timestamp. It forwards the request to an RWDC at headquarters.
   • The RWDC validates the user's credentials against its local directory. It then consults the RODC's Password Replication Policy.
   • If the user account is permitted by the PRP Allowed list and not restricted by the Denied list, the RWDC sends the Kerberos ticket back to the RODC along with a copy of the user's credential hash.
   • The RODC caches the credential hash locally in its NTDS.dit database and returns the Kerberos Ticket Granting Ticket (TGT) to the branch client.

2. Subsequent Branch User Logon (Offline WAN / Branch Isolation):

   • The WAN link to corporate headquarters fails.
   • When the branch user logs on, the RODC finds the cached credential hash in its local database, verifies the Kerberos pre-authentication timestamp, and issues a TGT locally.
   • The user successfully logs on and accesses local branch file and print shares without requiring WAN connectivity.

[!NOTE] The RODC krbtgt Account: Every RODC possesses its own unique secondary Kerberos Key Distribution Center account named krbtgt_<NumberedSuffix> (e.g., krbtgt_12345). Kerberos TGTs issued by the RODC are encrypted using this unique local key rather than the domain-wide krbtgt key. If an RODC is stolen, compromising its local krbtgt key does not compromise Kerberos tickets generated across the rest of the domain.

---

4. Password Pre-Population Strategies

In environments with intermittent WAN links or slow satellite connections, waiting for users to log on individually to populate the RODC cache can result in authentication delays or initial login failures during WAN outages. Administrators can proactively push credentials to the RODC using Password Pre-Population.

Managing PRP and Pre-populating Passwords via PowerShell

# Query the Password Replication Policy of a specific RODC
Get-ADDomainControllerPasswordReplicationPolicy `
    -Identity 'BR-RODC01' `
    -AllowedGroup `
    -DeniedGroup

# Add branch security groups to the Allowed PRP list
Add-ADDomainControllerPasswordReplicationPolicy `
    -Identity 'BR-RODC01' `
    -AllowedList 'CORP\Branch-Chicago-Users', 'CORP\Branch-Chicago-Computers'

# Pre-populate password hashes for all members of the branch user group
Get-ADGroupMember -Identity 'Branch-Chicago-Users' | 
    ForEach-Object {
        Add-ADDomainControllerPasswordReplicationPolicyUsage `
            -Identity 'BR-RODC01' `
            -Prepopulate `
            -UserAccount $_.SamAccountName
    }

# Audit all accounts whose passwords are currently cached on the RODC
Get-ADDomainControllerPasswordReplicationPolicyUsage `
    -Identity 'BR-RODC01' `
    -RevealedAccount

---

5. Read-Only DNS Zones & Name Resolution

When the DNS Server role is installed on an RODC, it hosts read-only copies of Active Directory-integrated DNS zones.

+-----------------------------------------------------------------------------+
|                     RODC READ-ONLY DNS UPDATE MECHANICS                     |
|                                                                             |
|   [BRANCH CLIENT]              [BRANCH RODC DNS]       [HQ WRITABLE DNS]    |
|          |                             |                       |            |
|   (1)    |--- Dynamic DNS Update ----->|                       |            |
|   Client |    (Registers Host A record)|                       |            |
|   Boot   |                             |--- (2) Forwards ----->|            |
|          |                             |    Update to RWDC     |            |
|          |                             |                       | (3) Writes |
|          |                             |                       | Record in  |
|          |                             |<-- (4) Replicates ----| AD-DNS     |
|          |                             |    Zone Delta         |            |
+-----------------------------------------------------------------------------+

• Read Operations: Local branch clients query the RODC DNS server for name resolution (e.g., resolving local file servers or intranet resources) and receive instant, low-latency responses directly from the read-only zone.
• Write / Dynamic Update Operations: When a client workstation boots or changes its DHCP IP address, it attempts a Dynamic DNS update. Because the RODC DNS zone is read-only, the RODC DNS server responds with an RCODE referral or proxies the dynamic update request across the WAN to a writable DNS server running on an RWDC.

---

6. Administrator Role Separation (Delegating Local Server Admin)

In distributed organizations, local branch staff often need administrative rights to manage the physical server hardware, install printer drivers, restart crashed services, or execute OS patch reboots. However, granting branch personnel Domain Admins or Server Operators rights creates an unacceptable enterprise security vulnerability.

RODCs resolve this dilemma through Administrator Role Separation:

# Delegate local administrator permissions on the RODC to a branch user
Set-ADDomainControllerPasswordReplicationPolicy `
    -Identity 'BR-RODC01' `
    -DelegatedAdministratorAccountName 'CORP\Chicago-LocalAdmin'

How Administrator Role Separation Operates:

• The delegated user (Chicago-LocalAdmin) is automatically placed into the local BUILTIN\Administrators security group on that specific RODC instance.
• The user gains complete administrative control over the local Windows Server operating system: they can log on locally or via RDP, manage disks, restart the server, and perform OS maintenance.
• Zero AD DS Privilege: The user is granted no rights within the Active Directory domain, cannot create or modify domain user accounts, cannot alter Group Policy, and has no administrative rights on any other domain controller in the enterprise.

---

7. Incident Response: Branch Compromise & Password Reset Protocol

If an RODC is physically stolen from a branch office, or if the underlying virtualization storage volume is compromised, administrators must execute the RODC Incident Response Protocol immediately.

+-----------------------------------------------------------------------------+
|                   RODC COMPROMISE INCIDENT RESPONSE PROTOCOL                |
|                                                                             |
|   [1. IDENTIFY EXPOSURE] ---> Run Get-ADDomainControllerPasswordReplication |
|                               PolicyUsage -RevealedAccount                  |
|                                     |                                       |
|                                     v                                       |
|   [2. MASS PASSWORD RESET]---> Immediately reset passwords for ALL exposed  |
|                               user and computer accounts                    |
|                                     |                                       |
|                                     v                                       |
|   [3. PURGE RODC METADATA]---> Delete the RODC computer object in ADUC and  |
|                               reset the RODC's krbtgt account               |
+-----------------------------------------------------------------------------+

Compromise Remediation Steps:

1. Query the surviving writable DC to identify the exact list of accounts cached on the compromised RODC:

   $ExposedAccounts = Get-ADDomainControllerPasswordReplicationPolicyUsage `
       -Identity 'BR-RODC01' `
       -RevealedAccount
   

2. Open Active Directory Users and Computers, right-click the compromised RODC computer object, and select Delete. In the deletion wizard, select the option: "Reset all passwords for user accounts that were cached on this read-only domain controller".
3. The deletion wizard resets the passwords for all revealed accounts across the domain and resets the unique krbtgt account associated with that RODC, completely neutralizing the attacker's ability to use harvested hashes.