The estimated reading time 3 minutes
Folder owner should not be able to change permissions / OWNER Rights explained for NTFS security
Some time ago we had a interesting discussion concerning ownership of folder which were created by regular users. Standard behaviour: as user who has created the folder you have FULLACCESS to it and you are able to change permissions as you like.
Aim: if an user creates a folder he or she should not have fullaccess to this folder and should not be able to change permissions.
As a short review I describe the default behaviour in NTFS.
First have a look on default permission of a share on a windows fileserver (no changes applied)
The Creator Owner permission allows user to get fullaccess to created folders. So if an user creates a new folder under this share he is given fullaccess to it and he can also modify and delete NTFS permissions. See screenshot:
After this step I created another subfolder in testfolder01 with another user (user09)
From this moment I’m able to disable inheritance under the context of user09 and delete all other permissions
As you can see no other user (expect Administrators) have permissions on this folder, now I delete also administrators. So even as Domainadmin I’m not able to access this folder via share.
one way to get access again is to browse directly from the server to folder an regain it as owner.
Sometimes you want to know who changed permission or created this folder before you overwrite this peace of information. So here is the cmdlet in powershell to display the current owner if you do not see it in explorer.
get-acl -Path "C:\Shares\share01\testordner01\testunterordner01" | select path, Owner -expand access
This is worst case and should not happen in productive environments, let’s have a look on the solution for this.
Unfortunately I did not find lots of information from Microsoft about this important topic (if someone knows a link share it in the comment section please)
the only thing I found was this link of known SIDs LINK
- SID: S-1-3-4 Name: Owner Rights
Description: A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner.
NOTE: operating systems with other languages differ so there is no OWNERRIGHTS for example in german it is “Eigentümerrechte”
If you want to prevent users interaction in permission allocation you should completely remove “Creator Owner” ,replace it with “Owner Rights” and change FULLACCESS to MODIFY on the top folder (in my case Shares)
Have a look on my screenshot
Every folder should get this change and now we can check the result.
Newly created folder inside this share with owner rights implemented
When I want to change permissions with user09 it is not possible although I’m the owner. User09 also is not allowed to disable inheritance so nothing happens the user should find this “secret” security setting.
Conclusion: OwnerRights are one step to better NTFS security so users can not change permissions on created folders.
NOTE: even the creator owner permission is changed to “modify” it is possible for the user to change permission. This group should be completely remove, otherwise owner rights is not working properly.
If there are any further questions leave me a comment or write an e-mail.
We also had some users who were making changes in permissions. This was the only site with a clear description and a clear solution to the problem.
Wow, I’ve been administering Windows server for close to 30 years and always believed I was doing this right! Over this years I’ve had all these occurrences of NTFS permissions getting dorked up and blaming junior IT staff for it when now I realize it may not have been them?
Just had this occurrence this week and the user said HE made the change. I realized he was for folder owner and I thought, well that’s a flaw!
Great article, you’ve taught an old dog a very valuable new trick!
Thank very much. It’s been a pleasure to tell someone that experienced another side of the medal. Have a great day.
How come nobody has commented on this brilliant, useful, wonderful piece of configuration? This is exactly what is needed to satisfy NIST800-53 AC-3(4)
Thank you very much Pablo. Hope you find another solution on my blog.