5

I have a very strange NTFS rights phenomenon on a fileserver and I cannot find my mistake, pulling my hair out for hours now. What am I missing?

My goal is:

  • User from Group-A should be able to write new files/foldes into a folder ("add files"). They should also be able to edit those newly added files.
  • At night the newly added files should be "protected" from further editing/deleting by Group-A. The right to read the files and the right to add more new files should remain.

Here is what I did:

  • Create Group-A, add users
  • Give Group-A (F)ull access to the folder
  • Create a script that
    • deletes the inheritance bit of the files in the folder
    • removes (F)ull access to the files, leavinf read-only rights

The problem is, my user(s) can edit and delete files like they have full access. Even if the 'effective permissions' show no right to edit, the still can.

The script works fine and looks like this:

icacls d:\folder\Bild1.jpg /inheritance:d
icacls d:\folder\Bild1.jpg /remove:g Group-A"

After the script has run, The NTFS permission on file.jpg looks like this (looks correct to me): NTFS Rights on File

So does the icacls output:

d:\folder>icacls Bild1.jpg
Bild1.jpg WM\DomainAdmin:(F)
          WM\Domänen-Admins:(F)
          WM\Group-A:(RX)

The effective permissions tab of that file shows exactly the same (right) thing:

Effective NTFS permissions

The permissions for the parent folder, users should be able to add files here, look like this:

Artweger WM\Group-A:(I)(OI)(CI)(F)
         WM\Domänen-Admins:(I)(OI)(CI)(F)

If this User logs on (he is just in two groups, Domain-Users and Group-A), he can edit, delete, rename and move the file bild1.jpg. How is this possible? What does NTFS do with my glorious plans?

bjoster
  • 4,423
  • 5
  • 22
  • 32
  • 3
    Who's the owner of the files? – TJJ Apr 28 '16 at 08:27
  • Could you provide a Screenshot of the first tab in the advanced permissions settings (Tab "Berechtigungen" in your second screenshot)? – Tobias Apr 28 '16 at 09:16
  • **Owner:** Depends. Mostly the creating user, for large portions the domain admin. makes no difference so far. – bjoster Apr 28 '16 at 10:26
  • **Screenshot:** http://i.imgur.com/MUiriiY.jpg (Sorry, i missed that in the first place). The Top Picture is from the Folder, the second one ist the File. – bjoster Apr 28 '16 at 10:27
  • **Monitoring**: I have enabled Monitoring für this file/folder an the event 4656 (for the accesstype DELETE) was granted. Additionally it says, the right was granted by the ACE of the containing Folder (A;OICIID;FA;;;USERNAME). But the inheritance is off? – bjoster Apr 28 '16 at 10:32
  • 2
    The trouble I see with your approach is that: If a user creates a file, he is the owner of said file. And the owner always has the permission to change the ACL of his files., thus being able to eventually delete any file that he owns. So what you need to do is to remove the user from the ownership immediately after file creation. – Daniel May 02 '16 at 10:32

1 Answers1

4

I have experienced a similar problems two months ago, this thread may be helpful to you.

I would first check if this happens for all files or only files that are owned by the user (change the owner to see if it still persists), as suggested by Daniel.

I would then try to set the permissions as described in the other thread, but using the detailed preference pane in Windows (Button Advanced in the lower right corner) and the Sharing tab (I don't know for certain if this is how it's done in Windows Server, in Solaris it is done this way). The basic idea is (quote from the second linked thread):

The owner is always allowed to change ACLs on her objects. You can prevent this for shared content by using a share which is only allowing "Everyone:Modify" permissions as this will "filter out" any change ACL requests at the share level. If you want to allow your Administrators to change ACLs, just add "Storage Admins:Full Control" to the share permissions.

Community
  • 1
user121391
  • 2,452
  • 12
  • 31
  • The interesting bit: The User *cannot* change permissions on files ("Access denied"), but he can delete the file. – bjoster May 09 '16 at 08:38