Deploying and Configuring an Read-Only Domain Controller (RODC)

I know most of you have to maintain branch offices, and they are not easy and especially not secure. Domain controllers in those locations can be easily stolen or compromise, leaving your users and your network vulnerable to attacks. Microsoft thought about this, and starting with Windows Server 2008 they implemented a feature in the server product so domain controllers can be in read-only mode. So even if is stolen or compromised that domain controller has no passwords or AD accounts on it. You can configure it to cache credentials and passwords, but by default is not going to. In order for a RODC to exist you still need to have writable domain controller but this is on a main site where security can be guaranteed and specialized personal exist. More information about RODC can be found here. The AD infrastructure needs to meet some prerequisites before a RODC can exist:

- The forest functional level should be at least at Windows Server 2003.

- A writable domain controller running Windows Server 2008 or Windows Server 2008 R2 that is also a DNS server need to exist in the same domain as the RODC.

- If your environment is Windows server 2003, you need to prepare the forest and the domain. Just follow the first section of that article and you will be good-to-go.

- The PDC emulator should be running on Windows server 2008.

For this guide there is a single forest and a single domain. The branch office is connected to the main site trough a VPN connection and has a RODC running Windows server 2012. The installation of a RODC is just like adding and additional domain controller to your network. What makes the difference is the Domain Controller Options page, where you need to check the Read only domain controller (RODC) box.

As soon as you check that box you will get additional options on the left of the wizard. On the section where it says Accounts that are allowed to replicate passwords on the RODC, there is a security group already created. Users and computers that are part of this security group will have their passwords replicated/cached on the RODC. You can create and add your own groups, but I'll show you how is done from the RODC properties page, later on. As you can see in the section Accounts that are denied from replicating password to the RODC, are accounts with administrative access that are denied from replicating passwords on the RODC. In case the server is compromised, the attacker can't find or decrypt the admin account password since it does not exist on the server. Is nested only on a writable domain controller on the main site. By having a small environment here, the Allowed RODC Password Replication Group will do the job just fine. Later I will add some users and computers accounts to this group, to see how replication/catching works. Continue the wizard using the defaults or following the above mentions article.

After the server is promoted to a domain controller, you can open Active Directory Users and Computers (ADUC) on the RODC. If you try to create a new user, you are allowed. And now you might think, why since this is a read-only server. Well…take a look at the top of the console, you can see that you are connected to the PDC, which is the writable domain controller on the main site. Right-click the server name (the PDC) and choose Change Domain Controller.

From the list select the RODC then click OK. As soon as you click the button, a message pops-up telling you that no rights operations can be performed on the domain controller.

     

Try now to create a user account. The option to create it is not even in the menu, and I'm logged in with an Enterprise admin account. Next, I tried to delegate the control of an OU and delete a user account, reset its password. Trying to do so, I either get a warning message or the options were grayed out.

   

Right now, I know this doesn't help you understand the RODC idea, but the next section may fill the void. I'm going to simulate an offline WAN connection, so the RODC can't communicate any more with a writable domain controller on the main site. On one of the clients from the branch office I will log on, or at least I'll try to log on using an AD account. After almost two minutes waiting to log on, I finally got a message: The trust relationship between this domain and the primary domain controller has failed. This happened because the workstation can't find a writable domain controller to verify the user credentials, and the RODC does not have the credentials cached for this user account.

     

You can also see this if you open ADUC on a writable domain controller, go to the Domain Controllers container, right-click the RODC and choose Properties.

Click the Password Replication Policy tab then hit the Advanced button. As you can see my User01 account is not listed here. You can click the Prepopulate Passwords button to cache the user credentials manually, and you should do this only if you are in hurry or something. A writable domain controller needs to be available for this.

     

Another way to cache users credentials is to add those users and computers accounts to the Allow RODC Password Replication Group security group. Here I have two users that I want their credentials to be cached so in case the WAN connection goes down, they will be able to log in. These are those king of users that know some stuff about computers, so I want them to be able to troubleshoot small problems when needed. Make sure you also add their computer accounts or is not going to work.

This credentials won't be cached right away, but after a few minutes, logins and restarts, they will eventually appear in the Advanced Password Replication Policy window.

If I take the WAN connection offline again, these two branch office users will be able to log in to computers that are cached on the RODC.

Now, if you want to change the default security group from the Password Replication Policy all you have to do is open the RODC properties. Here, go to the Password Replication Policy tab, hit the Add button and add the security group you created in AD. This must be done on a writable domain controller. Once you click the Add button, choose the settings for the account, if you want to deny or allow replication.

Type the security group(s) you want to add to the policy.

All you have to do in order for the replication to work, is add users and computer accounts to this/those group(s).