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.

  • Very interesting question. +1 for the good description. Well worth reading.
    – John K. N.
    Nov 23 '12 at 12:58

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.

  • I also use this approach and I think it works well for Small to Medium sized businesses where the access requirements are not as detailed. Jun 17 '09 at 13:36
  • +1 This is a novel and interesting approach. If I'm understanding you correctly, you would set the ACLs on the share instead of on the NTFS and just make every "resource" its own share. It would side-step the move/copy problem as well as make changing permissions quick and painless since you wouldn't have to touch all the files/folders if you needed to make a change. Combined with some creative use of DFS for nested resources, this approach has some clear advantages. Jun 24 '09 at 0:09

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.

  • Jim, the main "trap" I am concerned with is that by re-using the same group across multiple resources, there is no way to answer "What resources does group X have access to?" without examining every resource in the environment (sorry if I'm being a little abstract here). Also, you end up needing to re-ACL the filesystem if another group needs access to the files as well. Jun 11 '09 at 3:54
  • @David, actually that's not entirely true: as you're naming the resource groups with a descriptive name, you can go to role groups (say Managers) and check to which groups the belong to (say FileServer01_HR_RO and FileServer01_Mgmt_RW). Of course, this model requires to be strict with both naming and following the group membership standard. But not being strict in this or any other model would end in a mess anyway.
    – curropar
    Jun 21 '16 at 11:57
  • @curropar: It's been 7 years but I /think/ what I was talking about was if you actually put the Role groups directly on the resource ACLs it would be problematic. We actually ended up not using role groups at all in the project I was working on that prompted the original question because it was all automated. Users would request access to resource groups directly using an online web form and the resource owners (business folks) were responsible for approving/denying those requests. Jun 22 '16 at 12:44
  • That makes sense; and even if this is 7 years old, I was looking up for models for my file server, and this post was up in a Google search, so I commented for future visitors, just in case ;)
    – curropar
    Jun 22 '16 at 13:00
  • 1
    @curropar Looks like I never answer the questions years ago. As far as auditing goes, you have to audit every resource anyway since the other way around is not a valid audit.
    – Jim B
    Jun 22 '16 at 14:12

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.

  • Agree with #1. The role part of the system is optional though but does make management easier. On the Universal groups, I had some concerns about the replication traffic but given that our group memberships change fairly slowly (maybe 1000 groups being modified a day?), it hasn't become an issue yet. Domain Local looks like it would work since they can contain users for any domain in the forest. Jun 11 '09 at 3:59
  • Just to follow up on this: We ended up converting the groups over to Domain Local and that worked well for about 6 months. THEN when we had a requirement to set up a disaster recovery environment and had the file servers from one domain set up as replicas for file servers from another domain, we ended up having to convert back to Universal groups because otherwise, the DR servers couldn't interpret those permissions (since the DR servers were not in the same domain as the source file servers and the domain local groups). Jan 2 '13 at 15:06

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.

  • Not sure I understand the Domain Local groups requiring more total groups vs Universal groups as I would still need 1 per secured resource per access level. I agree with not taking the hit on replication so I may look at changing those at some point in the future (should be a fairly simple operation). Jun 11 '09 at 4:02

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).

  • Yup, we're putting the UNC in the description because of AD group name length limitations. In my production environment, the group name reflects the full UNC path to the folder with backslashes converted to dashes. If the name is too big to fit, we chop the end off (before the -RW or -RO suffix) and put a 3 digit incremental number starting at 001. Not the simplest approach but it's consistent and easy enough to query for AD. Jun 11 '09 at 4:07

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:


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)


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.


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...


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.

  • I have used ABE before in a previous engagement but the main complaint was that hiding the existance of the resource (folder) from the users that couldn't access it ended up making it harder for them to actually request the access if it was something they had a legitimate need to get into. In my current environment, we have these Linux-based NAS servers so ABE isn't an option here. Jun 24 '09 at 0:15

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.

  • Agree about the best-case scenario would be having enough knowledge and engagement with the business to be able to map out job roles for each "kind" of user but in my environment (global company, 150k+ users) it just isn't realistic to expect the business folks to spend the time required to map that out. We basically went the other route with only one-off access but we automated the entire process so it isn't a burden on IT. Jun 24 '09 at 0:18
  • As for moves and "cleaning up" old access, again, we automated the process and the responsibility is laid upon the resource owner to periodically review and request removal of access for folks who no longer should have access. "Moves" in our environment don't typically involve the removal of access to resources since who better than the resource owner to know whether this person still needs the access or not in their new position? Jun 24 '09 at 0:24
  • Trying to map out 150k users and their roles is an indication that the company didn't do their research before growing to that size. Obviously, it's far easier to have the framework in place before expansive growth.
    – spoulson
    Jun 24 '09 at 12:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.