On my Windows server I have a share called 'Data', inside data are 3 child folders called 1, 2 and 3.
The NTFS permissions are as follows
Data (The AllStaff group has Modify here, Admins have full control)
-folder1 (inherits parent permissions)
-folder2 (The AllStaff permissions have been removed and 2 non-admin users are added with Modify permission)
-folder3 (inherits parent permissions)
My problem is that everyone can still read and write into folder2, eventhough looking at the NTFS permissions the folder is not inheriting perms from the parent and onlt 2 users should have access (plus admins), yet everyone can access it!
I decided to start over and leave the AllStaff group with Modify permissions on folder2 but check the 'Deny' box for each type of permission, I gave the 2 users Modify, now the 2 users that should have access can't get in, they are members of the AllStaff group so I can see why this would be.
Can someone explain why I can't achive my goal? Basically 2 users need a private folder within the Data share.
Many many thanks
Scott
Best Answer
NTFS doesn't support blocking only certain inherited permission (which happens to be the only feature I'd like to see from the old Netware filesystem-- inherited rights filters). As such, you should design your permission hierarchies with an approach that grants the least permissions at the high levels, and adds permission at lower levels.
You're designing a permission hierarchy upside-down, basically.
I'd set the permission on the "data" share to something like:
Then, I'd create sub-folders for each specific necessary use and grant permission to those folders to the groups who will need access.
This has the nice side-effect of keeping users from populating the root folder of the "data" share with their own files and directories. If you don't have a the "heap of files" problem yet and you do allow users to populate that root directory you will quickly be into such a mess. (We have Customers who have spent a lot of money, relatively speaking, cleaning up messy "public drives" because they didn't start with a good subfolder / permission strategy and allowed huge amounts of files to pile up for years. It's like quicksand-- you get stuck in it and, once users have spreadsheets with "links" into the "swamp", shortcuts to files in the "swamp", etc, you can't get out easily.)
Additionally, you shouldn't EVER name individual users in permissions except in cases of wholly user-specific directories (such as roaming profile folders, home directories, etc). All other permissions, even if they're for "just a couple people" should be based on groups. Turnover happens, and in the future when you need to give a replacement employee the "same rights" as the person they're replacing you'll be glad that you used groups. Instead of having to keep documentation about all the filesystem permissions you might've set (or, worse, having to grovel through it by hand) you can just put the new user into the same groups as the person being replaced and be assured that you've given the new wuser the the "same rights" as the replaced user.
The "Deny" permission in NTFS should set off alarm bells in your head. It's rarely used in well-designed permission hierarchies. Generally if you catch yourself needin to use "Deny" then you probably have designed things backwards.
Blocking permission inheritance should be avoided because it limits future permission flexibility. If you're going to do it, you should have a good reason.
Every time you break the inheritance hierarchy you limit your ability to add a permissions higher up in the hierarchy that, obviously, inherit down.
Suppose "the boss" comes to you and says: "I want the 'Executives' to have read access to the entire 'data' share". If you've blocked inheritance in 20 different places each one will need an ACL entry added. Compare that to adding a single ACL entry at the top of the hierarchy (assuming you never blocked inheritance anywhere in the hierarchy).