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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

Your approach is basically the way i would approach it.
The only things i would add are these:

1) I would add to your "roles" scheme by evaluating what they need across servers not on just one server you are probably going to run into outliers to this, but my theory with those is when you run into them, create another group. in my experience where there is one outlier there are many.

2) I would STRONGLY re-evalute the need for Universal groups for everything as you take a replication hit with them as the members and groups inside of the Universal group is replicated to the Global Catalog servers while with Domain Local and Global only the group is replicated to the global catalog servers. So if you make a change in a universal group it kicks off a replication, while with global and domain local it does not.

Answer 4

Your method of using resource group for each access level is correct. The only thing I would consider is using Domain Local Groups for resources. You don't necessarily need to use Universal Groups if you're creating server-specific resource groups.

The downside of using Domain Local Groups for resources is that you end up with more total groups. The upside is that you have less of a problem with replication, as Zypher noted.

Answer 5

The proposed approach seems fairly solid. One thing to look out for though is the way you initially set up the file shares. Recommended practice is to have a single top-level share, containing subfolders which you then assign the group permissions to. NTFS can then bypass the "Traverse Folder/Execute File" on the top level folder and grant access to the subfolder.

The structure would then look like \servername\sharename\group-folder, with share permissions only needing to be set on the "sharename" folder, and the actual NTFS permissions set on the "group-folder" folder.

Your file server will be able to perform better with this kind of setup too.

General other things I would do is have a naming convention for the groups such that the group name is the same as the group folder name (with FC/RW/RO appended if desired), and stick the UNC to the folder into the group description (so that your logon script can read it back and set a drive mapping that way, and also so that you can more easily see what shared folders apply to which groups).

Answer 6

The standard practice I've been using for Windows file server since Windows 2000 (laid out in Mark Minasi's Mastering Windows Server series, so look there for more info) is to use groups that are local to the file server itself for nesting.

For example, consider a file server named KERMIT in a domain called MUPPETS.

Say KERMIT has a few file shares:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Create groups local to KERMIT for access and give them permissions on the file system exactly as you've specified (i.e. one group per access level per share)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Because these are local groups, you can put whatever other groups or users you want in them - domain local groups, global groups, universal groups, user accounts from any domain in your forest. Rights management is now local to the file server's groups rather than the file system or the AD.

This does add an additional layer to your groups management, but it has the benefit of allowing (say) site-local admins to manage their own file servers without needing anything more than Admin rights to that file server. If you have a federated sort of branch office structure, where every office kind of does its own thing with its servers, this can be a real benefit. You may not want to have to give AD admin rights to a few dozen local site admins.

It also keeps your AD from being cluttered with a lot of groups (one group per access level per share per server can add up very quickly), and minimizes group replication between GCs. It allows you to reserve your AD groups for roles instead of permissions.

If your environment is rigorously standardized and all file servers are identical and replicated, then this is obviously one more layer of groups you don't need. Also, if you know you need a particular AD group to have the same rights on a share that exists on every single file server, you're going to need some automation to maintain that.

In a nutshell, the more different your file servers are from each other, the more using machine local groups makes sense. The more they are similar, the more you want to use the system you are currently using.

Answer 7

I'm looking at a migration from NetWare to Windows Server 2008 so this has been on my mind a lot lately. Server 2008 (and to some extent Server 2003R2) have some very nice features that really ease this transition. Server 2008 comes with Access Based Enumeration out of the box. This is a very nice feature that allows users to only see directories they have rights into. If you have a share like...

\\user-home-srv\homes\

Without ABE the end user would see tens/hundreds/thousands of directories. With ABE the end user would see only one. The same holds true of shared shares. With ABE you can have a single huge volume for all of your departmental directories if you wish, and not spam the heck out of your users with directories they can't get into. While not an ACL issue, it is somewhat related so I bring it up.

Another thing that Server 2008 seems to do better than its earlier versions is ACL inheritance. It just seems faster at propagating down to the leaf an ACL change at the top of a large tree.

Due to our Netware legacy, we have a large number of groups that are named based on who is in them, with a few out there named for what they give access to. For directories that have regimented access, we also use the "RO" "Full" nomenclature.

We have a monolithic "shared" volume (still on NetWare, but we plan to have it monolithic when we move to Windows) that is the single shared volume for all 4,400 workers, and has over 3.5 million files on it. The top-level directories are all department names, and each department regulates what goes on inside them. There are a few exceptions for the really large departments, those have a 2nd level of directories with ACLs.

At my last job we were even able to set up permissions so HR employees applying for jobs wouldn't be able to see their own application data on their server. It took some inheritance-rights-filters to do it, which is similar to the "block inheritance" tag on Windows. The tricky part there was documenting it all, but it worked.

Answer 8

A best case scenario is to have every user added to just one security group for the user's job role. The role then is delegated access where needed.

Equally, a shared folder should be granted access using "resource" security groups, like your "FILE01-Test Results-RW" example. This will contain the job roles, department roles, or other applicable groups.

The upside of this design is that you delegate access on a per-group basis (team, department, etc.), and not one-off access that can be difficult to track. When a user transfers to another department, you need to clean up all the old access.

The downside is that groups can be misused. Make clear distinctions as to what the groups are used for, so that resource groups assigned to a share aren't reused as if they were departmental groups, creating a tangled mess of access.