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 . A domain user having the Administrator role can do maintenance work on the RODC such as installing software. The Password Replication Policy determines the user groups for which passwords caching will be allowed . If a password isn’t cached, the RODC will forward the authentication request to a writeable DC.

RODC can actually enhance the local authentication but you need to cache the local computes password to form a secure channel with RODC else it will query RWDC. There’s a good chance that the RODC’s DSRM password is the same as the one 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.

Click thePromote this server to a domain controllerlink that appears in the notification. Read-only AD database– RODC host read only database where we cannot make any changes directly. Applications or tools that need read only access of database can use the RODC. So, by putting RODCs in place, we are helping local users to authenticate and authorized same as writable DCs, but at the same time we are protecting our organization from any possible outage. In following few posts, we will practically see how we can setup a RODC and what all additional settings we need to configure.

Adprep /rodcprep should be executed on the DC holding Domain Naming Master FSMO role not on any DC. It is not mandatory to run Adprep /rodcprep in existing windows 2000 or 2003 AD environment until you plan to deploy RODC may be now or in future. There is one more prerequisite you need at least one writable DC in windows 2008 before you can deploy RODC in existing windows 2003 AD environment, since RODC doesn’t consider windows 2003 DC. 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.

How Are RODCs Managed?

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. 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.

• Administration– Writable DC are administered by the domain Administrators and Domain Admins groups; however, membership in these groups also grants enhanced Active Directory rights.
• This attack would work against any account not currently listed in the RODC’s msDS-NeverRevealGroup attribute explicitly or through group membership.
• 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.
• Federation enables internal users to be authenticated to external systems without exposing the internal Active Directory to the DMZ or systems on the internet.

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 . 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.

More from Posts By SpecterOps Team Members

Limit the groups and accounts that have admin rights on RODCs. 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.

1.Log on to DC01, as windowstechno\administrator, then open theCommand Prompt, typeNTDSUTILand pressEnter. Better access to the authentication resource on the network. Unidirectional replication–The RODC https://forexaggregator.com/ can’t spread misinformation to the rest of the domain, even if a change is made on the RODC. This reduces the risk of a system-wide assault and reduces the complexity of the replication structure.

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. 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. 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 .

If you compromise an account listed in the managedBy attribute of an RODC, you have local admin on the RODC. And if you compromise an account with delegated rights to modify the managedBy attribute of an RODC, you can make yourself an admin. The managedBy attribute does not usually serve any function for an AD object, although it can be used for organizational purposes. Any user or group specified in the managedBy attribute of an RODC has local admin access to the RODC server (thanks to Guido Grillenmeier for teaching me that!). While the RODC hosts and the credentials for their computer accounts do not belong in Tier Zero, all RODC computer objects must be protected as Tier Zero resources. Once you click Promote this server to a domain controller and chooseAdd to an existing forest, you’ll check the checkbox called Read-only domain controller to promote the DC to an RODC .

Installing an RODC

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 . Any service accounts with privileged rights should be added to a group Native Mobile App Development which is configured to prevent member account passwords from being cached on RODCs. If this isn’t done and the RODC is allowed to cache all account passwords , then highly privileged accounts could have passwords cached on the RODC.

RODCs can only receive replication from a 2008 writable DC. This replication method is the same for replicating SYSVOL. Using an RODC at your local site allows you to offload services off the pipe, to the RODC, again limiting bandwidth requirements to AD synchronizations and delta synchronizations. This allows your bandwidth to be used for more important things like Line of Business applications, e-mail, etc.

Also, because the domain controller isn’t writable, the thief cannot power on, inject data in to Active Directory and have it sync to your other domain controllers if they somehow gained access to your internal network. RODCs are an alternative for Domain Controllers in less secure physical locations. They maintain a filtered copy of AD, excluding sensitive attributes, such as LAPS passwords, to support LDAP queries, and cache credentials for selected users and computers to support authentication. Typically, an RODC would be allowed to retrieve and cache credentials only for accounts that belong to the same physical location, such as a branch office, and have an equivalent or lower level of physical security.

Most documentation on the web doesn’t provide the recommendation to exclude RODCs from this configuration. Using the Mimikatz command to just pull the krbtgt account data works against the RODC as well. Since Read-Only Domain Controllers are not supposed to be managed by Active Directory admin accounts , finding a RODC admin account to compromise often isn’t difficult. 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. This means if there are multiple RODCs in the same site, they may have different accounts cached and possibly different password policies.

Attacking Read-Only Domain Controllers (RODCs) to Own Active Directory

In this attack, Leandro obtained NT hashes of the targeted account by abusing the mechanism RODCs use to obtain NT hashes of users to support NTLM authentication locally. While RODCs, by definition, are not part of the set of resources that can control “enterprise identities”, known as Tier Zero, we have seen cases where there is a privilege escalation path from an RODC to domain dominance. The newly implemented Read-Only Domain Controller in Windows Server 2008 provides a way to increase the security of servers whose physical security cannot be assured. The replication happens in RODC is unidirectional means changes made on RODC is not replicated to RWDC, but you can still connect to RWDC console from RODC and make modification on RWDC which is still vulnerable. RODC can’t provide substitute for a DC when WAN link is down and the reason is RODC can’t issue Kerberos ticket to the domain clients. RODC can’t navigate the trust and it only utilizes the RWDC in other domains.

Authentication occurs when a user first logs on to his or her computer in the morning. Service tickets are a component of the Kerberos authentication mechanism used by Windows Server 2008 domains. RODCs that cache passwords should be better protected than RODCs with the default configuration that don’t cache passwords.

What is an RODC

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 , 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. In Part 1, Protecting the Active Directory Domain Services – Best Practices for AD administration, I focused on protection steps to protect your domain service locally.

This eliminates the exposure of the directory service to corruption resulting from changes made to a compromised branch office DC. Finally, RODCs, unlike writable DCs, have a local Administrators group. You can give one or more local support personnel the ability to maintain an RODC fully, without granting them the equivalence of domain administrators.