Delegation question.

  • Last Post 26 July 2019
daemonr00t posted this 22 July 2019

Hi folks,

I might be losing a silly spot here but.... I need to allow folks to have Full Control over user objects within AD but not be able to delete them.

Been trying to do it but no success.

Even tried disabling write over lastKnownPart and isDeleted

What am I losing here??


Order By: Standard | Newest | Votes
barkills posted this 22 July 2019

Hm. This may be a fools errand. But here are a few tips that may help you get further.


First, you can’t delegate the ‘Modify permissions’ permission. If you do that, you’ve allowed them to give themselves the ability to do what you didn’t want them to do—which in this case is delete. So add that to your list of permissions

you can’t delegate.


Second, take a look at the ‘Owner Rights’ identity. Owners have built-in permissions, which can stymie any permission delegation scenario if you aren’t paying close enough attention. The ‘Owner Rights’ permission allows you to manage what

used to be a wildcard. When you assign one or more permissions to ‘Owner Rights’, you override all the default permissions for Owners, which means that wildcard is now very specifically defined. It’s a must if you really want to eliminate uncertainty, and

I think you will need to set it in your scenario.


Third, note that there is a difference between permissions and properties. In the Permissions section, each object class will have a ‘Delete X objects’ permission entry possible (provided that object class is shown, which is a detail I’ll

omit for now, but anyone can feel free to ask & I’ll share those details too), where X is the object class. For example, ‘Delete Group objects’. In contrast, in the Properties section, each attribute will have a ‘Write Y’ property entry possible, where Y is

the attribute (or property). For example, ‘Write gPLink’. You probably want to use the Permissions section for this use case.


Finally, for AD security delegation the ordering of ACE resolution is important. For AD, it follows this order (and note that this order is not the same as it is for file servers):

  1. Explicit (non-inherited) Deny entries
  2. Explicit Allow entries
  3. Inherited Deny entries
  4. Inherited Allow entries


There are a set of #2 which show up by default, based on the defaultSecurityDescriptor of the object class. In some cases, that defaultSecurityDescriptor has an identity which can be very large, e.g. ‘Pre-Windows 2000 Compatible Access’

may have every user in it, depending on what options you chose when you setup your first DC (or if you made a change to its membership). I don’t think that will affect your scenario, but I thought I’d mention it just in case. I’d also note that in some lists

of AD ACE resolution, there are five types listed, where the Owner entries are listed first—that’s why you want to make sure you set ‘Owner Rights’ for a custom scenario like yours.





daemonr00t posted this 26 July 2019

Thanks so much for such detailed answer Brian. Brilliant as always.

I en d up pushing back, using part of the technical matters and politics and gave’em a bit more strict permissions so it end up very well.



Sent from Windows Mail