Q:

Is this a recommended/valid approach for file server permissions?

File servers are a fact of life in IT and I'm curious if there are any generally accepted practices (I hesitate to use the word "best" here) for how you create groups and apply permissions for managing client access to a shared folder on a file server.
At my current job, I ended up inheriting quite a mess of different ways of doing this ranging from dozens of groups on the ACLs to just putting individual users directly on the filesystem. My task was to clean up the mess and come up with some kind of standardized way of approaching this throughout the company (large environment, 150k personnel, 90k client computers, 100's of file servers).
From my understanding of the issue, it seems that you at a minimum need one group per required access level per secured resource. This model seems to give the most flexibility in that you do not need to touch the filesystem permissions again unless you need to support a different access level. The downside is that you will create more groups than with re-using the same group across multiple shared resources.
Here is an example showing what I mean:
There is a share called "Test Results" out on a file server named FILE01 and you have folks who need read-only access, read-write access, and full control. 1 secured resource * 3 access levels = 3 security groups. In our AD environment, we create these as universal groups so we can easily add users/groups from any of the domains in the forest. Since each group uniquely refers to a shared folder and access level, the group names incorporates those "key" pieces of data and the permissions are thus:
"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

Typically, we would also include the built-in SYSTEM account and built-in Administrators with Full Control access as well. Any changes to who actually gets what access to this share can now be handled using group memberships rather than having to touch the ACL (either by adding "Role" groups representing specific business roles like Managers, Technicians, QA Analysts, etc. or just individual users for one-off access).
Two Questions:
1) Is this actually a recommended or valid approach for handling permissions or am I missing some simpler, more elegant solution? I'd be especially interested in any solutions that use inheritance but still retain flexibility in not having to re-ACL large parts of the filesystems when things change.
2) How are you handling file server permissions and group structure in your environment? Bonus points for those who are also working in large environments.

A:

That approach isn't bad.  As a rule never use individual users to add permissions- use a group.  Groups can however be used across resources. Eg HR might have RW access to files while MANAGERS might have R.  You can also set up Access Based Enumeration.  Take a look at the following webcast:
TechNet Webcast: Windows Server 2003 Administration Series (Part 4 of 12): Group Management (Level 200)
Access based enumeration can make life easier too see:
Access-based Enumeration
ABE can help reduce the number of different shares you have to administer.

A:

My approach is to not use file/directory level file permissions; use file share level permissions, and set the whole server filesystem data drive to Everyone Full Control (which becomes moot).
Over the years (10+), I have found that NTFS permissions are more complex and leads to more errors. If the permissions are set wrong, or the inheritance gets broken, you expose data and its hard to find and see it. Plus, you are exposed to the move/copy problem ... users moving files also move the file's ACL, whereas copy inherits the destination ACL.
Use your read/write groups the same, but on the whole file share using Comp Mgmt MMC. Don't do full ... users will shoot themselves with partial-knowledge/best-intentions.

