![]() As part of our Active Directory security review services, we scrutinize RODC configuration and identify potential issues with the configuration. This post shows what is possible given common real world RODC deployment configuration. 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. The information in this post is not from any one customer environment I have seen, but a combination of several. This post covers these scenarios and enables Red and Blue teams to better understand and check RODC configurations for issues. Given certain scenarios, it’s possible to escalate from a Read-Only Domain Controller to a full writable Domain Controller. 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. This post covers a few different scenarios on how to attack Read-Only Domain Controllers in order to escalate privilege. – something that could be deployed in a location that’s not physically secure and still be able to authenticate users. Microsoft customers wanted a DC that wasn’t really a DC. I have been fascinated with Read-Only Domain Controllers (RODCs) since RODC was released as a new DC promotion option with Windows Server 2008.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |