I have been fascinated with Read-Only Domain Controllers (RODCs) since RODC was released as a new DC promotion option with Windows Server 2008. Microsoft customers wanted a DC that wasn’t really a DC. – something that could be deployed in a location that’s not physically secure and still be able to authenticate users.
This post covers a few different scenarios on how to attack Read-Only Domain Controllers in order to escalate privilege. Since RODCs are typically untrusted and viewed as not having the same level of access as writable DCs, it’s possible in many environments to compromise a RODC to escalate privileges. Given certain scenarios, it’s possible to escalate from a Read-Only Domain Controller to a full writable Domain Controller. This post covers these scenarios and enables Red and Blue teams to better understand and check RODC configurations for issues.
The information in this post is not from any one customer environment I have seen, but a combination of several. I have found that many AD domains that have RODCs are configured very similarly: many more accounts, both user and computer, have passwords cached on RODCs than is necessary and the ability to manage RODCs is not limited or secured appropriately. This post shows what is possible given common real world RODC deployment configuration. As part of our Active Directory security review services, we scrutinize RODC configuration and identify potential issues with the configuration. Furthermore, we find that when RODCs are deployed in an environment, they are frequently configured with weak security settings (as noted in “RODCs in the Real World” and “Attacking RODCs” below).
The information here describes what is possible in many Active Directory environments with Read-Only Domain Controllers and doesn’t highlight a misconfiguration, but common configuration issues that could be exploited to escalate privileges in the domain since the RODC is often treated as “just another server” (or worse, as a workstation). Accounts are regularly cached on RODCs (since RODCs that don’t cache passwords aren’t very useful) and once an attacker gains access to it, these passwords are available and may include delegated Active Directory admin accounts which could be compromised.
If you want to simply know how best to “harden Read-Only Domain Controllers”, skip to the end to read the “Securing RODCs Against Attack” section.
Note that throughout this post, I use the Microsoft Active Directory PowerShell cmdlets and some of the attribute names are adjusted in the output from what they are actually named in AD.
Enter the Read-Only Domain Controller
When Microsoft released Windows Server 2008, a new type of Domain Controller was added called the “Read-Only Domain Controller”. The Read-Only Domain Controller (RODC) performs similar services as a writable Domain Controller except they are “read-only”. But what does that really mean?