Read-Only Domain Controllers

May 28, 2017
RODC Outline
Since Windows 2000 Server was first released almost 15 years ago, domain controllers have been the absolute foundation of any Active Directory environment. They handle the authentication of your user accounts and devices. They grant or deny users access to such things as shared folders, printers, and other resources on your network. They also store information about all of the accounts and resources in your environment and enable users to look up the resources they need. They let you create and deploy Group Policy Objects (GPOs) that allow you to manage, control and lock down numerous aspects of your environment.
But since domain controllers basically manage the security of your Active Directory environment, they represent a high-value target for those who wish to attack your organization. Ensuring the physical security of domain controllers is paramount because if someone were able to steal one of your domain controllers, they could have access to the secrets of how your business operates. Because of this, Microsoft introduced a new type of domain controller beginning with Windows Server 2008 called a read-only domain controller (RODC). Unlike a writeable (normal) domain controller, a RODC maintains a read-only copy of your Active Directory database. It also replicates directory changes in only one direction (inbound) which means if a RODC was compromised, any changes made to its database would not be replicated to the rest of your forest. RODCs also include additional security features, for example in how they cache credentials. These features of RODCs make them a good choice for when you need to deploy a domain controller at a small branch office or other remote site that doesn’t have the same level of physical security as your central office does.
Where you should begin
Your starting point for learning how RODCs work and how they should be deployed is the Planning and Deploying Read-Only Domain Controllers whitepaper which is available in .doc format from the Microsoft Download Center. Don’t be put off by the fact that this whitepaper was published back in 2008 because there have been essentially no changes to how RODCs work since Windows Server 2008. In other words, Windows Server 2012 R2 RODCs work the same as Windows Server 2008 RODCs do. Any changes to RODCs since 2008 have basically just been bug fixes. You might also want to have a look at How Read Only Domain Controllers and DNS works in the TechNet Wiki for some additional information on how RODCs interplay with the DNS infrastructure that undergirds your Active Directory environment.
Once you’ve read the above whitepaper and wiki article, the next resource you should probably review will be the Read-Only Domain Controller (RODC) Branch Office Guide which is available here from the Download Center. This .doc is dated 2009 but it’s still pretty much accurate in regard to deploying Windows Server 2012 RODCs at branch offices.
If you’re thinking about deploying a RODC in the DMZ (perimeter network) of your environment, your starting point for reading should be the Active Directory Domain Services in the Perimeter Network (Windows Server 2008) whitepaper which is available here from the Download Center. There’s also a TechNet Wiki page on this subject but currently it’s only a stub.
Once you’ve downloaded and read all the above docs, you may still come across issues or scenarios not covered by them. That’s what this present article is intended to address. In other words, we’ll look at some tips and got has concerning RODCs that aren’t covered in these docs, or at least they aren’t covered very clearly.

RODCs and your business applications
One important question you should investigate before you begin deploying RODCs in your environment is whether all of your business applications will work with RODCs. If you have some mission-critical application that doesn’t work with RODCs and you go ahead and deploy RODCs, you might suddenly find your business suddenly grinding to a halt.
All Microsoft seems to have to offer in this regard is this Read-Only Domain Controllers Application Compatibility Guide in the TechNet Library. Unfortunately, that guide was last updated in 2007 so it’s probably not sufficient to answer all your questions concerning RODC compatibility for your key business applications. When I discussed this issue my Active Directory contacts at Microsoft they said they didn’t keep a master list of applications not compatible with RODCs because it’s the job of the application owners, not the Active Directory team, to determine whether their applications work with RODCs or not. I did confirm the obvious however, for example that Microsoft SQL Server cannot be installed on a RODC, that Microsoft Exchange can’t query against a RODC, and so on.
Then there’s the matter of third-party applications and their compatibility with RODCs. For this of course you can’t ask Microsoft–they can’t be expected to maintain a central compatibility registry of all of the business applications in the world. You have to contact the application vendor instead and ask them directly about RODC compatibility for their applications. But don’t expect a helpful response from vendors. I once asked a vendor about this and their reply was “What’s an RODC?”
So basically, your best way of approaching the problem of application compatibility with RODCs is to build a test environment that has all of your critical business applications deployed. Then introduce some RODCs into your test network, put each application through its paces, and observe what happens. Remember, if you don’t have a test environment then your production environment *is* your test environment. And you definitely don’t want that.
RODCs and the PDC Emulator role
I don’t think it’s well-documented on TechNet, but from discussions with my colleagues it seems there can be a direct dependence by RODCs in a domain upon the domain controller holding the PDC Emulator role in that domain. The PDC Emulator is the authoritative domain controller for a domain and it’s necessary in order to synchronize time within the environment so Kerberos authentication can work properly. I heard awhile back from one colleague that he knew someone who used IPsec to segment their environment in a way that an RODC could not communicate directly with the PDC Emulator for the single-domain forest. A side effect that was noticed in this situation was that when a user account was deleted from Active Directory, the change was not replicated to the directory database of the RODC. Another side effect was that when a change was made to one of the user rights via Group Policy, the change was also not applied to the security policy for the RODC. When an IPsec rule was introduced that allowed the RODC to directly talk to the PDC Emulator however, such changes were applied as expected by the RODC. I haven’t verified this in my lab yet, but it suggests that you should exercise caution when firewalling your internal network with IPsec tunnels as you could end up breaking Active Directory which could result in authentication failures and other related issues.
When I said that the above issue isn’t well-documented on TechNet, there are some hints around that problems can occur of which the RODC can’t communicate directly with the PDC Emulator. For example, see the topic “Resolving an account lockout problem in a branch office with an RODC” in the article Administering RODCs in Branch Offices. The thread titled Replication timelines with RODC in remote AD site on the TechNet Forums also discusses some issues that seem related to this matter.
We’ll examine a few more potential issues involving RODCs in the next article in this series.
Got questions about Active Directory?
If you have any questions about using read-only domain controllers, the best place to ask them is the Active Directory Domain Services forum on TechNet.