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?
By default, no AD account passwords are cached on a RODC (other than the RODC computer account & RODC KRBTGT passwords) and no changes originate from a RODC’s AD database, SYSVOL, or DNS. Certain sensitive Active Directory attributes are included in the RODC Filtered Attribute Set (FAS) which includes confidential attributes such as the AD attributes storing Bitlocker keys and LAPS passwords. This ensures these attributes are never replicated to RODCs.
RODCs provide the following:
- Read-only Active Directory Database – Read-only copy of Active Directory provides a more secure option for distant locations such as a branch office. Changes attempted against the RODC are referred to the next upstream DC.
- Read-only DNS Server – DNS on the RODC can be configured as a DNS Secondary of the Active Directory Integrated DNS zone file or of a Primary standard DNS zone.
- Credential Caching – By default, no passwords are stored on a RODC (including computer passwords), though specific groups can be configured for password caching. Physical attacks on Active Directory stored domain credentials on RODCs are not possible when password caching is disabled.
- Administrator Role Separation – Administration of a RODC can be delegated to a domain user account without providing “keys to the kingdom” access or significantly decreasing the security posture of Active Directory.
- Reduced Exposure – Filtering specific object attributes to ensure they don’t exist on RODCs. For example, there may be attributes that were added after the instantiation of Active Directory such as specific attributes that are confidential (SSNs, clearance, etc).
- Unidirectional Replication – The only replication that occurs on a RODC is inbound replication from a fully writable DC. This reduces the amount of replication traffic that occurs in the environment as well as the number of connections and connection objects at the primary site. This also protects the rest of the directory from memory corruption of the database due to hardware failure or improper shutdown.
- SYSVOL Modification Isolation – If SYSVOL is modified on a RODC in the field, the change stays on the RODC and is not replicated out. This includes added, deleted, and modified SYSVOL files.
RODC & writable DC differences:
- Active Directory Database – DCs host the only writable copies of the Active Directory database and therefore can perform read and write operations against the directory database. RODCs host read-only copies of the AD database which do not include security principal secrets (passwords). Since RODCs are unable to perform write operations on the RODC hosted AD database, some write operations are forwarded to full DCs and other times the RODC provides referrals to clients in order for the client to locate a writable DC.
- Active Directory Replication – Writable DCs replicate among themselves frequently and as needed to ensure directory consistency. RODCs never replicate to or from another RODC. RODCs also never send replication data to other DCs. RODCs can only receive replication from a 2008 writable DC. This replication method is the same for replicating SYSVOL.
- Local AD database storage – Writable DCs host a full copy of the Active Directory database including security principal credentials. RODCS host a copy of the database except for attributes that are part of the RODC Filtered Attribute Set (FAS) and security principal credentials. Specific credentials can be identified and selected for password replication to the RODC.
- Administration – Writable DC are administered by the domain Administrators and Domain Admins groups; however, membership in these groups also grants enhanced Active Directory rights. RODCs provide the capability to delegate a standard user account and/or user group full administrative rights to the RODC without providing elevated Active Directory permissions.
When placing a RODC at a site, there are several important considerations:
- Think twice about placing a RODC in the same site as a DC. RODCs are meant to be used where there are security and/or other concerns (delegation, replication, etc). If a writable DC is in the site, it makes more sense to place another DC there instead of a RODC.
- If a location requires a DC that hosts additional services (roles), the DC placed at the site should be a RODC. DCs should not host services beyond core Active Directory services (like AD DS and DNS).
- There must be a 2008 (or newer) DC upstream from the RODC to enable proper replication. It is best to have two 2008 (or newer) DCs nearby to enable efficient replication.
- All of the users located at the site serviced by a RODC should be members of a site group which is added to the password policy for the RODC. This will ensure the user passwords are cached for logon in the event the network connection to a nearby writable DC is down.
- All of the computers (workstations & servers) located at the site serviced by a RODC should be members of a site group which is added to the password policy for the RODC. This will ensure the computer passwords are cached ensuring proper computer operation in the event the network connection to a nearby writable DC is down.
- RODCs never communicate with other RODCs. This means if there are multiple RODCs in the same site, they may have different accounts cached and possibly different password policies. This scenario is why it may not make sense to place two RODCs in a site.
Note: If items 3 & 4 are not configured to enable password caching, a writable DC must be available to service authentication (Kerberos) requests; both the computer & user passwords must be cached in order for a Kerberos ticket to be granted.
RODCs in the Real World
RODCs were originally designed to provide authentication and directory services in situations where the system couldn’t be fully trusted. This normally means not allowing account passwords to be cached (default settings) or configuring a subset of domain user and computer accounts that are allowed to have their passwords cached on the RODC. This is configured by creating a group, adding the appropriate accounts to the group, and setting the Password Replication Policy on the RODC to enable password caching for the group. In order for a user to authenticate from a computer in a site with a RODC to that RODC (without a DC involved), the user and computer passwords need to be cached on the RODC.
RODCs are typically deployed to not cache any accounts (default) or are configured to allow caching of most accounts, often by adding Authenticated Users or Domain Users to allow password caching. When the Read-Only Domain Controller was designed, the concern was related to passwords cached on a RODC potentially being cracked. Given that it’s possible to pass a password hash to access network resources (or create Silver Tickets), simply gaining access to a password hash enables account impersonation. This also means the risk of passwords cached on RODCs is higher than originally anticipated.
RODCs are meant to be administered by almost anyone since they are standard servers. However, there is risk with this. If regular users are delegated admin access to one or more RODCs, these RODCs either shouldn’t cache passwords or allow only the minimum number of accounts required to cache passwords. Enabling the RODCs to cache a large number of account passwords in the domain effectively makes the RODC a junior DC and elevates the RODC admins to psuedo-Domain Admin status since they have access to many of the account passwords in the domain.
There is guidance on the web about deploying RODCs in the DMZ to enable production AD users to be authenticated by DMZ applications. I am not a fan of deploying any internal resources in the DMZ or even poking holes in the DMZ-Internal firewall to enable traffic to go from the DMZ to the internal network. From a security perspective, the DMZ is an untrusted zone and should not have direct connectivity to the internal network. If the DMZ is compromised, it should have minimal impact on the interior network. There may be situations where placing a RODC in the DMZ is the best of several bad options. In this case it should probably not cache any passwords (remember these are internal AD accounts) and will require communication from the RODC to one or more DCs on the internal network. This RODC, if compromised, provides a pathway to get to the internal network.
Federation is a much better solution and greatly reduces risk of compromise related to authentication of internal users to external systems. Federation enables internal users to be authenticated to external systems without exposing the internal Active Directory to the DMZ or systems on the internet.
This post covers several attack techniques that can be performed against Read-Only Domain Controllers and chains them together in interesting ways based on real-world configurations.
What are the issues with RODCs as they are typically deployed?
- RODCs cache more passwords than actually required, providing a potential escalation path – compromise the RODC to compromise additional accounts. In this scenario, the RODC acts as kind of a Junior DC since it contains a subset of domain account passwords.
- RODCs are typically administered by a “RODC admins” group which is not typically protected at a high level. Often the RODC admin group contains server administrators and potentially regular user accounts. The accounts in the RODC admin group(s) are often allowed to be cached on the RODC to enable administration if a DC cannot be contacted to authenticate them.
- If the organization has configured the Directory Services Restore Mode (DSRM) password to change (and they should), they may not have configured a different process for RODCs, potentially setting the same DSRM password on RODCs and DCs.
If RODCs are considered “untrusted”, Domain Admins should not logon to them since they may believe their credential is safe since RODCs don’t cache DA passwords by default. When Domain Admins logon to RODCs, their password won’t be “cached” in the RODC’s AD database (ntds.dit), though it will be in LSASS if the DA used a Remote Desktop session (RDP) to connect to the RODC (as well as a couple of other scenarios). Active Directory admins shouldn’t manage RODCs unless the RODCs are treated like DCs and protected at the same level (not in untrusted areas).
Kerberos Service Accounts
Every Active Directory domain has a domain Kerberos service account called KRBTGT which is used to sign all Kerberos tickets and encrypt all Kerberos authentication tickets (TGT). Since the KRBTGT account password hash is used to sign/encrypt Kerberos tickets for the domain, if an attacker gains knowledge of the KRBTGT password hash (Domain Controller access, DC backup access, etc) can result in them creating Golden Tickets to spoof access to anything in the AD forest. It’s important to ensure that the KRBTGT password is changed regularly (2x every year).
Every RODC has its own specific KRBTGT account which is specific to that RODC & is cryptographically isolated from the domain KRBTGT account. The RODC Kerberos account follows the naming format “KRBTGT_######” and includes a BackLink attribute (msds-KrbTgtLinkBl) linking the account to its RODC.
In the graphic below, there are two krbtgt accounts, the standard domain one (krbtgt) and one that belongs to a RODC (krbtgt_27140). The msds-KrbTgtLinkBl attribute links the RODC Krbtgt account to the RODC associated with it. The krbtgt_27140 account is linked to the RODC “ADSRODC1”. Each RODC has its own krbtgt account to create and sign Kerberos tickets which ensures that the loss of a RODC doesn’t compromise the entire domain.
I like to include the msDS-KeyVersionNumber attribute since it tracks password changes: the domain KRBTGT account usually starts at 2 and the RODC KRBTGT account usually starts at 1 for a new domain.
Discovering RODCs is pretty easy. We can query for all “krbtgt” accounts in AD or simply ask for all computer accounts with attributes unique to RODCs (msDS-Reveal-OnDemandGroup, msDS-NeverRevealGroup, msDS-RevealedList, msDS-AuthenticatedToAccountList – described further down in the post).
Searching for computers with the PrimaryGroupID set to ‘521’ will return domain RODCs (or search for DCs with “IsReadOnly” set to True) which effectively identifies them being in the group “Read-only Domain Controllers’.
Kerberos delegation enables a designated computer or user account to impersonate a domain user. Given the power these accounts have, it’s critical to limit this ability only to systems that require it. There are two different types of Kerberos Delegation, unconstrained and constrained.
Unconstrained Delegation was a feature that shipped with Active Directory during initial release and enables account impersonation to any Kerberos resource.
Constrained Delegation is a more secure Kerberos delegation option than Unconstrained Delegation first available with Windows Server 2003. This configuration limits user Kerberos impersonation to specific services on specific servers. Accounts configured with Constrained Delegation with Protocol Transition can request Active Directory Kerberos service tickets (TGS) on behalf of the user without proof of prior user authentication.
RODCs also have the attribute ‘TrustedToAuthForDelegation’ set to True which means RODCs are configured to allow Kerberos Constrained Delegation with Protocol Transition.
DCs are configured to allow Kerberos Unconstrained Delegation.
We can also query for all Domain Controllers that are flagged as “IsReadOnly”.
RODC Password Replication Policy
The KRBTGT accounts are used to sign/encrypt Kerberos tickets. The RODC KRBTGT accounts only sign/encrypt Kerberos tickets for accounts the RODC has passwords cached and stored on it. Any RODC generated Kerberos authentication ticket (TGT) provided to a DC by the client is discarded and regenerated.
Since by default, no passwords are cached on a RODC, this shouldn’t be a big deal. However, the reality is there will need to be accounts cached on the RODC in order for them to be authenticated by the RODC (such as when the network connection to the DC is down). This is handled by adding users to a group and adding that group to the domain’s Allowed RODC Password Replication group or adding the group to the Password Replication Policy on the RODC (set to Allow).
Note that an account password that is “cached” on a Read-Only Domain Controller is stored in the RODC’s local Active Directory database (ntds.dit) much like how a regular DC stores account passwords. The difference is this information is never replicated from a RODC.
The graphic shows the default configuration for AD groups:
- Account Operators: Deny
- Administrators: Deny
- Allowed RODC Password Replication Policy: Allow
- Backup Operators: Deny
- Denied RODC Password Replication Policy: Deny
- Server Operators: Deny
Also added is the RODC Admins group used in this lab environment to administer the RODCs.
There are a number of domain/forest groups that are explicitly denied from having their account passwords replicated to the RODC. This protects against accounts in these groups from having their password saved on the RODC.
- Cert Publishers
- Domain Admins
- Domain Controllers
- Enterprise Admins
- Group Policy Creator Owners
- Read-only Domain Controllers (the RODC’s computer account password is stored locally, just not any others)
- Schema Admins
When a user attempts to authenticate to a RODC, the RODC checks to see if it has the the user’s password cached. If it doesn’t already have the password, the RODC forwards the authentication request to an upstream writable DC which replies with the authentication data. After this the RODC requests the user’s password from the writable DC. If allowed by the RODC’s Password Replication Policy, the writable DC replicates the user’s password to the RODC. If the user’s password is cached on the RODC, the RODC handles the authentication request.
There are 5 key attributes on a RODC:
- managedBy: This attribute identifies the group that administers the RODC. Since RODCs are considered to be less trusted than Domain Controllers, they shouldn’t be managed by Active Directory admins (DAs, etc). Often there’s a RODC specific admin group configured in this attribute, sometimes each RODC has a unique admin group.
- msDS-Reveal-OnDemandGroup: Contains the distinguished name (DN) of the Allowed List. Members of the Allowed List are permitted to replicate to the RODC.
- msDS-NeverRevealGroup: Points to the distinguished names of security principals that are denied replication to the RODC.
- msDS-RevealedList: List of security principals whose passwords have ever been replicated to the RODC.
- msDS-AuthenticatedToAccountList: This attribute contains a list of security principals in the local domain that have authenticated to the RODC.
The RODC ManagedBy attribute can be set during RODC install: “Delegated Administrator Account”.
Since RODC attributes contain some useful information and all Authenticated Users have read access to these attributes by default, we can query these attributes and use this information to craft an attack.
Here’s some example PowerShell script code:
Get-ADComputer $ROCName -Property * | Select Name,ManagedBy,’msDS-AuthenticatedToAccountlist’,’msDS-NeverRevealGroup’,’msDS-RevealedDSAs’,’msDS-RevealedUsers’,’msDS-RevealOnDemandGroup’
With this information, we can determine which RODCs have account passwords stored on them. The next step is identifying ways to gain access to the RODC with interesting account passwords stored on it.
Compromise a RODC Admin to Compromise Accounts with Cached Passwords on the RODC
One way to do this is to go after accounts with local admin rights on the RODC. Delegating admin rights to a RODC is easy: simply add a group to the Manager field on the RODC account. It’s just as simple to determine what group has RODC local admin rights by enumerating RODC computer accounts and the ManagedBy attribute.
Since Read-Only Domain Controllers are not supposed to be managed by Active Directory admin accounts (except in limited scenarios), finding a RODC admin account to compromise often isn’t difficult.
First, determine what group manages the RODC by enumerating the RODC managedby attribute.
Then enumerate the RODC admin groups membership.
Interestingly enough, we often find a mix of lower level accounts (user accounts) along with server admin accounts in RODC admin groups. This provides an interesting escalation path of its own since the best practice is to enable the RODC admin group account passwords are cached on the RODC.
Accounts with Passwords Cached on the RODC
All too often, we visit customers and see that RODCs are configured to enable storing passwords for a larger number of accounts than required – often by configuring “Authenticated Users” or “Domain Users” to store passwords on RODCs. This is not a good idea since, based on what we’ve seen, a large number of users in the environment will end up with their password being cached on the RODCs with this configuration.
This configuration typically results in most domain accounts having stored passwords on RODC(s). While the password stored on the RODC may not be the current one, this is still a risk. Normally, the user/computer needs to authenticate to the RODC before the password is cached. There is another way though. An administrator can pre-populate account passwords on a RODC if those accounts are allowed to be cached.
Let’s look at accounts with passwords on a RODC…
The computer properties GUI in Active Directory Users & Computers shows the list of accounts on the RODC
Enumerating the ‘msds-RevealUsers’ attribute on the RODC computer object in Active Directory, we can view the list of accounts (users and computers) with passwords stored on the RODC. In the graphic below, there’s a string of data before the actual account distinguished name. The RODC seems to track each authentication and password separately.
Using PowerShell, we can remove the initial string of characters shown before the account distinguished name so that only the account Distinguished Name is displayed (and remove duplicates)
This list of accounts have their passwords stored on the RODC. This list includes users and computer accounts which means if we can gain admin access to the RODC, we can steal these credentials and use them. The computer password hash can be used to create Silver Tickets to gain full admin rights on the computer. If we have admin accounts in this list, we can leverage this access to jump to other systems.
Let’s find out who has admin rights on the RODC by looking at the RODC’s ManagedBy attribute. Compromising one of these accounts provides an escalation path to gaining access that accounts with stored passwords have.
There also may be service account credentials on the RODC, especially if they are delegated rights to Active Directory without using the default AD administration groups (which is a best practice). Any service accounts with privileged rights should be added to a group which is configured to prevent member account passwords from being cached on RODCs. If this isn’t done and the RODC(s) is allowed to cache all account passwords (Authenticated Users or Domain Users), then highly privileged accounts could have passwords cached on the RODC(s).
In this scenario, we find there is a service account password stored on a RODC.
The first result is “CN=AccountProvisioning,OU=AD Management,DC=lab12,DC=adsecurity,DC=org”, so let’s see what that is.
This account is not a member of any group. So let’s check to see if it has any rights to AD objects using the PowerView function “Invoke-ACLScanner”.
PowerView is a PowerShell recon tool written by Will Schroeder (@Harmj0y) and is part of PowerSploit.
The results of Invoke-ACLScanner shows us that the svc-ActPrv service account has full control (“GenericAll”) rights to the Accounts & Groups OUs in the domain. Control of this one account provides full control on accounts and groups in the domain.
Let’s see what groups are in the Groups OU.
We can check to see if the Server Admins group is added to any computer local group via GPO using PowerView’s “Get-NetGPOGroup”
The Server Admins group is automatically added to the local Administrators group on all computers in the Servers OU by the Add Server Admins to Local Administrators GPO.
So, by gaining access to the RODC, we now have full control of accounts and groups as well as admin rights to all servers in the Servers OU (through the ability to modify the Server Admins group membership).
Read-Only Domain Controller Kerberos
Using Mimikatz on a RODC, it’s possible to get the RODC’s krbtgt account (krbtgt_45703) password hashes.
Using the standard AD database dump capability in Mimikatz provides the RODC krbtgt data.
Using the Mimikatz command to just pull the krbtgt account data works against the RODC as well. There are a couple of errors though.
DCSync from RODCs?
It’s important to note that we can’t DCSync from a RODC since they don’t replicate data (technically they do replicate a few attributes, but are not meant to be replication partners).
What about RODC Golden Tickets?
We can only forge useful Kerberos tickets against a RODC if the service tickets we will be requesting have the associated service account passwords cached (computer or user accounts). This means they aren’t “Golden Tickets” since we are limited to connecting to a single RODC (associated with the RODC’s krbtgt account) otherwise it won’t work. These RODC Golden Tickets aren’t very useful and based on my initial testing don’t seem to work even when targeting the RODC given the differences betwen RODCs and DCs.
The RODC Golden Ticket is created fine using the RODC KRBTGT, but in my initial testing may not work properly since it has to be passed to the RODC associated with the RODC KRBTGT used to create it. And then the target account service has to have its associated Kerberos service account password cached on the RODC.
However, Silver Tickets are quite useful since we can forge a ticket saying we are a Domain Admin and then connect to the service using this Kerberos ticket (assuming the target service account’s password is on the RODC).
In this scenario, we want to gain admin access to an Admin server, but don’t have direct access to it. We realize that a RODC has cached the password for this server, so we get onto the RODC and dump the AD database to get the admin server’s computer password hash. In this lab environment, the Admin computer is called “ADSEC12ADMIN1”.
Using the computer password hash, we can generate Silver Tickets for the services required to access PowerShell remoting (HOST, HTTP, WSMAN, RPCSS)
Once the Silver Tickets are generated and passed into memory, we can view these tickets in klist.
Note that the Silver Tickets are impersonating LukeSkywalker, though poedameron-admin is logged on (and the Poe account doesn’t have rights to the Admin server). This works because the Admin computer’s password hash is cached on the RODC.
Once all the Silver Tickets are generated and are in memory, we can connect to the Admin server using PowerShell remoting (or any other available service supporting Kerberos authentication).
Jumping Access from RODC to DC using DSRM
Once we gain admin access to a RODC, either by compromising an RODC admin account, a GPO that applies to it, or a system that manages it, dumping the local Windows Security Accounts Manager (SAM) database is a good first step. Yes, Domain Controllers do have a local Administrator (500) account called the Directory Services Restore Mode (DSRM) account. Using Mimikatz, we can get the DSRM account password for the RODC.
There’s a good chance that the RODC’s DSRM password is the same as the one(s) set on writable Domain Controllers. Microsoft has a good write-up on ensuring the DSRM password changes. If the Group Policy applies to all systems in the Domain Controllers OU, it applies to writable DCs and RODCs. Most documentation on the web doesn’t provide the recommendation to exclude RODCs from this configuration.
If we can gain console access to a DC (ILO, virtual console, etc), we can leverage this account to gain admin rights on the DC. Or, depending on how the Domain Controllers are configured, it’s possible to pull AD credential password hashes using Mimikatz DCSync.
Logging on to a DC with the DSRM account:
- Restart in Directory Services Restore Mode (bcdedit /set safeboot dsrepair)
- Access DSRM without rebooting (Windows Server 2008 and newer)
- Set the registry key DsrmAdminLogonBehavior to 1
- Stop the Active Directory service
- Logon using DSRM credentials on the console.
- Access DSRM without rebooting (Windows Server 2008 and newer)
- Set the registry key DsrmAdminLogonBehavior to 2
- Logon using DSRM credentials on the console.
Access DSRM without Rebooting:
PowerShell New-ItemProperty “HKLM:\System\CurrentControlSet\Control\Lsa\” -Name “DsrmAdminLogonBehavior” -Value 2 -PropertyType DWORD
The registry value is located at HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior. Its possible values are:
- 0 (default): You can only use the DSRM administrator account if the DC is started in DSRM.
- 1: You can use the DSRM administrator account to log on if the local AD DS service is stopped.
- 2: You can always use the DSRM administrator account (This setting isn’t recommended, because password policies don’t apply to the DSRM administrator account).
It is possible to use the DSRM Credentials over the network.
When Windows 2000 and Active Directory were released, DSRM being limited to console logon was a good security method. Today, however, there are several methods to logon to a system “at the console”:
- Virtualization Client
- VMWare Remote Console (TCP 903)
- Hyper-V VM Connection (TCP 5900)
- Out of Band Management (Lights Out, etc)
- Network KVM
- Remote Desktop Client when connecting to the “Console” which is “mstsc /console” prior to Windows Server 2008 and “mstsc /admin” with Windows Server 2008 and newer. Tested on Windows Server 2008 R2. Windows Server 2012R2 seems to refuse DSRM logon via RDP console.
Once logged in as the local DC’s DSRM account (DC local admin), we can confirm we are on a DC and that this is the DC’s local administrator account. not a domain account.
Further proof that this is not a domain account.
So what if the DSRMAdminLogonBehavior regkey is set to a non-default value?
Advanced Method for Using DSRM Credentials (Windows 2012 R2)
What’s really interesting about this account is that since it’s a valid local administrator account, it can be used to authenticate over the network to the DC (if the DsrmAdminLogonBehavior regkey is set to 2) . Furthermore, the attacker doesn’t need to know the actual password, all that’s required is the password hash. This means that once an attacker has the password hash for the DSRM account, it can be “passed” to the DC for valid admin access to the DC across the network using Pass-the-Hash. This was tested successfully in limited lab testing on a Windows Server 2008 R2 & 2012 R2 Domain Controllers.
Mimikatz “privilege::debug” “sekurlsa::pth /domain:ADSDC03 /user:Administrator /ntlm:7c08d63a2f48f045971bc2236ed3f3ac” exit
Gaining access to a Domain Controller’s file system is nice, but we can do better!
DSRM PTH to DCSync!
Since it is possible to pass-the-hash for the DSRM account, why not leverage this access to pull password data for any domain account using Mimikatz DCSync. We can target the specific Domain Controller and by using the DC’s short name, we force NTLM authentication.
Mimikatz “lsadump::dcsync /domain:lab.adsecurity.org /dc:adsdc03 /user:krbtgt
If an attacker can gain knowledge of the DSRM account password on a Domain Controller running Windows Server 2008 R2 or 2012 R2 (with the DsrmAdminLogonBehavior regkey set to 2), the DSRM account can be used to authenticate across the network via pass-the-hash to the DC (forcing NTLM authentication). This enables an attacker to retain Domain Controller admin rights when all domain user and computer passwords are changed.
The DSRM account now provides a useful attack method to pull domain credentials, despite the fact it’s a “local” administrator account.
Many thanks to Benjamin Delpy (author of Mimikatz) for his help in figuring this out!
DSRM Attack Mitigation
The only true mitigation for this issue is to ensure the DSRM account passwords are unique for every Domain Controller and are changed regularly (at least as often as other account passwords). Also, ensure the DsrmAdminLogonBehavior regkey is *not* set to 2 – this registry key doesn’t exist by default. Setting this regkey to 1 forces the admin to stop the Directory Services service for DSRM logon to work.
The Registry Key HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior should not exist or be set to 1.
Securing RODCs Against Attack
There are several ways to protect Read-Only Domain Controllers against attacks, most of which involve better restricting RODC access.
- RODCs that cache passwords should be better protected than RODCs with the default configuration that don’t cache passwords. If the RODC is configured to cache any account password, consider protecting the RODC at a similar level to a standard DC.
- Don’t add “Authenticated Users” or “Domain Users” to have their passwords cached on RODCs. If this is truly required, these RODCs should be viewed and protected in a similar manner to writable Domain Controllers.
- Create and configure groups to contain user and computer accounts that would need to be cached on the RODC. This can be scripted to update a group with accounts from specific OUs on a regular basis. This limits the accounts that can be cached to only what’s required and can mitigate issues with admin accounts being cached on the RODC.
- Limit the groups and accounts that have admin rights on RODCs. Ensure regular user accounts aren’t RODC administrators. RODC admins need to be protected based on how the caching is configured – if there are no accounts allowed to be cached, then the RODC admin can be almost anyone. If the RODC is configured to cache almost any domain account, the RODC admin needs to be highly protected.
- Add all privileged groups and accounts to the “Denied RODC Password Replication Group” or another group that prevents account passwords from being cached on RODCs. Since only the default AD admin groups are prevented from being cached on RODCs by default, it’s critical to add any custom groups delegated high-level privileges to Active Directory and critical systems.
- Ensure the DSRM password changes regularly on all DCs. RODCs should either have a unique DSRM password for all of them, or a different one for each. If all the RODCs are configured similarly with the same configuration, it may make sense for them to share a DSRM password (I still prefer a different DSRM password per RODC). If the DSRM password is the same on DCs and RODCs, there’s a chance this password could be extracted from a RODC and used on a DC to gain admin rights on a DC.
- If the RODC is configured to cache passwords, change the RODC’s krbtgt_###### account’s password on a regular basis (2x every year). Microsoft’s krbtgt change script is not geared for the RODC krbtgt account (the risk of changing the RODC krbtgt password is very low). In Active Directory Users and Computers, right-click on the krbtgt_###### and change the password (set it to pretty much anything, Windows should automatically set the password to a random value).
In its default configuration, Read-Only Domain Controllers can provide Domain services to a location without potentially risking the entire domain. The RODC can be configured to cache user and computer passwords to enable local authentication of these users. Administration of the RODC is easily delegated to local staff for on-site RODC management without making them Active Directory admins.
The ability of a RODC to act like a Domain Controller is extremely useful and there are scenarios where it may make sense to allow any account password to be cached. In these cases, the RODC should be considered almost as sensitive as a regular DC.
Furthermore, it’s important to follow the principle of least privilege with RODCs to mitigate potential risk.
If RODCs are not deployed properly, it’s possible that the RODC can create a scenario where an attacker could escalate privileges through the RODC up to and including full control of Active Directory.
This level of access could be acquired either through 1) a highly privileged account cached on the RODC; 2) a highly privileged account logged onto a RODC and is stolen from LSASS; or 3) the DSRM account password is the same on RODCs and DCs.
- RODC Overview
- Read-Only Domain Controller Planning and Deployment Guide
- RODC Technical References
- RODC Authentication Details (with packet captures)
- Silver Tickets
- Mimikatz Reference Guide
- Sneaky Persistence #13 with DSRM
- Sneaky Persistence #11 with DSRM