Can’t delete Active Directory object

access-control-listactive-directorypermissions

I've been trying to solve this mystery for a couple of days but I think I've reached a dead end.

We have delegated user creation and administration to a group. This permissions are applied to a Grandparent OU and inherited to a Parent OU and a Child OU, they include everything except for Full Control and Delete (Delete subtree is marked though).

OU Structure

Users from the group can create and modify users on all OUs, they can, however, only delete users from the Child OU (the last level). If they try to the delete a user from the other OUs they get an access denied error.

Things I've already checked:

  • "Protect object from accidental deletion" isn't checked.
  • Compared the effective permissions using objects from the different OUs, they are identical and don't include the Delete permission but do include the Delete subtree permission.
  • Exported the ACLs of users from the different OUs using dsacls.exe. The files are identical.

Weird things I've seen so far:

  • On the Root OU there's a explicit Deny delete (apply to descendant users objects). Shouldn't this also prevent deleting users from the Child OU?

I'm guessing this has something to do with the Delete subtree permission but I haven't found much info about it. Just one more bit, the domain functional level is 2008 R2, if that helps.

Best Answer

Your problem is the explicitly defined Deny delete permission in the "root" (properly called "grandparent") OU, and removing it should solve your problems. It's kind of hard to follow the exact OU structures and which permissions are explicit and which are inherited from your description (a picture is worth a thousands words), but it sounds like, to me:

There is an explicit Deny delete in the root/grandparent OU. It is only functioning on objects in the root, and one level down.

This would be because either:

  1. The Deny delete is only applying to the first level of descendant objects (so it's inherited by the parent OU, but not the child OU), or
  2. The second level of descendant objects (in the child OU) have an Allow delete permission that is of higher precedence.

To resolve the issue and allow your group to delete the objects you want to delete, remove the Deny delete permission at the root OU, or set it to apply to the OU object only (not to its descendant objects).

Here's a handy link to information about permissions precedence in NTFS (which applies to AD permissions as well):

Here are some rules for resolving permissions conflicts:

  1. "Deny" permissions generally take precedence over "allow" permissions.
  2. Permissions applied directly to an object (explicit permissions) take precedence over permissions inherited from a parent (for example from a group).
  3. Permissions inherited from near relatives take precedence over permissions inherited from distant predecessors. So permissions inherited from the object's parent folder take precedence over permissions inherited from the object's "grandparent" folder, and so on.
  4. Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in terms of being "deny" or "allow") are cumulative. So if a user is a member of two groups, one of which has an "allow" permission of "Read" and the other has an "allow" of "Write", the user will have both read and write permission--depending on the other rules above, of course.

Although Deny permissions generally take precedence over allow permissions, this is not always the case. An explicit "allow" permission can take precedence over an inherited "deny" permission.

The hierarchy of precedence for the permissions can be summarized as follows, with the higher precedence permissions listed at the top of the list:

  • Explicit Deny
  • Explicit Allow
  • Inherited Deny
  • Inherited Allow

Also true:

File permissions override folder permissions, unless the Full Control permission has been granted to the folder.

Related Topic