Folks,
Hello. I hope this finds you all doing well. This post is Day-8 of
Active Directory Security for Cyber Security Experts.
Today, I will help you learn how organizations that operate on Active Directory can easily and accurately answer an absolutely
essential and
paramount cyber security question that impacts their foundational cyber security -
Exactly who can change the membership of the Domain Admins group?
It is extremely important to know how to do so
correctly because a single incident involving the unauthorized change of the membership of the
Domain Admins privileged security group could
instantly result in a massive cyber security breach.
This is Paramount
The
Domain Admins privileged group in Active Directory holds the proverbial
Keys to the Kingdom and anyone who could
change the membership of the
Domain Admins group could
instantly cause a
massive cyber security breach.
Unfortunately, today, most organizations only audit the
membership of the
Domain Admins group; they do not audit who can
change its membership, and those that do usually do so incorrectly, leaving themselves vulnerable to compromise.
How to Correctly Make This
Paramount Determination -
From a technical perspective, there is only one correct way to find out exactly who can change the membership of the
Domain Admins security group and that involves accuratley determining
Active Directory Effective Permissions on it.
Specifically, technically speaking, all that one needs to determine is exactly who has
Write Property effective permissions to modify the
Member attribute on the
Domain Admins object,
cn=Domain Admins,cn=Users,dc=… in Active Directory.
A Step-by-Step Walkthrough
This is perhaps best illustrated with a simple example, so let us see how to find out who can change the membership of the
Domain Admins security group in the lab
Active Directory Security VM that everyone can freely download and use.
Consider the
Domain Admins security group in the lab VM domain,
corp.local -
As one can see, the all-powerful
Domain Admins security group contains 3 members, including the default
Administrator account, the
IT Directory Services Management Team security group and the
Privileged Service Accounts security group.
Let us proceed to
determine the complete nested membership of the
Domain Admins security group in the
corp domain -
As seen above, there are a total of
13 accounts that are member of the
Domain Admins security group in this domain.
- Note - Today, at most organizations, security audits are limited to enumerating the membership of the Domain Admins security group. Most organizations do not perform the extra measure of additionally also determining exactly who can change the membership of this group, even though knowing that is equally important.
As indicated above, to find out exactly who can change the membership of the all-powerful
Domain Admins security group, we need to find out exactly who has
Write Property effective permissions to modify the group's
Member attribute.
To do so, let us begin by examining the ACL (access control list) protecting the
Domain Admins security group -
As one can see above, there are numerous security permissions granted to numerous security principals in this ACL, and unfortunately it does not appear easy to examine the object's ACL easily using Microsoft's native ACL editor in ADUC.
To help make ACL analysis easier, perhaps we should view the object's ACL using an
Active Directory ACL Analyzer -
As seen above, the detailed, easily sortable high-fidelity view makes it so much easier to analyze this object's ACL. We can now easily see that there are a total of
20 security permissions specified in the ACL, including
4 Deny permissions.
A simple examination of the CSV export of this ACL from the tool helps us
clearly identify just what we need to analyze -
Specifically, we can now easily see that of the 20 permissions in the ACL, there are
only 10 permissions that impact
Write Property access on the object, of which 9 grant blanket writes and 1 grants write-property only to the
Member attribute.
Equally importantly, notice that of these 10 permissions,
6 allow access and
4 deny access, and as a result, not only will we have to expand the group memberships that are allowed access, but also expand the group memberships that are denied access, and strike
off (i.e. remove from) the
Allowed list, any accounts that are also on the
Denied list.
Here are the
6 security groups/principals that are
allowed blanket/member Write Property access -
- IT Cyber Security Team - Membership: 5 individual user accounts
- Domain Admins - Membership: 3 nested security groups
- Enterprise Admins - Membership: 3 nested security groups
- IT Admin Support Team - Membership: 5 individual user accounts and 1 nested security group
- Administrators - Membership: 1 individual user account and 2 nested security groups
- System
Similarly, here are the
4 security groups/principals that are
denied blanket/member Write Property access -
- Spartacus Program - Membership: 6 individual user accounts
- IT Local Admin Teams - Membership: 3 nested security groups
- IT Help Desk Team - Membership: 10 individual user accounts and 1 nested security group
- IT Contractors - Membership: 30 individual user accounts
Thus, in order to accurately make this determination, we will first need to completely expand
13 nested security groups, take into account the direct membership of
50 user accounts, and then
meticulously ensure that any user that is both on the
Allowed list and on the
Denied list is struck off the
Allowed list.
In this simple fictional domain, there were only 10 such relevant permissions. In most real-world Active Directory domains, there will easily be many more relevant permissions, and many more groups to expand and conflict resolutions to perform, making this process really difficult, error-prone and time-consuming to perform, and do so with 100% accuracy, each time.
By way of example, if you proceed to meticulously perform all of the security group expansions above in the lab
corp.local domain, you will find that there is at least one user,
Simon Baker, who is on both, the
Allowed and the
Denied lists.
Specifically, the
IT Admin Support Team, which is allowed the relevant write-property access contains a nested group,
IT Admin Support Backup Team, and
Simon Baker is a member of this group, so via a nested group membership he does make it on to the
Allowed list. However, it turns out that
Simon Baker is also a direct member of the
IT Help Desk Team, which as one can see above, is
denied the relevant write-property access, and so he is also on the
Denied list.
In effect, the
deny will take precedence over the
allow, and as a result, even though he is on the
Allowed list,
Simon Baker will
not be able to change the membership of the
Domain Admins group!
As clearly illustrated above, the process involved in trying to manually make this determination is substantially
complex, error-prone and time-consuming, even when it is essential that there be no mistake, because
accuracy is paramount.
It is also worth noting that if we had simply performed
Active Directory permissions analysis, even by using a highly capable
Active Directory Permissions Analyzer, we would have been making incorrect conclusions, as seen below -
As one can see above, even an advanced Active Directory Permissions Analyzer will report that there are
31 individuals who have been
allowed relevant Write Property permissions, including blanket and specific (to the
member attribute), and in particular they will report that
Simon Baker is also on this list, when in fact
Simon Baker is also
denied the same access, so he will in fact not actually have the allow access reported by an Active Directory permissions analyzer!
The above example also clearly illustrates why it is not sufficient to merely analyze "
Who has what (allow) permissions?" (which incidentally is what most commonly used tools do), because one also needs to correctly intersect deny permissions.
Finally, it is also worth noting that in this specific example, there were no inherited permissions because the ACL protecting the
Domain Admins group is a
protected ACL. In contrast, the ACLs of most Active Directory objects are not protected, and so there could easily exist both explicit as well as inherited permissions, making the conflict resolution even more complex, because not all deny permissions will negate/override allow permissions. There is a specific order that one needs to know about and take into consideration to correctly perform conflict resolution, and in production domains, this is
very difficult.
Now, many folks may point out that there is an
Effective Access Tab,
accessible via
Advanced Security Settings in Active Directory's native tooling that is designed to help calculate effective access/permissions in Active Directory. Yes, there is -
However, if you have ever tried to use it, you know that it is almost useless because of 3 simple reasons - 1) it is not 100% accurate, 2) it can at best calculate an approximation of effective permissions ONE USER AT A TIME, and 3) it cannot pinpoint which underlying security permission in the object's ACL entitles a user to a specific effective permission.
For instance, if you had a 1000 user accounts and a 1000 computer accounts in your Active Directory forest, you would have to use the tab at least
2000 times just to make this one determination, and that too would not be 100% accurate!
- Note: For the details of these limitations in Microsoft's Effective Access Tab, you may wish to read this post.
So,
how are organizations supposed to make this
paramount determination accurately and easily?
We value our time so we use
an automated tool that automates the entire process of making this determination for us, reducing the amount of effort involved down to touching a button, and the amount of time required down to seconds -
As seen above,
in less than 30 seconds, we were able to accurately determine that there are a total of
30 individuals (i.e. accounts) that in effective have
Write Property Member effective permissions on the
Domain Admins security group.
[ Solely by way of background, this tool is the world's only accurate
Active Directory Effective Permissions Calculator and it can instantly and accurately determine the complete set of effective permissions entitled on any Active Directory object. ]
Now, not everyone tasked with making these paramount determinations (e.g. an IT Auditor, an IT manager etc.) may be proficient in Active Directory, so they may not know how to perform this audit using an effective permissions calculator.
Individuals who may not be proficient in Active Directory could use the following tool to make this determination in simple English without having to know anything about Active Directory (e.g. attributes, permissions, effective permissions etc.) -
As one can see above, this tool, an
Active Directory Effective Access Auditor, delivers the same information but in very simple to understand non-technical parlance, making it very easy for non-technical individuals, such as IT auditors, IT managers and IT executives to easily make this determination without knowing anything about Active Directory.
Finally, lets say you wished to find out who can change the membership of not just the
Domain Admins security group, but of all security groups that reside in the
Users container, such as and not limited to
Enterprise Admins,
Schema Admins etc.
To fulfill this paramount need, some of the world's top organizations rely on the
Active Directory Privileged Access Auditor to make this determination, and do so in minutes. Simply point the tool to the
Users container and click a button -
This tool automatically identifies all domain security groups in the specified scope, then automatically determines effective permissions on each one of them, and reveals exactly
who can change the membership of every group in the set scope.
Of course, organizations can also make these determinations manually, without using any of the above mentioned tools, by simply having their IT personnel engage in the process outlined above, whenever required. The manual process may be substantially more time-consuming, expertise-reliant and error-prone, but it doesn't require procuring any tools.
Over the last decade some of the most important and valuable organizations in the world, including the U.S. Treasury, have used the tools mentioned above because they save their IT teams a mountain of effort and thousands of hours in time, and because they happen to be the only way to accurately make such determinations without investing a substantial amount of time and effort.
In essence, today organizations can make this paramount
determination both manually, as well as automatically.
Conclusion
The objective of today's post was to help thousands of organizations, their IT personnel, IT Auditors and CISOs learn how to correctly make a paramount determination in their foundational Active Directory deployments.
As we saw above, technically speaking, all that one needs to determine is exactly who has what sufficient
Write Property Member effective permissions on the
Domain Admins security group.
As we also saw above, in any real-world Active Directory domain, it is not at all easy to manually make this determination with accuracy, even though accuracy us paramount because a single unauthorized user who could enact this task could take over the entire organization in minutes.
Most importantly, as we saw above, albeit there were only
13 accounts that were members of the
Domain Admins security group, we were able to identify that there were a total of
30 accounts that could actually change the group's membership!
Thus, organizations that may only be relying on performing basic group membership audits are very likely operating on a dangerously false sense of security today, because as seen above, the number of accounts that can
change the membership of the
Domain Admins group are
far greater than the number of members in the group!
Organizations that do
not know exactly how many individuals (employees, contractors, service accounts etc.) can actually change the membership of their all-powerful
Domain Admins security group may be at a substantial risk of compromise.
I will conclude this post here. I'll share the next question in a day or so, and answer it on Monday, August 17, 2020.
Thanks,
Sanjay.
