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.

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

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

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

Solution 4

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.

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

View more solutions

Comments

[Admin]

Very interesting question. +1 for the good description. Well worth reading.

[ezakto]

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.

[ezakto]

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.

[ezakto]

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

[ezakto]

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.

[Kevin Kuphal]

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.

[ezakto]

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.

[ezakto]

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.

[ezakto]

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?

[spoulson]

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.

[ezakto]

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

[curropar]

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

[ezakto]

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

[curropar]

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

[raja]

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