Deletion Protection And Mysterious Access Denied

Issue:

-         Setup

1.     A group called “delComputerGrp”

2.     A member of delGroup called “delComputerUsr”

3.     OU named “testOU”

4.     delComputerGrp is granted below permission on “testOU” OU

§  Permission: “delete computer objects”

§  Apply to “all descendent objects”

-         Expected behavior

1.     Member of delComputerGrp can delete computer accounts under testOU

2.     This was working

-         Actual behavior

1.     Access Denied

Troubleshooting:

-         Check effective permission on OU level for delComputerGrp, it has the “delete computer objects” permission (expected)

-         Check effective permission on OU level for delComputerUsr, it doesn’t have “delete computer objects” permission (unexpected)
Note: This may be a bug on how Windows calculates effective permission. Although this is puzzling, but it turned out not related what we were going to discover later

-         Found that on testOU, it has “delete all child objects/Deny” ACE. No one has added this entry. This is shown as “DELETE CHILD” in dsacls output

-          In the meantime, the flag “accidental deletion protection” flag is not enabled on testOU

-          When enable “accidental deletion” on OU, here is what happen:On OU protected:

Fig. 2

So even with the protection turned on,  “delete child” is not set to deny. Something else set the “delete child/Deny” entry

Unexpected discovery:

-          By a little bit of googling and testing, I found that when one enables “accidental deletion protection” on an object, AD does not just add the deny permission on target object, it also adds a deny entry on parent container! In summary, when you check the protection box, it does:

1.       On target object (whether it be a leaf object or a container)

§  “Delete/deny” on the object itself

§  “Delete subtree/Deny” on the object itself

2.       On the parent container

§  “Delete all child objects”

-         
Fig 3

-          Back to the problem of deleting computer objects in test OU, it seems that someone has enabled deletion protection a computer (or computers) within testOU. AD then added “delete all child objects” on testOU. This deny ACE on parent container (testOU) effectively cancelled out the “delete compute objects/allow” permission. So even though the intention is to protect only one computer, but it makes delComputerGrp unable to delete other sibling computers.

Why AD needs to set deny permission on parent container to protect a child object?

-         It turns out that there are 2 type of ACE entries that give us ability to delete an object

1.     Delete permission on the target itself

2.     Delete Child from parent

-         As long as one has “delete” OR “delete child” (on parent), he/she can  remove the target object

-         The keyword of above statement is “OR”: Even with “delete” is denied on target, “delete child” from parent still gives one ability to delete the object. In order to truly protect an object, AD has to go one level up and deny the “delete child” permission. It’s a design flaw if you ask me, because it now causes problem that is described at the beginning of this article

Solution

-         Option #1: Remove the “delete child/deny” ACE from parent container (testOU)

1.     This gives the ability to remove computer objects back to delComputerGrp

2.     Computer(s) that need protection still get certain degree of protection (compare to when the flag is not enabled). Just that the protection is not complete - member of delComputerGrp are still able to remove via “delete computer objects/allow” entry (subset of “delete child”)

3.     But the biggest drawback is the “delete child/deny” entry is going to come back whenever anyone turns on the protection on any object in this container

-         Option #2: Instead of give “delete computer objects/allow” permission on (testOU) to delComputerGrp, give it “delete”(all descendent objects)

1.     This gives delComputerGrp more permissions than it should have, it can now remove not only computers, but all other object types - not a least privilege approach

2.     “Delete child” is not going to cancel out delComputerGrp’s ability to remove computer objects now. Because, remember, the condition to delete an object is “delete” OR “delete child”.

Ref.:

http://www.active-directory-security.com/2017/08/how-to-correctly-audit-who-can-delete-an-organizational-unit-in-active-directory.html (Defences, n.d.)

-