Dear Microsoft,
Today is Day-14 of our
Active Directory Security School for you. Today, I will answer the question I had asked on
Day-13 by teaching you how organizations worldwide can
correctly audit who can delete an Organizational Unit (OU) in Active Directory.
Microsoft, like my other posts,
this one too likely impacts Trillions of $ worldwide, so you'll want to read it with utmost attention.
This post also demonstrates the extent to which
your entire global organizational customer-base is operating in the dark today.
So let's proceed, shall we? By the way, if you haven't already done so,
before reading this post, you'll absolutely want to read
this post.
Such A Simple Question
The simple question I had asked in my
last post was -
How do organizations find out "Who can Delete an Organizational Unit in Active Directory?"
Microsoft, you likely may not know the answer to this simple question,
so I'll help you and the world figure out how to do this correctly...
First, Let's Rule out the Incorrect Answer
Before I share the correct answer to this most simple of Active Directory questions, let me help the world rule out the incorrect answer, which incidentally may be how 99% of all organizations worldwide may have been answering this question thus far.
If you were to ask this simple question to most self-proclaimed Active Directory Security experts out there, or even to numerous highly-accomplished Active Directory experts and gurus, or to most vendors in the Active Directory solutions space that develop and sell "Active Directory Permissions Audit" solutions, or to thousands of folks who participate in tech forums such as Microsoft TechNet, here's the answer you're most likely to get -
"Oh, this is easy! Simply find out "who has what Standard Delete permissions on the OU", and that's it!"
Many will suggest that you can
simply use tools like dsacls or acldiag, or
simply write-up a PowerShell Script to do so, and the vendors will suggest using their
Active Directory Permissions Audit tools. Sadly, and unbeknownst to them, they'd all be wrong!
 |
| acldiag on ou=corp,dc=root,dc=local |
In fact, they're not just wrong, they're substantially and dangerously wrong, and yet (and sadly,) this is exactly how most IT personnel at most organizations worldwide may be answering this question at their multi-billion dollar organizations today!
Here's why...
Now, The Correct (And Not So Simple) Answer
This question may be simple, but the answer certainly is not. You see, to answer this question correctly, one needs to consider just what is involved in the deletion of an OU, and although its complicated, I'll do my best to explain it as succinctly as I can -
I. First, The Three Delete Permissions
To begin with, when it comes to deletion, there are three (3) Active Directory security permissions that influence deletions.
- Standard Delete - The Standard Delete permission controls the ability of a security principal to delete the Active Directory object in whose DACL the permission resides.
- Delete Child - The Delete Child permission controls the ability of a security principal to delete a child object directly underneath an object. If the ObjectType member of the ACE in which this permission is specified specifies a GUID of a specific Active Directory object class, the permission only controls the ability to delete child objects of the specified Active Directory class. If the ObjectType member of the ACE does not specify a GUID, then the permission controls the ability to delete child objects of any Active Directory class.
- Delete Tree - The Delete Tree permission controls the ability of a security principal to delete an entire (sub-)tree of objects regardless of the permissions specified on the individual objects in the tree. The root of this tree is the object in whose DACL this permission resides.
II. Second, The Access Checks
When a security principal attempts to delete an Active Directory object, he/she must have one of the following access rights -
- Standard Delete on the object itself, OR
- Delete Child permissions (for that object type) on its parent object
By the way, this isn't some secret; this is straight from Microsoft MSDN right here.
Further, and additionally, if a security principal's deletion request involves the
Delete Tree operation, then if the security principal has sufficient (i.e. effective)
Delete Tree permissions on the object that is the target of that operation, then he/she will be able to delete the entire tree of objects regardless of the permissions granted on the child objects.
III. In Light of the Above, Consider This -
With the above theory in mind, now let us consider what it might take to delete a top-level Organizational Unit (OU) that may have thousands of Active Directory objects (such as domain user and computer accounts, security groups and OUs) within it.
In order to be able to successfully delete this top-level Organizational Unit -
- If the user has sufficient Delete-Tree effective permissions on the OU AND he/she uses the Delete Subtree Control, he/she will be able to delete the entire OU irrespective of the permission specified on all the child objects in the OU.
- If the user does not have sufficient Delete-Tree effective permissions on the OU, then he/she will only be able to delete the entire OU if he/she has sufficient access so as to be able to delete the entirety of all objects contained in the OU (including the OU object itself), and by that I mean that in order to be able to delete the entire OU, he/she will need to have ON EACH OBJECT in the OU (including on that OU object itself), either OF 1) Standard Delete effective permissions on the object, or 2) Delete-Child effective permissions on its parent object.
In short, as one can see, in order to be able to determine who can delete an OU in Active Directory, irrespective of whether or not it is a top-level OU, organizations will have to determine effective permissions on EVERY SINGLE OBJECT in that OU!
Thus, to
correctly find out who can
actually delete a top-level Organizational Unit (OU) that may contains thousands of Active Directory objects, IT personnel will need to accurately determine effective permissions on thousands of Active Directory objects!
IV. Oh, The Most Important Part
Now, the most important part here is not that IT personnel will have to audit access on not just one Active Directory object (i.e. the OU itself,) but on thousands of Active Directory objects; that of course is very important. The MOST IMPORTANT part here is that IT personnel will need to determine
Active Directory Effective Permissions on thousands of Active Directory objects!
I cannot stress this enough - to make this determination, today, all that most organizations may be doing is trying to find out "
who has what permissions on an Organizational Unit('s object)" WHEREAS what they need to be doing is trying to find out "
who has what effective permissions on all the objects in that Organizational Unit( including that OU object itself)."
I'll say that again. Today most organizations are likely merely performing a useless "
Active Directory Permissions Audit" on the OU object itself to try and find out who has Delete permissions on the OU. What they need to be doing is performing an "
Active Directory Effective Permissions Audit" on not just the OU object itself, but on every single object in that OU, to find out who effectively has the effective permissions I have mentioned in point
3 above!
The difference is HUGE, and in fact, the difference between having accurate and inaccurate insight could mean the difference between preventing someone from being able to enact a MASSIVE denial-of-service attack or letting them successfully do so!
Microsoft, hopefully now you and thousands of organizations worldwide can see why it is not only completely useless to perform an "
Active Directory Permissions Audit" but also that infantile tools like dsacls, acldiag, PowerShell, or any one of many Active Directory permissions audit tools from any one of numerous vendors out there cannot help make this determination accurately!
Side-note: For folks on Twitter, such as one who said this regarding this - "That's it? Make sure your delegation is tight and...no big deal" (here), well this is also what one might consider a delegation in Active Directory, and so trying to find out who can delete a top-level OU would fall under making sure your delegations are tight.
Thus, I'd really like for this gentleman to not just talk the talk, but walk the walk, because there is a mountain of a difference between the two, and since he makes it sound so easy, perhaps he should show the world how to make sure this delegation is tight! (Even if he tried for a 100 years, I doubt he'd likely be able to do it.)
Click, Done.
We just established above that trying to find out who can delete a top-level Organizational Unit could be a massive challenge, since it would require organizations to determine effective permissions/access on potentially thousands of objects in that OU.
Now,
thanks to you Microsoft,
thousands of organizations worldwide don't even seem to know what "
effective permissions" are, so obviously for them to possess the ability to determine "effective permissions"
correctly is to expect too much from them, in which case obviously, trying to do the above would be almost impossible for them!
So, wouldn't it be nice if someone could make this almost impossible problem a little easier to solve for the whole world?
I think it would.
How easy you ask? Well, how about as easy as touching
a single button?!
(Wait, isn't this supposed to be almost impossible?) ...
Here you go (; isn't it amazing what half a decade of laser-focused innovative R&D can do?) ! -
 |
| Gold Finger - Active Directory Effective Access Audit Tool |
What you're seeing above is a snapshot of the world's only accurate
Active Directory Effective Access Calculator, a tool that can instantly and of course accurately audit and reveal exactly who can delete entire organizational units in any Active Directory in the world, even one that contains thousands of Active Directory objects in it, within a matter of minutes, if not within seconds!
If you wish to see the complete output of this effective access assessment on the
Corp OU, you can download it from
here.
In fact, not only can it accurately audit and reveal who can delete OUs, it can accurately audit and reveal who can enact 100+ administrative tasks that can be enacted on Active Directory content, such as
exactly who can create, delete and manage OUs, accounts, groups etc. anywhere in Active Directory +
how they can do so, which is what we need to know to tighten delegations.
This powerful tool is unique in is ability to
correctly audit who can delete an organizational unit in Active Directory, in light of the technical details I've shared above, and irrespective of whether the organizational unit contains 100 objects or 100,000 objects.
A Picture Speaks a 1000 Words
The substantial complexity in trying to audit who can delete an OU in Active Directory is perhaps best illustrated with pictures -
If you take a closer look at the
Status message in the snapshot of the tool displayed above, you will see that it indicates that during the process of trying to find out who can delete this one single top-level
Corp OU, the tool analyzed 11528 ACEs!
That's a bit intriguing, because all we requested was an effective access assessment on a single object i.e. a single top-level OU named
Corp, yet the status message indicates that the tool had to analyze
11,528 access control entries (ACEs) to make this one single determination! There couldn't possibly be that many ACEs in the ACL of a single Active Directory object!
This definitely merits a closer look!
In the interest of time, I'll make this super simple for you...
First, in one second, using Gold Finger's
Active Directory Security Audit Tool, we find that
there are 263 objects in the Corp OU:
Next, in less than five seconds, using Gold Finger's powerful and comprehensive
Active Directory Permissions Analyzer, we determine that there are indeed a total of
11494 access control entries (ACEs) on the
263 objects that exist in the
Corp OU -
(In fact, an instant
Corp OU-wide
ACL dump performed with Gold Finger's
Active Directory ACL Exporter tool confirms this.)
Now, some basic Kindergarten math i.e. subtracting 11494 from 11,528 leaves us with
34 ACEs.
Hmm, if we consider the
Corp OU's parent object i.e. the domain root, and use the Gold Finger
Active Directory ACL Viewer to view its ACL, we see that there are
exactly 34 ACEs in the ACL of the
Corp OU's parent object, i.e. the domain root object -
(By the way, in case you want to view the entire ACL as exported from this nifty tool, it can be downloaded from
here.)
Thus, if in the process of determining effective access to find out exactly who can delete the
Corp OU, Gold Finger analyzed 11,528 ACEs to make this assessment,
it must have analyzed 11,494 ACEs that exist in the ACLs of the 263 objects in the Corp OU (including the Corp OU's ACL itself)
as well as the 34 ACEs that exist in the ACL of its parent object, the domain root, since
11,494 + 34 = 11,528!
In other words, to find out who can delete a single top-level OU, one needed to determine effective permissions on not just every single object in the OU, but also on the parent of the OU object!
Here's why -
- It needs to determine who has sufficient Delete-Tree effective permissions on the Corp OU object itself, because all users who have this effective permission on the OU will be able to delete the OU.
- It needs to determine who has sufficient blanket Standard-Delete effective permissions on the Corp OU object itself AND either Standard-Delete effective permissions on every single object in the OU OR Delete-Child effective permissions on the parent of every such object , because all users who have this combination of effective permissions in this subtree will also be able to delete the OU.
- It may optionally need to determine who has sufficient blanket* Delete-Child effective permissions on the Corp OU object itself, if this OU only had a single level of child objects in it, because then all users who have this effective permission on the OU will also be able to delete the OU.
- Finally, it needs to determine who has sufficient Delete-Child effective permissions on the parent of the Corp OU object i.e. the domain root object, since that will also influence who can delete the Corp OU (assuming all such users also have sufficient access to be able to delete all objects in the Corp OU except the Corp OU object itself!)
Note - Strictly speaking, there is one other case to take into account (, and our unique tool can optionally take that into account) but I'm not going to mention it here.
So you see, in order to answer what is seemingly such a simple question, one needs to accurately determine effective permissions on every single object in the OU as well as on its parent object!
Now, in the simple example we saw above, there were only about 260 objects in that top-level OU. In the real world, at so many organizations, there are thousands of objects in a top-level OU. In fact, at many large organizations there could be well over 50,000 to a 100,000 objects in a top-level OU!
At most of these organizations, let alone possessing the ability to accurately determine effective permissions in Active Directory, thanks to the lack of any guidance whatsoever from Microsoft, IT personnel may not even know that to make this seemingly simple determination, they need to be able to determine effective permissions on thousands of objects!
Oh, and this is how much effort it takes to make this determination on one OU. What if an organization had 50 or a 100 OUs?! (One of our customers had 20,000 OUs in their Active Directory.) To do so, you'd have to proverbially scale Mount Everest!
[A Small Digression...
The Protect Object from Accidental Deletion Feature
This discussion wouldn't be complete without a quick mention of your feeble
Protect Object from Accidental Deletion feature, which is (more of a hack than a feature) designed to accomplish exactly what it states i.e. prevent accidental deletions of OUs.
I imagine that so many organizations out there must think that if this feature is enabled on an Organizational Unit, then that Organizational Unit cannot be deleted, PERIOD. That is a misconception that should be clarified for everyone once and for all.
You see, when you activate this feature on an Organizational Unit, all that the System does is that it introduces two access control entries, one on the object on which it is activated, and one on its parent object, and these are the ones -
Deny Everyone Delete, Delete Subtree (This one is in the ACL of the target object)
Deny Everyone Delete All Child Objects (This one is in the ACL of the parent object)
It is the presence of these two explicit deny permissions that protects the target object from being accidentally deleted.
Now, of course, anyone who could change the permissions on either the target object or on its parent object could effectively undo, modify or remove these permissions, leaving the object vulnerable to deletion, whether it be accidental or intentional.
But more importantly, it doesn't even take that much to intentionally circumvent this feature!
Specifically, anyone who has sufficient
Delete-Tree effective permissions on the parent** object of the object that is protected from accidental deletion could effectively delete the entire subtree rooted at the parent object, and as a consequence, this object (and if happens to be the root of a subtree, such as a top-level OU, then that entire OU) too would end up getting deleted!
So, if you truly want to know exactly who can delete an Organizational Unit, even one that is protected from accidental deletion, you'll also want to find out who has sufficient
Delete Tree effective permissions on its parent*** (and technically, all the way up!)
For instance, let us consider another example in which we take a look at the
Cyber Security OU (whose properties are displayed in the snapshot above) which as one can see in the snapshot above, is
protected from accidental deletion.
As seen below, when a user Michael Karp tries to delete this
Cyber Security OU, he is (consequently) unable to do so -
However, if we analyze Active Directory Effective Permissions on the parent OU of the
Cyber Security OU, which is the
Corporate Security OU, we see that although Michael Karp may not be able to delete the
Cyber Security OU, he does in fact have
Delete Tree effective permissions on its parent object,
Corporate Security OU -
To see the complete output of the effective permissions audit on the Corporate Security OU, you can download it from
here.
So, Michael Karp launches LDP and tries to delete the parent OU, i.e. the
Corporate Security OU using the
Delete Tree control, and he is successfully able to do so, as a result of which the entire
Cyber Security OU (which was protected from accidental deletion)
is now also deleted -
In the LDP snapshot above, here's what the four numbers indicate -
- Unsuccessful attempt to delete the Cyber Security OU (since its protected from accidental deletion)
- Unsuccessful attempt to delete the Corporate Security OU (i.e. the parent OU) using various standard delete options
- Successful deletion of the entire Corporate Security OU using the extended Delete Tree operation and control
- Confirmation that the entire Corporate Security OU no longer exists i.e. no such object!
So you see, this little (hack of a) feature does exactly what it says, prevent an object from accidental deletion!
... End of Small Digression.]
Scaling Mount Everest
Now, just prior to the small digression above, we had started giving some thought to just how much effort it might take to make this determination in an Active Directory domain that had numerous OUs (e.g. 20+), and I had had left it by saying that to do so, one would have to proverbially scale Mount Everest!
Consider that you needed to find out exactly who can delete every single OU in an Active Directory domain that had 50 OUs.
How would you do so? Well, you would have to manually perform the above process on every single OU in the domain (, and by now I shouldn't have to tell you that not only is that almost impossible, if attempted it could take months to do!) OR ...
What if someone could fully automate performing this Herculean feat for the world, so all you had to do was touch a button?!
Here you go (; its amazing what else half a decade of laser-focused innovative R&D can do) ! -
What you're seeing above is a snapshot of the world's only accurate and fully-automated
Active Directory Administrative Access / Delegation Audit Tool, a tool that can instantly and of course accurately audit and reveal exactly not only who can delete every single entire organizational unit in any Active Directory in the world, even one that may contain thousands of Active Directory objects in it, within a matter of minutes, if not within seconds, but in fact can accurately audit and reveal exactly who can perform virtually the universe of all administrative tasks that may be possible in Active Directory.
If you wish to see the complete output of the domain-wide OU deletion effective access audit, you can download it from
here.
For example, not only can it accurately audit and reveal exactly who can delete every single OU in an Active Directory, it can also accurately audit and reveal exactly who can create, delete and manage every single domain user account, domain computer account, domain security group, container, OU, service connection point, print-queue etc. in Active Directory.
As it pertains to object deletions, simply put, whether you have one OU in your Active Directory or whether you have 100s of OUs, this tool can instantly, automatically and above all, correctly determine exactly who can delete each one of these OUs.
(Of course, if it couldn't deliver such
paramount cyber security insight at the touch of a button, it wouldn't be called
Gold Finger, i.e. a tool that can deliver informational security gold at the touch of a single button (i.e. at the tip of a finger), thus the name.)
But, this isn't about promoting the tool so I'm not going to say any more about it. The only reason I mentioned it, is to prove that
if one truly cares for the world and puts one's mind to it, even such an incredibly difficult technical challenge can be solved. In contrast, you (Microsoft) couldn't even
educate the world about the importance of effective permissions over an entire decade :-(
This Impacts of Trillions of $ Worldwide
Microsoft, as you obviously know, literally the entire world is running on Active Directory today. In effect thousands of organizations, many of whose market capitalization is easily in the billions of dollars, operate on Active Directory.
Consequently, today foundational Active Directory deployments help secure and protect trillions of dollars of wealth worldwide.
Now, at these organizations, the entirety of their domain user accounts, computer accounts, security groups etc. all reside in their foundational Active Directory deployments, within organizational units of course!
At most of these organizations no one has any idea as to exactly who can delete not just all their OUs, but even their top-level OUs in their foundational Active Directory deployments, and thus most of them may be minutes away from an intruder or a malicious insider being able to launch a crippling denial-of-service attack in seconds, by simply deleting their top-level OU(s)!
Were such an attack to be launched on them internally, organizations that have up-to-date backups may experience an entire day of downtime, and organizations that do NOT have up-to-date backups could experience days (if not weeks) of downtime!
Now, I don't have to tell you how much one day of downtime could cost a multi-billion dollar organization that has thousands of employees. This would in effect be a massive organization-wide denial-of-Service attack most easily executed in ONE second!
Oh, and if you know of any company that could survive weeks of downtime in today's fiercely competitive world, let me know.
In essence, due to a complete global lack of ability to obtain
accurate effective access insight into something as simple as who can delete an organizational unit in Active Directory, trillions of dollars of wealth across the world could be so easily impacted!
In Summary
Microsoft, in summary, here are the salient points I wanted to convey to you concerning this vital topic -
- Active Directory is the foundation of cyber security at 1000s of organizations worldwide, and in the Active Directory deployments of these organizations, all their building blocks of cyber security are stored in Organizational Units.
In the Active Directory of most organizations, an excessive number of individuals may have sufficient effective permissions/access to be able to delete these Organizational Units, yet no one knows exactly who they are.
- Should someone be able to delete one of these Organizational Units, especially a top-level one, he/she would basically and most easily have inflicted a massive internal denial-of-service (DoS) attack on the entire organization within minutes, since no one (including of course all employees, contractors, senior executives including C*Os, as well as IT personnel) will be able to log-on or engage in their computing activities, until the Active Directory is restored using a backup.
Organizations that have an up-to-date backup of their Active Directory may be able to recover within a day, but at organizations that do not have an up-to-date AD backup, it could take weeks to recover from such an attack.
- Organizations thus must know at all times exactly who can delete their Organizational Units. This is not just a "nice to know" thing; this is an integral part of cyber security and thus a responsibility the organization has to its stakeholders, predominantly its shareholders as well as its customers, partners, employees and others.
- Sadly, thanks mostly to you Microsoft, IT personnel at most organizations worldwide don't even know how to correctly audit who can delete their OUs, so obviously they are far away from being able to identify and lockdown who could launch such a simple yet massive internal DoS attack that could cost them millions of dollars per occurrence.
-
Let alone possessing the ability to help these organizations figure this out, you haven't even educated them about how to correctly do so, which is concerning, given that you're going all out to woo the world to embrace your Cloud offering!
I felt that it was important for organizations worldwide to know why it is so important for them to know exactly who can delete their Organizational Units, esp. top-level OUs, so, above I have now educated them about how they can do so.
I just find it concerning that even though here we are in 2017, i.e. 17 years
after Active Directory was shipped, and yet someone is having to explain such a basic and fundamental aspect of Active Directory and cyber security to the world!
Given
what it is we do here at Paramount Defenses, my time is very valuable, and while we're doing our bit to help secure and defend organizations worldwide, you, the $550 B Microsoft, need to do your bit by
educating your customers about this stuff!
We are here to help them, but we cannot educate them
all about such basic cyber security stuff - that's
your responsibility.
Best wishes,
Sanjay
PS: To Satya and team at Microsoft, you may want to ask your IT folks if they know exactly who can delete your own OUs. If they too need help figuring it out, feel free to give us a call, and time permitting, we'll be happy to consider helping them out.
Aug 30, 2017 Update - I penned
this today to help organizations better understand the importance of what is shared above.
