In this article, we will explore what an RODC is, its benefits, and the step-by-step process to install and configure it using both direct and staged installation methods.
Note. The steps described below are applicable to Windows Server 2025 or 2022 as ADDS remains largely consistent across recent Windows Server versions. Where relevant, you should use modern admin tools such as Windows Admin Center and PowerShell 7+ as alternatives to Server Manager.
A Read-Only Domain Controller (RODC) is a domain controller in the Windows Server environment that stores a read-only replica of the Active Directory database. Unlike a writable domain controller, an RODC does not allow any changes to the Active Directory database from that particular domain controller.
This limitation makes it an ideal choice for cases where security is a significant concern, such as remote offices, branch locations, or sites with lower physical security.
The main advantages of an RODC
Reduced Attack Surface: Since the RODC is read-only, even if it is compromised, an attacker cannot make changes to the AD database, minimizing the potential damage.
Credential Caching: RODCs can cache credentials of previously authenticated users, which reduces the need for users to contact a writable domain controller for authentication, thus improving logon times.
Better Bandwidth Utilization: An RODC can help optimize the replication traffic in locations with limited bandwidth since it only receives updates but doesn’t send them out.
Requirements for Installing a Read-Only Domain Controller
Active Directory functional levels: Microsoft documents Windows Server 2003 as the historical minimum forest and domain functional level for RODC deployment, but this is not an appropriate target for a modern Windows Server environment. In case you are deploying an RODC on Windows Server 2025, the existing domain must be at least at the Windows Server 2016 functional level, and all DCs must meet the OS requirements for the selected functional level. Windows Server 2025 uses a new Windows Server 2025 functional level when all DCs in the forest support it. For modern deployments, you need to use the highest functional level supported by all DCs in the environment, rather than deliberately maintaining a legacy 2003 functional level.
SYSVOL replication: Modern AD environments must use DFSR for SYSVOL replication. Windows Server 2016 was the last Windows Server release that supported FRS, and newer DCs cannot be introduced into an environment that still relies on FRS. You need to check if SYSVOL has been migrated to DFSR before deploying a modern RODC.
Writable domain controller: A writable DC running Windows Server 2008 or later must be available in the domain for RODC deployment. For a new deployment, you should use a currently supported Windows Server release rather than introducing a legacy DC solely to satisfy this historical minimum.
Prepare the Forest for RODC Deployment
Before deploying the first RODC in a forest, you should check if the forest has been prepared for RODC deployment. If adprep /rodcprep has not been run previously, you need to run it from the Windows Server installation media on a writable DC using an account with the required AD DS privileges:
adprep /rodcprep
The command prepares the forest for read-only DCs and only needs to be run once per forest. If the forest has already been prepared, you do not need to run it again for subsequent RODCs.
The following role model is an author-defined example based on Microsoft’s privileged access and administrative tiering concepts. These are not built-in Microsoft roles/official RODC role names. In modern AD administration, you should follow a structured privileged access model rather than ad-hoc delegation. For example, RODC deployment and administration can be divided into the following responsibilities:
RODC Pre-creation Administrator (Tier 0). Performs privileged AD DS operations such as creating the RODC computer account and configuring the Password Replication Policy (PRP).
RODC Deployment Operator. Performs the staged installation of the RODC using the pre-created account and delegated permissions.
RODC Local Delegated Administrator. Manages the RODC server locally after deployment.
This model helps align RODC deployment with least-privilege principles and can reduce unnecessary exposure of highly privileged credentials in branch-office environments.
Understanding Password Replication Policy (PRP)
One of the most important security features of an RODC is the Password Replication Policy (PRP). This one controls which user and machine credentials are allowed to be cached on the RODC for local authentication in branch office cases.
Keep in mind that passwords are not automatically stored on an RODC. Credentials are cached only after a successful authentication request and only in case the account is explicitly allowed by PRP. By default, privileged accounts are denied from password caching on RODCs.
Keep in mind that cached credentials on RODCs may include NTLM hashes and Kerberos keys (which can be extracted offline in case the server is compromised). This makes PRP a critical boundary control for lateral movement prevention in Tier 0 environments.
Allowed RODC Password Replication Group
Members of the “Allowed RODC Password Replication Group” are permitted to have their credentials cached on the RODC after successful authentication. Note that this group should contain only branch office users and machines that require local authentication when WAN connectivity to writable DCs is unavailable.
Denied RODC Password Replication Group
Members of the “Denied RODC Password Replication Group” are explicitly blocked from credential caching on the RODC. Note that highly privileged accounts should always remain denied from replication.
Security warning. Never allow privileged accounts to cache credentials on an RODC, including:
Domain Admins
Enterprise Admins
Schema Admins
KRBTGT account
Tier 0 administrative accounts
Privileged service accounts
Backup operators
Infrastructure/admin service accounts
Method 1: Direct Installation of RODC
Installing the RODC using this method is performed by an administrator on the target server. The installation can be done using PowerShell and the Server Manager (GUI).
Installing RODC using PowerShell
In this section, we’ll install a read-only domain controller on a target server called RODC2 using PowerShell.
Open PowerShell as an administrator on the target RODC server.
Run the following commands to install the Active Directory Domain Services role:
# Install AD DS Role Import-Module ServerManager Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Run the following script to promote the domain controller. This PowerShell script installs an Active Directory Domain Controller with specific configurations, such as making it a global catalog server, setting the appropriate paths for the AD database and log files, installing DNS, setting the Safe Mode Administrator Password, making it a Read-Only Replica, specifying the Active Directory site, and forcing the installation to proceed. The script guides the user to enter the password for DSRM at the beginning for added security.
# Install the RODC $Credential = Get-Credential -Message "Enter credentials authorized to promote the RODC" $DSRMPassword = Read-Host -AsSecureString -Prompt "Enter the DSRM Password"
Now, let’s go through the various parameters used with the Install-ADDSDomainController cmdlet:
DelegatedAdministratorAccountName “THEITBROS\RODC Delegated Admins”: Specifies the user/group that receives delegated local admin permissions on the RODC. Members of this group do not become Domain Admins/domain-wide admins.
SafeModeAdministratorPassword $DSRMPassword: Provides the password entered by the user at the beginning of the script for Directory Services Restore Mode.
ReadOnlyReplica:$true: Indicates that the domain controller being installed is a Read-Only Replica. RODCs are used in branch offices and have limited functionality to enhance security. The remaining parameters specify the AD database, log files, SYSVOL location, DNS installation, AD site, restart behavior, and other installation settings. In most deployments, the default values shown in this example are appropriate unless your organization requires a custom config. Once the installation is finished, the RODC server will restart automatically.
Run the following command in PowerShell to display the new RODC.
In this section, we’ll install a read-only domain controller on a target server called RODC1 using the Server Manager GUI.
Open the Server Manager on the target RODC server.
Click Manage → Add Roles and Features.
Select the “Role-based or feature-based installation” option, and click Next.
Select the target RODC server and click Next.
Check the “Active Directory Domain Services” role, click Add Features and Next.
Click Next on the following pages until you reach the Confirmation step.
Click Install and wait for the ADDS role installation to complete.
Once the ADDS installation is finished, click the “Promote this server to a domain controller” link.
Select the “Add a domain controller to an existing domain” option, select the correct domain, and click Next.
Check the “Read only domain controller (RODC)” option, type the DSRM password, and click Next.
Select the “Delegated administrator account” on the RODC options page. You can choose a user or group. In this example, I’m selecting a pre-created security group called RODC Delegated Admins. The members of this group will have local administrator-equivalent access to the RODC server. Leave other fields as default and click Next. Note that delegated RODC admins should be considered trusted for the branch office environment. Although they do not receive Domain Admin privileges, they have full admin control over the RODC server itself and may potentially access locally cached credentials/compromise services running on the server.
Choose whether to replicate from a specific domain controller or any domain controller and click Next.
Customize or leave the default database, log files, and SYSVOL paths and click Next.
Review the RODC installation options and click Next.
When the prerequisites check has been completed and passed, click Install.
Wait for the installation to complete. Once the installation is finished, the server will reboot automatically.
A staged RODC installation is useful when a Domain Admin must delegate the completion of the RODC deployment. This method is done in two stages.
Important. Modern staged RODC deployments should use a pre-created RODC computer account and the supported -UseExistingAccount workflow. Do not use the legacy NetJoinLegacyAccountReuse registry setting. Microsoft removed support for this setting in security updates released on and after August 13, 2024.
Stage 1: Pre-Creating the RODC Account
This step is typically done in the same location as the RWDC. The Domain Admin pre-creates the domain controller computer account, which includes:
Specifying the RODC name and site.
Adding delegated administrators who can deploy the RODC on the new server.
Note that after pre-creation, the actual installation can be finished by a delegated admin without Domain Admin privileges (as long as they are explicitly assigned in the RODC delegation settings).
Stage 2: Installing the RODC on the Target Server
Note that delegated admin operates under least-privilege principles and does not require Domain Admin membership when using a pre-staged RODC account. This method avoids assigning a highly privileged account to deploy the RODC.
Requirements
The forest and domain must meet the minimum functional-level requirements for RODC deployment described above.
The administrator who will pre-create the RODC computer account must be a Domain Administrator.
A delegated user or group must be prepared prior to the RODC deployment.
The target RODC server must meet the following:
A configured computer name.
Have a static IP address.
Must be pointed to the nearest Read-Writable Domain Controller (RWDC) as its DNS server.
Must NOT be joined to the domain.
If computer account reuse is blocked by domain join hardening
If the staged RODC deployment is blocked because the delegated account is not permitted to reuse the pre-created computer account, you need to config the Domain controller: Allow computer account re-use during domain join policy for the appropriate delegated account/group. Follow the steps below:
On the domain controller, open the Group Policy Management console.
gpmc.msc
Navigate to an existing GPO or create a new one. In this example, let’s create a new GPO.
Next, type the name of the new GPO and click OK. This example uses the GPO name “Allow Pre-Created RODC Computer Name Re-Use.”
Right-click the new GPO and click Edit.
Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options, and double-click the “Domain controller: Allow computer account re-use during domain join” policy.
Check the “Define this policy” box, click Edit Security, and add the delegated user or group. The policy is now defined. This means that the delegate user or group members are allowed to join existing computer accounts to the domain, such as the pre-created RODC.
Wait for the group policy update interval, or run gpupdate /force on the domain controllers.
Run the gpresult /r command on the domain controller and confirm that the policy has been applied.
Installing read-only domain controller Using the Server Manager (GUI)
In this example, we’ll install the read-only domain controller on a server named RODC3 using the Server Manager GUI.
Stage 1: Pre-Create the RODC Account
Open the “Active Directory Users and Computers” console using your Domain Admin account.
Right click the “Domain Controllers” container and click the “Pre-create Read-only Domain Controller account” item.
Check the “Use advanced mode installation” box and click Next.
On the “Network Credentials” step, specify whether to use the current logged-on credentials or set alternate credentials for whom will install the ADDS role on the RODC. Let’s choose the “My current logged on credentials” option, assuming it is a domain admin.
Type the target RODC computer name and click Next. In this example, the server name is RODC3.
Select the AD Site for the new RODC and click Next.
In this example, the wizard calculated that the DNS server must be installed on the new server and make it a Global catalog. Leave the additional domain controller options as-is and click Next.
In this step, you can customize the password replication policy ACL. You can add or remove the users or groups whose passwords can be replicated to the new RODC. The BUILTIN and “Denied RODC Password Replication Group” groups are blocked by default. While only the “AllowedRODC Password Replication Group” is allowed. Here you need to review the Password Replication Policy carefully before deployment. Note that only accounts that require branch office authentication resilience should be allowed to cache credentials on the RODC.
In the “Delegation of RODC Installation and Administration”, set the user or group who will be delegated to install the RODC installation. In this example, I’m setting the “THEITBROS\Delegated Admins” group I created previously.
Review the RODC installation options and click Next.
Lastly, click Finish.
Check back in the ADUC, and confirm that the new RODC has been added and is disabled.
Stage 2: Install the Read Only Domain Controller
In this stage, the delegated admin account can continue installing the ADDS role and promote the server as an RODC.
Log in to the target RODC server using a local account (because it is not yet joined to the domain).
Open the Server Manager, click Manage → Add Roles and Features.
Select the “Role-based or feature-based installation” option, and click Next.
Select the target RODC server and click Next.
Check the “Active Directory Domain Services” role, click Add Features and Next.
Click Next on the following pages until you reach the Confirmation step.
Click Install and wait for the ADDS role installation to complete.
Once the ADDS installation is finished, click the “Promote this server to a domain controller” link.
Select the “Add a domain controller to an existing domain” option and type the domain name. Click the Change button and enter the credentials of your delegated administrator. In this example, the delegated administrator is djohnson, a member of the “RODC Delegated Admins” group.
On the next page, you’ll see a banner saying, “A pre-created RODC account that matches the name of the target server exists in the directory.” This message means that the wizard detected the pre-created RODC computer account. Select the Use existing RODC account option, type the DSRM password, and click Next.
Choose whether to replicate from a specific domain controller or any domain controller and click Next.
Customize or leave the default database, log files, and SYSVOL paths and click Next.
Review the RODC installation options and click Next.
When the prerequisites check has been completed and passed, click Install.
Wait for the installation to complete. Once the installation is finished, the server will reboot automatically.
Open the Active Directory Users and Computers console, navigate to the Domain Controllers container, and see that the new RODC is now enabled.
Install RODC using PowerShell
In this example, we’ll install the read-only domain controller on a server named RODC4 using PowerShell.
Stage 1: Pre-Create the RODC Account
Log in to the existing RWDC and open PowerShell as admin.
Run the following command to pre-create the RODC account. In this example, the RODC computer name is RODC4 in the theitbros.com domain. The delegated admin group is ‘THEITBROS\RODC Delegated Admins’, and the AD site is ‘BRANCH-01’.
The -Allowed query shows accounts and groups allowed by the RODC password replication policy. The -RevealedAccounts query shows accounts whose passwords are stored on the RODC.
In case you prefer repadmin, the equivalent check is:
repadmin /prp view RODC4 allow
The command below shows accounts whose password secrets have been replicated to the RODC. This can include accounts whose credentials were replicated after authentication as well as accounts whose credentials were explicitly prepopulated. Therefore, the revealed list should not be interpreted as a list of users who have successfully authenticated through the RODC:
repadmin /prp view RODC4 revealed
Post-Installation Validation
To check DC health, run the command:
dcdiag /test:Advertising
In order to verify replication, use the commands:
repadmin /replsummary
repadmin /showrepl
To verify DNS registration:
dcdiag /test:DNS
To check Active Directory replication failures, use the following command:
Get-ADReplicationFailure -Target * -Scope Forest
Wrapping Up
This blog post showed you the different ways to install a read-only domain controller (RODC). We’ve used the Server Manager (GUI) and PowerShell to perform the direct and pre-staged RODC installation.
We’ve also touched upon the updated hardening policies that may affect the pre-staged RODC deployment and how to prepare for them, ensuring a successful deployment.
In enterprise environments, RODCs should be deployed using delegated administration, least-privilege principles, and carefully configured Password Replication Policies. After deployment, you should always validate replication, DNS, and PRP config before placing the server into production.
RODC Compromise Considerations
In case an RODC is compromised/stolen, you should:
review cached credentials;
reset exposed passwords;
invalidate cached Kerberos secrets;
review the PRP config and deploy a replacement RODC if necessary;
remove the compromised RODC metadata from AD.
The recovery scope depends on which accounts were permitted by the Password Replication Policy.
A Read-Only Domain Controller (RODC) is an Active Directory domain controller that stores a read-only copy of the AD database. It can authenticate users but cannot accept directory changes, making it well suited for branch offices and locations with limited physical security.
The Password Replication Policy (PRP) controls which user and computer credentials may be cached on an RODC. Passwords are not cached automatically—they are stored only after a successful authentication if the account is explicitly allowed by the PRP.
I enjoy technology and developing websites. Since 2012 I'm running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.
Hi, can I proceed with this RODC process without adding a delegated administrator account initially over GUI? The reason why I ask is because I get an error when I want to choose the precrated RODC account like I have for other RODC’s… The error is: “The program cannot open the required dialog box because it cannot determine wether the computer named XY.domain.com is joined to a domain. Close the message and try again” – this XY.domain.com is a DC and it is joined to a domain of course… :) Thanks
Hi,
can I proceed with this RODC process without adding a delegated administrator account initially over GUI? The reason why I ask is because I get an error when I want to choose the precrated RODC account like I have for other RODC’s… The error is: “The program cannot open the required dialog box because it cannot determine wether the computer named XY.domain.com is joined to a domain. Close the message and try again” – this XY.domain.com is a DC and it is joined to a domain of course… :)
Thanks