David Archer's questions

As anyone that has dealt with file server permissions is aware, NTFS has an interesting design feature/flaw known as the Move/Copy problem.

As explained in this MS KB article, the permissions for a folder or file do not automatically inherit from the parent if the folder is moved and the source and destination are on the same NTFS volume. The permissions are inherited if the folder is copied or if the source and destination are on different volumes.

Here is a quick example:

You have two shared folders on the same NTFS volume called "Technicians" and "Managers". The Technicians group has RW access to the Technicians folder and the Managers group has RW access to the "Managers" folder. If someone has access to both and they move a subfolder from the "Managers" folder to the "Technicians" folder, the folder that is moved is still only accessible to users in the "Managers" group. The "Technicians" group cannot access the subfolder even though it is under the "Technicians" folder and should be inheriting permissions from the top.

As you can imagine, this causes support calls, tickets, and wasted cycles on resolving these end user issues, not to mention the rats nest of permissions that you can end up with if users are often moving folders between different secured folders/area on the same volume.

The questions are:

What is the best way to workaround this NTFS design flaw and how are you handling it in your environment?

I know the linked KB article talks about some registry keys to change the default behavior of Windows Explorer but they are client-side and requires the users to have the ability to change permissions which I would think in most environments is a non-starter if you want to keep control over your file server permissions (and your sanity as a sysadmin).

In my environment, I have several projects that involve running NTFS ACL audit reports and various ACL cleanup activities on a number of file servers. There are two main reasons why I cannot perform these activities locally on the servers:

1) I do not have local access to the servers as they are actually owned and administered by another company.

2) They are SNAP NAS servers which run a modified Linux OS (called GuardianOS) so even if I could get local access, I'm not sure of the availability of tools to perform the operations I need.

With that out of the way, I ended up rolling my own ACL audit reporting tool that would recurse down the filesystem starting at a specified top-level path and would spit out an HTML report on all the groups/users it encountered on the ACLs as well as showing the changes in permissions as it descended the tree. While developing this tool, I found out that the network overhead was the worst part of doing these operations and by multi-threading the process, I could achieve substantially greater performance.

However, I'm still stuck for finding a good tool to perform the ACL modifications and cleanup. Your standard out of the box tools (cacls, xcacls, Explorer) seem to be single-threaded and suffer significant performance penalty when going across the network.

The Question

Are there any faster tools than Explorer or CACLS for performing NTFS ACL modifications across the network?

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.