How to Set Up Multi-Factor Authentication on Windows Server 2022

What Is a Read-Only Domain Controller and When to Use It

A Read-Only Domain Controller (RODC) is a special type of Active Directory domain controller introduced in Windows Server 2008 that holds a read-only, non-writable copy of the AD database. RODCs were designed primarily for deployment in branch offices, remote sites, and locations where physical security cannot be guaranteed. Because the RODC cannot be used to write changes to AD, any modifications made to the AD database on the RODC are rejected, dramatically reducing the blast radius if the server is stolen or compromised.

Key characteristics of an RODC include: it does not perform outbound replication to other DCs (all replication is inbound from a writable DC), it uses a filtered attribute set that excludes sensitive attributes from replication, it caches only the passwords of users explicitly permitted via the Password Replication Policy (PRP), and it allows delegation of local administration to branch office personnel without granting them Domain Admin rights.

RODC Prerequisites

Before deploying an RODC, verify the following requirements are met:

• The forest functional level must be Windows Server 2003 or higher.
• At least one writable Windows Server 2022 (or later) DC running the PDC Emulator FSMO role must be available and reachable.
• DNS must be functional; the RODC will host a read-only copy of the DNS zone.
• The account used for promotion must be a member of Domain Admins or have been delegated specifically for RODC installation.
• The server being promoted must be joined to the domain already, or you must use the two-stage installation method (staging the account first, then attaching the server).

Install the AD DS role on the server that will become the RODC:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Staging the RODC Account (Two-Stage Installation)

The two-stage method separates account creation (performed by a Domain Admin) from server attachment (which can be delegated to a local administrator). This is the recommended approach for branch deployments where you want to delegate the final installation step.

On a writable DC, create the RODC account using PowerShell. This stages the computer account in AD with the RODC flag set, allowing a delegated user to complete the promotion later:

Add-ADDSReadOnlyDomainControllerAccount `
  -DomainControllerAccountName "RODC-BRANCH01" `
  -DomainName "corp.example.com" `
  -SiteName "BranchOffice-NYC" `
  -AllowPasswordReplicationAccountName "Branch-Users","Branch-Computers" `
  -DenyPasswordReplicationAccountName "Domain Admins","Enterprise Admins","Schema Admins" `
  -DelegatedAdministratorAccountName "branchlocaladmin" `
  -Credential (Get-Credential)

At this point the computer account RODC-BRANCH01$ exists in AD in the Domain Controllers OU with the msDS-IsReadOnly attribute set to TRUE. The delegated administrator can now complete the installation from the branch office server without needing Domain Admin rights.

Promoting the Server as an RODC

On the target server at the branch office, run the following to attach the server to the pre-staged account and complete the RODC promotion. If using the two-stage method, this can be run by the delegated local admin:

Install-ADDSDomainController `
  -DomainName "corp.example.com" `
  -ReadOnlyReplica:$true `
  -SiteName "BranchOffice-NYC" `
  -UseExistingAccount:$true `
  -Credential (Get-Credential) `
  -InstallDns:$true `
  -Force:$true

For a single-stage RODC promotion (Domain Admin running the full promotion directly):

Install-ADDSDomainController `
  -DomainName "corp.example.com" `
  -ReadOnlyReplica:$true `
  -SiteName "BranchOffice-NYC" `
  -AllowPasswordReplicationAccountName @("Branch-Users","Branch-Computers") `
  -DenyPasswordReplicationAccountName @("Domain Admins","Enterprise Admins","Schema Admins","Cert Publishers","Group Policy Creator Owners") `
  -DelegatedAdministratorAccountName "corpbranchadmin" `
  -InstallDns:$true `
  -Credential (Get-Credential) `
  -Force:$true

The server will restart after promotion. Upon reboot it will begin initial replication from a writable DC in the hub site.

Password Replication Policy (PRP) Explained

The Password Replication Policy is the mechanism that controls whose credentials the RODC is allowed to cache locally. By default, the PRP denies caching for sensitive accounts (Domain Admins, KRBTGT, etc.) and has an empty allowed list — meaning no passwords are cached initially.

To add users to the Allowed PRP (their passwords will be cached at the RODC after their first successful authentication):

Set-ADAccountControl -Identity "RODC-BRANCH01" -PasswordNeverExpires $false

# Add to Allowed list
Add-ADDomainControllerPasswordReplicationPolicy `
  -Identity "RODC-BRANCH01" `
  -AllowedList "CN=Branch-Users,OU=Groups,DC=corp,DC=example,DC=com"

To add to the Denied list (these accounts will never be cached, regardless of the Allowed list):

Add-ADDomainControllerPasswordReplicationPolicy `
  -Identity "RODC-BRANCH01" `
  -DeniedList "CN=Domain Admins,CN=Users,DC=corp,DC=example,DC=com"

View the current PRP for an RODC:

Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-BRANCH01" -Allowed
Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-BRANCH01" -Denied

The design philosophy: only accounts that regularly log on at the branch should be in the Allowed list. If the RODC is compromised, an attacker only has access to credentials that were cached at that device — not to any hub-site admin accounts.

Credential Caching and How It Works

When a user in the Allowed PRP list logs on at the branch for the first time after RODC deployment, the RODC forwards the authentication request to a writable hub DC. The hub DC checks the PRP, and if the account is on the Allowed list, it replicates the user’s password hash to the RODC. Subsequent logon requests from that user are served directly by the RODC without a hub-site round trip — essential for branch offices with unreliable WAN connectivity.

To see which accounts currently have credentials cached on the RODC:

Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-BRANCH01" -AuthenticatedAccounts

To see revealed (cached) accounts specifically:

Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-BRANCH01" -RevealedAccounts

Prepopulating the Credential Cache

Rather than waiting for users to log on before their credentials are cached, you can prepopulate the cache proactively. This ensures branch users can authenticate even if the WAN link is down from day one:

Invoke-ADReplicationSyncCommand -Source "DC-HUB01" -Destination "RODC-BRANCH01" -Object "CN=Jane Doe,OU=Finance,DC=corp,DC=example,DC=com"

Alternatively, use the prepopulate cmdlet to push credentials for all members of the Allowed group:

$users = Get-ADGroupMember -Identity "Branch-Users" -Recursive
foreach ($user in $users) {
    $user | Get-ADUser | Add-ADFineGrainedPasswordPolicySubject -Identity "RODC-BRANCH01"
}

# Or use repadmin to prepopulate
repadmin /rodcpwdrepl RODC-BRANCH01 DC-HUB01 "CN=Jane Doe,OU=Finance,DC=corp,DC=example,DC=com"

RODC Administration Delegation

A key RODC benefit is the ability to give a local branch staff member administrative rights over the RODC server without granting them Domain Admin rights. The delegated administrator can manage local services, restart the server, and perform local group management — but cannot modify AD objects directly.

Verify or change the delegated administrator after promotion:

# Check current delegated admin
Get-ADComputer "RODC-BRANCH01" -Properties "msDS-RevealOnDemandGroup","managedBy" | Select-Object managedBy

# Set a new delegated admin
Set-ADComputer "RODC-BRANCH01" -ManagedBy "CN=BranchAdmin,OU=Admins,DC=corp,DC=example,DC=com"

The delegated admin account is added to the local Administrators group of the RODC automatically.

Monitoring RODC Replication

RODCs only replicate inbound from writable DCs. Monitor replication health with:

repadmin /showrepl RODC-BRANCH01
repadmin /replsummary RODC-BRANCH01
repadmin /showreps RODC-BRANCH01

Check the replication queue (useful during initial replication which can be slow over WAN):

repadmin /queue RODC-BRANCH01

Force immediate replication from the hub DC to the RODC:

repadmin /syncall RODC-BRANCH01 DC=corp,DC=example,DC=com /AdeP

Monitor RODC-specific event IDs in the Directory Service event log. Event ID 1240 (RODC attempted to replicate a secret attribute that was filtered) and 1644 (performance logging for LDAP queries) are particularly relevant for RODC health monitoring.

Branch Site Configuration for the RODC

For the RODC to serve clients in the branch office, you must configure an AD site and subnet for the branch, and link it to a site link that connects to the hub site. Clients in the branch subnet will discover the RODC as their DC via DNS SRV records.

# Create the branch site
New-ADReplicationSite -Name "BranchOffice-NYC"

# Create the subnet for the branch
New-ADReplicationSubnet -Name "192.168.10.0/24" -Site "BranchOffice-NYC"

# Create a site link between hub and branch
New-ADReplicationSiteLink `
  -Name "HQ-to-NYC" `
  -SitesIncluded "Default-First-Site-Name","BranchOffice-NYC" `
  -Cost 100 `
  -ReplicationFrequencyInMinutes 180

# Move the RODC computer object to the DC in the correct site
Move-ADDirectoryServer -Identity "RODC-BRANCH01" -Site "BranchOffice-NYC"

After the move, clients in the 192.168.10.0/24 subnet will query DNS and receive the RODC’s SRV record, directing their Kerberos and LDAP traffic locally. Verify client site assignment:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /site:BranchOffice-NYC

With the RODC fully deployed, branch office users benefit from fast local authentication, and the risk of a stolen server exposing the entire domain’s credential database is eliminated. The RODC is a cornerstone of any enterprise AD deployment that spans multiple physical locations.