(2008-02-21) Delegated Permissions And Owner Permissions
Posted by Jorge on 2008-02-21
Isn’t it great when you have created your own delegation model in AD to manage all your stuff in it like creating users, groups, computers, resetting password, unlocking accounts, etc.? That sure is, but things can become not that nice when delegated admins are misusing their delegated powers. In all Windows systems the creator of an object (in AD or on the file system) automatically becomes the owner of the object. Whether or not explicitly configured in the permissions, the owner of an object can do ANYTHING with owned objects like for example changing permissions. By changing permissions the owner can gain more permissions than assigned by the admin or can even assign permissions to others. Of course that is something that is not desired. An example?
Let’s say you delegated someone to create user accounts in AD. Just create and no deletion. Because that someone created the object, that person automatically became the owner of the created object and can do ANYTHING with. At this point if the creator of the object tries to delete the object he gets an Access Denied. However if the delegated admin (the owner object) goes into the permissions tab he can change the permissions and give himself, and others, additional permissions. Let’s say the delegated admin gives himself Full Control, he would now be able to delete the created object.
Does this suck or what? Of course it does! Remember this applies both to AD objects and File System Objects.
Can you do anything about it? Natively not really. Third party? Yes, using some proxy tool.
In W2K8 a new security principal has been created called "OWNER RIGHTS". See the screenshot below…
As you can see the "Owner Rights" security principal has been assigned ALLOW:READ for "This object and all descendant objects" on the Users OU. Permissions that are assigned to that security principal are inherited by the owners of their created objects. In addition to normal delegated permissions it would be enough to configure "OWNER RIGHTS" with ALLOW:READ. That would prevent the owner from changing anything on the owned object, including the permissions. No specific Domain/Forest Functional Level is required, just W2K8 RWDCs.
When the new security principal is configured in an ACE and you still have W2K3 RWDCs, it will show like "Account Unknown". While W2K8 RWDCs will enforce the feature, the W2K3 RWDCs will ignore it and the delegated admin would still be able to change permissions. So the recommendation is to only have W2K8 RWDCs and to prevent the introduction of W2K3 RWDCs increase the DFL to at least Windows Server 2008!
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########