Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's English Pages


Engineering and troubleshooting by Directory Master!
MCM: Directory

Quick Launch

Ondrej Sevecek's English Pages > Posts > What does the OWNER RIGHTS security identifier means
August 01
What does the OWNER RIGHTS security identifier means

Everyone with a bit of NTFS security permissions awareness knows about the CREATOR OWNER security identifier (SID S-1-3-0). It is present in default security descriptor of every root drive (volume) permissions in the world. Everybody knows that it defines generally what the current owner of the objects can do. It allows for defining permissions without specifying the identity explicitly. The identity evaluates dynamically at the time of access. If the owner of the object changes, the permission ACE (access control entry) simply applies the the new owner instead. Simple and boring :-)

Yet nearly nobody knows about another principal SID called OWNER RIGHTS (S-1-3-4). It seems similar but in fact it is completelly different story. It actually defines or even limits what the owner of the object can do or even cannot!

Object owner background first

What? We have to first understand what the owner of an object means.

It goes this simply - if an identity is specified as the owner of an object this principal can always change permissions on the object, implicitly, regardless of its permissions. In practice it means that if you are the owner, you cannot deny access to yourself. Although you can create explicitly denying permission entries (ACEs) to even yourself, you will always be able to later remove them as long as you are owner of the object. Even if the ACL list does not contain any permission entry, the owner is still able to change permissions. The behavior of the owner principal is this implicit.

This is also the reason why the built-in Administrators group is granted Take ownerhip of files and other object user right or privilege (the SeTakeOwnershipPrivilege) by default. Having the ability to change owner of any object using this privilege gives them in turn the ability to change any permissions and thus in turn obtain access to any object.

On the other hand, ownership also complicates things for administrators. For example NTFS admins who manage shared files. On one hand, you try to limit users to Modify permission only in order to prevent them from modifying the NTFS permissions on the shared folders and files. On the other hand, even if you grant them Modify only, they will be able to get Full Control on all items that they create themselves. If they create anything, they are owners of it and thus they can change permissions and in turn they can grant themselves the Full Control ultimately.

This problem can be seamingly remediated by sharing permissions where you grant Change instead of Full Control only. This way the guys will not be able to change permissions over the network share and you keep your hierarchy safe. But. This would apply to the whole shared folder structure without exceptions possible. It would also not apply for local access, such as from remote desktop session (RDP).

The OWNER RIGHTS finally

It is where OWNER RIGHTS SID steps into the game. If you specify this principal for an ACE, the access specified for the permission entry now defines the access allowed to the owner principal explicitly. So the system forgets about the implicit change permissions completelly and allows the owner explicitly only the access that the ACE defines. So if the permission entry grants othe OWNER RIGTS principal the Read & Execute then the owner can only Read & Execute and cannot change permissions.

You can also grant no access by creating a permission entry for the OWNER RIGTS principal but leaving all the access checkboxes unchecked. This would just rid the owners of any implicit ability to change permissions while it would not give then anything else in exchange.

What is the difference against the CREATOR OWNER? The CREATOR OWNER works just like any other additional permission entry. It can only add some access permissions to those that are granted to the object owner implicitly. So the CREATOR OWNER cannot rid the owners of the ability to change permissions. Not even if the CREATOR OWNER ACE was actually Deny ACE.

With OWNER RIGHTS principal you can prevent even the authors of files and folders or any other object (and thus owners) from being able to change permissions.


There are no comments for this post.

Add Comment

Sorry comments are disable due to the constant load of spam *

This simple antispam field seems to work well. Just put here the number.


You do not need to provide any value this column. It will automatically fill with the name of the article itself.

Author *

Body *