Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

AdminSDHolder

0
0

Folks,

Today is Day-0 of Microsoft's 30-day Active Directory Security School , which starts on March 01. Today, I'll answer the2nd (here's the 1st ) $100 B question I had asked them,which concerns AdminSDHolder , the root of organizational cyber security worldwide.

[The insight I have provided below is worth a proverbial $100 Billion, so in your own interest, you shouldread it in its entirety.]
AdminSDHolder

If you're Microsoft, or one of millions of windows/Active Directoryadmins or cyber security pros worldwide, you know that at the heart, root& foundation of administrative/privileged access in Active Directory lies one Active Directory object - AdminSDHolder .

In the interest of brevity, I'll skip the details and provide a very brief background here. In essence, all default Active Directory accounts and groups that are considered to be administrative in nature by Active Directory are protected with a special protected locked-down access control list (ACL), which is the access control list of the AdminSDHolder object-


AdminSDHolder
AdminSDHolder

Itlogically follows that anyone who can modify the permissions specified in the AdminSDHolder object's ACLcan easily control and impact the security afforded to all default Active Directory administrative accounts and groups, such as Domain Admins, Enterprise Admins, Administrators, Backup Operators, etc., as well as the default Administrator account, and all such accounts.

In other words, anyone (e.g. a rogue or coerced insider, an intruder, APT etc.) whocould modify the permissions specified in the AdminSDHolder object's ACL could instantlyobtain complete administrative control over the entire Active Directory forest!


A $ Billion Question -
So a $ Billion question begs itself , and all organizations operatingon Active Directorymust ideallyhave an exact answer today -
AdminSDHolder

Q: " In our Active Directory domain(s), exactly who can modify the permissions specified in the AdminSDHolder object's ACL? "

(If you're thinking" That's easy; just perform a permissions audit using dsacls, PowerShell etc. ", think again. Its notthat simple.)

$100 Billion side-note: A few days ago, I had posed the same question to Microsofthere. They're likely not going to answer it,so to help Microsoft, as well as 1000s of organizations worldwide, I've answeredthe question below.


The Answer Illustrated

The answer is best illustrated with a walk-throughexample. In your own best interest, I highly recommendgoing through it.

Let us assume that a fictional publicly-held organization is required to identify (i.e. audit) exactly who can modify the security permissions protecting the AdminSDHolder object to demonstrate regulatory compliance, since that is what determines who controls the most powerful and prized privileged/administrative accounts in an Active Directory based IT infrastructure.

To try and answer this question, lets begin by diving right in and launching Active Directory Users and Computers to locate and view the ACL on the AdminSDHolder object -


AdminSDHolder

A closer look reveals that this is a modified (i.e. non-default) AdminSDHolder ACL, in which access changes have been made, as evidenced, for example, by the presence of security permissions that are specified for numerous non-default domain security groups such as IT Contingency Support Team, IT Global Admins Team etc. -


AdminSDHolder

Since this is no longer a default AdminSDHolder ACL, the resulting (effective) permissions/access granted to various individuals by the various permissions specified in the ACL may now differ (likely)substantially from those granted by the default ACL!

For instance, let us consider the impact of the Special security permissions specified for the IT Contingency Support Team -


AdminSDHolder

The Special permissions specified for the IT Contingency Support Team include Allow Modify Permissions and All validated writes. Since it includes Modify Permissions it impacts our answer, so its worth taking a look at the membership of this group .


Acloser look at the IT Contingency Support Team indicates that there is a another domain security group nested inside it -


AdminSDHolder

Upon further expansion, one finds that the IT Contingency Support Team has as a member the IT Data Center Operations Team , which in turn has as member the IT Cloud DevOps Team, which in turn has 12 users that are members of that group -


AdminSDHolder

In essence, this one single Special permission alone ends up indirectly (i.e. via 3 levels of nested group nesting) granting 12 individuals Modify Permissions on this ACL.

However, it should also be noted that there could also be one or more Deny permissions in the ACL that could similarly end up denying one or more of these 12 individuals the same Modify Permissions on this ACL, and thus it is not sufficient to merely analyze any one permission in isolation. Further any such Deny permission may or may not end up negating the Allow , because the resulting accessin this case would also depend on the nature (Explicit/Inherited) of both the Allow and Deny permissions.

Assuch, as seen above, there are many ACEs (access control entries) in the object's ACL (access control list),each one of which allows ordenies a specific security principal (which could be a user, a computer, a security group, a well-known SID etc.) one of more specific Active Directory security permissions, and eachone couldeither have beendirectly (explicitly) specified on the object, or may have been inherited via inheritance of permissions from the ACL in the object's parent.

In essence, the only way to answer this question is to accurately determine the new resulting (effective) permissions/access granted on this object , which involves collectively taking into account the entirety of all permissions specified to all security principals (users, groups well-known security principals etc.),in light of their permissions types (Allow/Deny) and nature (Explicit/Inherited), to ultimately identify all individuals who effectively possess Modify Permissions permissions on this object.

Specifically , not only will one have to correctly resolveallow vs deny conflicts taking into account the explicit vs inherited nature of each permission, but one will have to expand any and all relevant security group memberships, many of which could contain multiply nested groups (some

Viewing all articles
Browse latest Browse all 12749