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. This tutorial uses Windows Server 2022 for demonstration. The steps described below are also applicable to Windows Server 2025, 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 scenarios where security is a significant concern, such as remote offices, branch locations, or sites with lower physical security.
In modern deployments, RODCs are primarily used in isolated/low-trust branch environments, while identity modernization efforts focus on hybrid identity integration with Microsoft Entra ID.
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 Active Directory 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
The domain functional level must support Read-Only Domain Controllers (RODC), typically Windows Server 2008/higher. In modern environments, we recommend Windows Server 2016+ functional levels for security and compatibility. We also recommend you to use Windows Server 2022/2025 DCs to ensure support for current security baselines and management tools.
Keep in mind that the RODC installation does not require Domain Admin privileges when using a pre-staged deployment model. In modern AD environments, RODC deployment should follow a delegated access model based on pre-created machine accounts and explicitly assigned installation permissions. Domain Admin rights are required only for Tier 0 operations, which include creation of the RODC computer account, configuration of Password Replication Policy (PRP), modification of AD DS structural objects. Note that all installation and promotion tasks should be executed using delegated Tier 1 accounts under a pre-staged RODC model.
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 be joined to the domain.
In modern AD administration, you should follow a structured privileged access model rather than ad-hoc delegation. RODC deployment and administration should be aligned with:
RODC Pre-creation Administrator (Tier 0). It creates RODC computer accounts and configures PRP. Note that Tier 0 separation must be enforced (to ensure that AD DS admin actions do not overlap with lower-tier workloads).
RODC Deployment Operator (Tier 1/controlled Tier 0 access). This one performs staged installation using pre-created account.
RODC Local Delegated Administrator (Tier 1). Manages local server operations only.
This model ensures that RODC deployment remains consistent with least-privilege principles while minimizing Tier 0 exposure in branch office cases. The structured access model directly reduces the risk of credential compromise propagation from branch environments into Tier 0 infrastructure.
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
Credential Exposure Model
Keep in mind that in case an RODC is physically stolen/compromised, attackers may potentially extract cached credentials stored locally on that RODC. The security impact depends entirely on which accounts are allowed by the Password Replication Policy. Note that proper PRP config drastically limits lateral movement risk in branch office compromise scenarios.
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 (Recommended)
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.
Now, let’s go through the various parameters used with the Install-ADDSDomainController cmdlet:
DelegatedAdministratorAccountName “THEITBROS\RODC Delegated Admins”: Sets the account name for the Delegated Administrator. This is usually used for Read-Only Domain Controllers (RODCs) to specify which group can administer them.
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.
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 functional level of your domain is Windows Server 2008 or higher.
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.
Update domain controller GPO
The solution is to update the domain controller GPO to allow your delegated admin user or group to re-use an existing computer account. Here’s how.
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 “THEITBROSDelegated 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 PowerShell or CMD as an administrator and run the following command. This command ensures that the domain-join part of the RODC deployment succeeds.
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.
Remove the NetJoinLegacyAccountReuse registry entry you added in Step 2:
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’.
In some legacy/constrained environments, you may require a registry workaround in order to allow domain join operations during staged RODC deployment.Note that NetJoinLegacyAccountReuse setting is a legacy compatibility workaround and you should use it only in specific staged RODC deployment cases (in which machine account reuse is required). We do not recommend it for standard domain join operations.Security note. Keep in mind that this setting relaxes default domain join constraints and should be removed immediately after successful deployment to restore secure baseline config.So, run the following command. This command adds the NetJoinLegacyAccountReuse registry entry, ensuring that the RODC deployment’s domain-join part succeeds.
After successful installation, you need to ensure that all temporary config changes such as legacy registry settings are removed to maintain a secure baseline config.
Wait for the RODC deployment to finish, and the computer will reboot automatically.
Once restarted, run the following command in PowerShell to list all RODCs.
Now confirm that the core AD services are running:
Get-Service DNS,NTDS,DFSR | Select Name,Status
After that you need to verify Password Replication Policy. Use the following command to display the users and groups whose credentials are allowed to be cached on the RODC:
repadmin /prp view RODC4 allow
The command shown below displays the accounts whose credentials have already been cached on the RODC after successful authentication:
repadmin /prp view RODC4 revealed
Remove the NetJoinLegacyAccountReuse registry entry you added in Step 3.
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