The whole point behind Active Directory and its multi-master model is that an Active Directory domain controller in one location has essentially the same copy or view of the database as does every other DC in the entire Active Directory domain. Now this is great because every single domain controller can be a writable domain controller, however every single domain controller, as you can imagine, contains every single object in Active Directory. Now, in a world where our domain controllers can be locked behind closed doors, that’s a perfectly acceptable thing. A would-be attacker would have to break into our offices, and then once inside break further into the data center itself in order to find and then take off with that domain controller server itself. You can imagine that an environment that had 10s of thousands of different usernames and passwords, well, the loss of a single Active Directory domain controller because it wasn’t properly secured, could mean the repermissioning, the repasswording of every single user. Now for that reason Microsoft includes this RODC role, that again, is only intended when you have a domain controller that you for some reason cannot lock away.
RODC, addresses branch office scenarios where you may have no local IT staff, few users, potentially expensive wide area network links, and limited physical security. What exactly does the read-only domain controller offer us as an IT professional, by means of security and convenience?
The RODC’s chief purpose is to provide an enhanced security in a branch office domain controller as opposed to installing say, a full fledged read-write domain controller. The read-only domain controller is an ordinary domain controller like any other in your domain, except all of its directory partitions, particularly it’s domain partition, are read only. The read-only nature of course means that you lessen the chance of someone maliciously altering active directory data. Again, critical if you’re in a branch office that doesn’t have local staff, local IT staff. Now the read only nature of the RODC extends to DNS, any active directory domain services domain controller worth its salt is going to also be a DNS server.
RODC is compatible with other windows server features that enhance security. It reduces the exploitation or attack surface of the machine. There is also option for BitLocker for your data volumes to make sure that if, for instance, somebody steals your RODC and tries to get confidential data from that data volume, they will fail in that attempt. And then again, more specifically, with the security piece, we have cashed credentials also known as the password replication policy, the FAS or FAS, filtered attribute set, and ARS which is administrative role separation.
Password Replication Policy (PRP)
The PRP is an access control list of sorts, that specifies which domain, user, and computer accounts can have their password hashes cached on the RODC. You might have a hundred users, organization wide, but only few in the branch office. Isn’t it silly to replicate all of the password hashes for all the domain users to the branch office? Specially if you don’t have additional layers of security down, like maybe the branch office has a full read-write domain controller. Even worse, a malicious user could feasibly steal that machine if it’s not physically secured and brute force attack to figure out what the passwords are that are represented by those hashes. It’s not a good deal. Least service means, if you’re not using a service, don’t even install it. We can extend that to password security by not replicating any passwords for any users who do not exist in the branch office.
What RODC can give your branch users? It gives them convenience. Because their password hashes are locally cached, so their domain log-ons are going to be much faster. They’ll also be able to log-on, not just to local cached credential log-on, but a true blue domain controller log-on, even if the WAN and the headquarters branch fails. Now of course if the WAN connection fails to the headquarters, the users wouldn’t be able to necessarily connect to headquarters resources anyway. But presumably you have locally in that branch office, the printers, the shared folders, the local internet website replica, whatever else that they need on campus, so they shouldn’t be so dependent upon the headquarter’s site. You should also know that high security groups, domain admins, enterprise admins, even the sub-administrative groups are automatically denied, as far as RODC password caching is concerned.
Administrator Role Separation (ARS)
Domain administrator in the central site can pre-create an RODC computer account. That’s a different process actually than simply pre-staging an ordinary computer account that you might do for operating system deployment. There’s actually a wizard specifically for pre-creating or staging read-only domain controller accounts. Once you have that created, you’ll then specify one or more users who are delegated admins in that branch office location. Now this is a special kind of delegated administration. These delegated admins can attach the local RODC that you may have shipped to that branch office, and maybe you’re walking the delegated admin through plugging it in, getting on the network, update server and so forth. RODC delegated admins are delegated administrative authority only on that RODC. So you may actually have more than one RODC in one or more branches just because one person has those privileges on RODC in Site A, that gives him or them absolutely zero administrative privileges out of the box on an RODC in Site B. Administrator role separation isn’t available on writeable DCs.
INSTALL Read-Only Domain Controller (RODC)
There are 2 ways of doing it. We can configure it when promoting server to a domain controller or we can pre-create RODC computer account. When you pre-create RODC computer account you configure everything in advance, which users will have their passwords cached and replicated etc. and when you promoting server to a dc those options will be grayed out.
Let’s install RODC using pre-created account. I will not focus on usuall way because it is straightforward, install AD DS role and promote server to a domain. When you do that you will need to select RODC and do the same thing about configuring password replication policy you will see here so no need to do the same thing twice.
To use second option you will need to open ADUC and right-click on Domain Controller OU and select Pre-Create Read-Only DC Account.
When wizard opens ,Mark Use advanced mode installation and click Next
First it asks us, do we have the creds to do this? I’m logged on as a domain administrator so I’m good. Click Next
Now we specify the computer name. Now this is important, it says, the server must not be joined to the domain before you install active directory domain services on it. Now there’s some important captchas here before you fill this in. It says, principally, that before the server can be attached to the account that you’re creating, and become an RODC, it must be named with the same name that you specify here. I already have a server named RODC so I will use that name for it host name. Click Next
Next it’s asking us for a site, I only have one site so I don’t have much options to choose here but you will specify your branch site. You’ll notice fromprogress dialogues (when you click on Next), it’s essentially doing the same thing that we do when we run the active directory domain services installation wizard normally. We’re just running the wizard in a different context than usual.
I’m going to do DNS server and global catalog. Note that read-only domain controller option is grade out. It also tells us that it detects that there are already 2 DNS server that’s authoritative for mehic.se domain. Click Next
Specify the password replication policy window, here you can either allow to replicate passwords to this DC, or deny from replicating passwords to this DC. It is in this location where if you have multiple different remote sites, one for different geographic locations, it’s probably a good idea for you to configure multiple different replication groups for each site so that you further constrain down just which passwords are gonna be on this machine. High privilege groups like administrators, and server operators, et cetera, are set to deny by default. This is where you can remove entries that are not relevant, or add additional groups to the list.
NOTE: if an account is in the denied replication group, please know that this doesn’t prevent a user from logging on through a RODC, it just simply denies the RODC the ability to locally cache the password. So in other words, the WAN link will have to be available so the RODC can pass over the WAN and get an authentication token from a read-only domain controller.
Click on ADD
When you click on add it will ask you if this going to be an allow or a deny. I will select Allow. When you click OK it will ask you to add groups
I have a group called HBG Users, Click Ok
Here it is, so anybody in this group will have their passwords cached. (Now if you decide not to mess with this right now, that’s okay because you can always come to this part after)
Once done click next
Delegation of RODC Installation and Administration Window, This is the administrative role separation and you can choose a group or a user, who is going to be delegated admin or admins on this server. I have a group called HBG Delegated Admins, click next
As usual, we can export settings if you’re looking at an automated process or I’m just going to go ahead and do it. When you click next it will tell you that now that we’ve completed the account creation, we can attach the server that we want to be the RODC by running the ad roles, wizard and server manager.
When you click Finish you will see that we have the RODC account, it’s disabled, unoccupied DC account. So far so good.
Switch to your RODC server and open powershell as admin and type in
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools -IncludeAllSubFeature
That completed successfully, and we don’t need a restart. That’s always good news. Now we need to bring up the server manager (you can run servermanager in powershell to open it) and refresh our view and we should get a little alert, click on the Promote this server link….
Deployment Configuration window, We’re adding a domain controller to an existing domain, it’s mehic.se, I’m going to need to change those credentials to specify domain credentials.
When you click next you will see this message, A pre-created RODC account that matches the name of the target server exists in the directory. Choose whether to use the existing RODC account or reinstall. I’m going to leave the default of course, and everything else here is grayed out, read-only because that’s been part of the pre-staged account. I have to supply the appropriate DSRM password. You may not want to give a delegated admin that password. Click Next
Here we can configure the additional options that, most of this here has to do with any domain controller, RODC or not. We won’t do an install from media, we’ll replicate from any domain controller, click next
we’ll use the standard paths here for ADDS
And then we’ll choose the Next button, and the Install button, to complete the installation of our RODC.
That’s it. Now when that is done your server will reboot and when it is up and running open server manager and start ADUC and go through some of the additional management tasks that you may wish to do here on this machine. You will notice that you will be able to make changes and that is because you will be connected to a different domain controller and not RODC. To change ADUC to your RODC you will need to right-click on the domain (mehic.se) or a ADUC node and select change domain controller
Before we continue make sure that Advanced Features are enabled.
Now click on Domain Controllers OU and right-click on our RODC and select properties
The first of which is Password replication policy tab, where you’ll see configured the allow and deny settings for any of these groups that were part of that original installation process and the group that we added when we pre-configured this account. So it’s here where you would add additional groups if you wanted to be those where your password was replicated down.
Click the Advanced Button
Here we can identify the actual accounts themselves that have been replicated down to this RODC. So you can see here that the computer account for RODC has been downloaded, and this Kerberos ticket-granting ticket user has been downloaded as well. So it’s here where you can actually identify which users have their passwords on this machine, as well as, should you have need to repopulate those passwords, you can do so by clicking on Prepopulate Passwords
If you expand Display users and computers that meet the following criteria, it will allow you to see a list of accounts whose passwords are currently cached on the RODC, and accounts that have been authenticated.
If you click on Accounts that have been authenticated to this RODC, you will notice that we have an entry for administrator, domain admin, who’s been authenticated, but whose password does not appear in the local cache. That’s because the domain administrator is part of the denied RODC password replication group,
Click now on the Resultant Policy Tab, here we will have the ability to identify which potential users and computers will be downloaded as part of the different policies that you’ve set up in the previous screen so here we can test whether a particular user is part of the replicated group or not. Let’s see how this works?
I will click on Add and add one user who is in Allow group and add one user who is not in RODC group.
Sales1 user –> exists in the users container, and there’s an implicit deny, which means that Sales1 isn’t in the actual denied group, but his password cache setting is implicitly denied because he’s just not at all indicated in the branch office.
HBG1 User –> His resultant settings is allow
Let’s go back to Policy Usage Tab, and let’s click on Prepopulate Passwords,
This is where you can in fact do a manual cache of an account as long as it’s not in the denied group. What if Sales1 User plans to log on to the branch office? We can prepopulate his password. Click on the Prepopulate Passwords and add the user
Notice that it gives us an error. This account must fist be added to the allowed list in order for this to take place. It’s nice that we’ve got these layers of security
Let’s add our user to Allowed list. You will find that group under the Users OU
Once done, let’s go back to RODC Properties and see if we are able to add it.
NOTE: If you receive the same error again that is because AD didn’t replicate changes immediately.
And here it is. Let’s close this and check one more tab.
Next tab is Managed By, we can identify which group of users should have access to administrators RODC, so like my HBG Delegated Admins, for example here in mehic.se. (This option is pre-populated because we configure this when we created that RODC account) This group now could perform all the usual management tasks of dealing with this as being a Windows server, but would have no access to do anything associated with Active Directory and the things commonly associated with account operators and domain admins.
Now, in a worst case scenario, if the RODC is compromised and you need to reset it, what we’re going to do is right click and select delete.
Warning message pops up, click yes
And notice, we get the supplemental dialog box after we answer yes. The text here is instructive. If the RODC is compromised or stolen, Microsoft recommends that you reset account passwords that the hashes for which were stored in the RODC. And by default, it’s going to reset all user account passwords that are cached on that RODC. You can also reset the computer account passwords, but notice that if you do that, all of the computers that are part of that remote site will need to be rejoined to the domain. If you don’t want to go through with this, you can just hit view list to look at impact. And it just simply shortcuts to this advanced password replication dialog that we saw earlier. If you choose not to export, the delete button becomes available. If you do choose to export, you have to specify a directory path and a file name, CSV file name, before delete becomes relevant.
That’s it. I hope this has been informative for you.
Thanks for reading!
Hello, Thanks you.
I’m going to install RODC on many branchs office, my method is the following:
1) install and configure RODCs on the primary site (VMs machine on hyper-v)
2) export the RODCs VM server
3) import the RODCs VM server (Hyper-v)
4) modify IP address
5) run the replication from RW to RODC.
It’is the best method ? or you can advise me another way.
Thanks in advance.
Great post. It is really very hard to find blog post where author go so much in detail and explaining every step. I am amazed with the level of knowledge you have, the way you provide information in every post and thank you for sharing it with us.