Managing Security Groups for NTFS Permissions

To start off with, I work for a company that a long time ago when they implemented file shares for each division, they also broke the cardinal rule of NTFS permissions and used explicit permissions for users on certain folders. To give an example of our set up, every user has a W: drive. The W: drive hierarchy is similar to the following:

W:\HR

W:\Legal

W:\Finance

W:\Communications

I'm pretty sure at one point, these folders were fairly organized. But then came the complex situation where someone in Legal needed access to HR documents, someone in Finance needed access to Legal documents, then there's the odd cases where 2 different people from different subdivisions of legal need access to a specific folder in the legal folder, but they don't want anyone else to have access to this folder. To which the IT department at that time felt the best solution would be to just give explicit permissions to those people.

Since I've started at this job 7 years ago, I've been hinting at creating security groups for these instances (even if it's only for one user account) because when users leave, we remove them from all groups, and put them in a Former Employees OU for 5 years, but their explicit permissions remain on the folders in the file share.

When I make hints of creating security groups for these instances, the counter argument is, "How will we manage all the empty groups when people leave? How would we organize and name these groups in AD?"

For the first argument, I propose a simple powershell script to delete empty groups or just to leave them in place for any future employees requesting the same access to specific folders.

The second argument though is where I am having trouble coming up with a good solution. So after that brief novel, I'd simply like to ask for any tips or examples on organizing security groups in AD for NTFS permissions when faced with the situations I listed above.

One thought I had was to create an OU just for special NTFS permissions groups, name the groups after the folders they give access to , and put the full filepath in the description.

If anyone has any better ideas or if anyone does this differently, I'm open to suggestions.

Solution 1:

Your thoughts are essentially what I do, and I've had a lot of success in managing things that way in complicated environments.

The solution to both of the question is that you create resource groups that are tied to the folders/shares. You don't delete the empty groups at all, the groups exist for as long as the folder or share exists, not for as long as there are users in them. If you deleted the folder, then you would delete the associated resource group, regardless of whether it's empty or not.

The question about how to organize security principles in AD is a bit of a mystery to me - that's what AD is for! You can organize it any way you want!

Here's how I do it:

• Create an OU in an appropriate place and call it something helpful like "Resource Groups".
• Optional: Create an OU inside "Resource Groups" and name it something like "Folder Groups". This step is mainly about leaving yourself a place to put other resource groups, like printer groups or application groups.
• Start going through all the folders/shares that have non-inherited permissions on them. When you find something with non-inherited permissions, create a Domain Local security group named for it. For example, for \\FileServer01\Accounting, you would create a group called "Accounting Folder". Note that you should not name the group "Accounting" because the group is for the folder, not for the department. I like to keep things extra clear and have no groups named "Accounting". I like to have the "Accounting Users" global security group and the "Accounting Folder" domain local security group.
• In the description of the new folder group, put in the full UNC path or some other way to specify what folder it is for. This way there is no confusion about what resource the group allows access to. For example, you might make the description "\\FileServer01\Accounting" or you might make it "D:\Shares\Accounting on FileServer01".
• Add the new group to the ACLs on the folder, and add every user or user group ACE on the folder to the group. Let me clarify that: First, give the Accounting Folder group the appropriate permissions to the Accounting folder. Then go through the other permissions on the accounting folder and add all those objects to the Accounting Folder group, but don't add objects like "SYSTEM" or "CREATOR OWNER". Just add the ones that you know, like the "Accounting Department" group and the individual accounts that have been granted explicit access to the accounting folder. DO NOT REMOVE ANY PERMISSIONS TO THE FOLDER AT THIS TIME. Users won't get their new access based on the group you've created until the next time they get a security token, which is usually the next time they log on. If you take away explicit ACEs, you will almost certainly lock people out of the folder and they will have to log off and back on to get the new permissions structure working.
• Keep going through all the folders until you're done creating the new groups and setting up the new permissions structure. After you're sure users have logged off and back on at least once (maybe a few weeks), you can start with the least critical folders to remove the explicit ACEs on the folders themselves and make sure users still have access. Work your way back through the folders and make sure you check with the most critical users (HR, Finance, C-level) that they still have access to the appropriate files.
• NOTE: You may have already wondered about ACEs that have different levels of access granted E.g., Accounting has read/write on the accounting folder, but the CEO has read-only. In those situations, you have to create multiple resource groups for each folder, and I would suggest that you figure out how to create no more than three groups per folder and that you name them consistently and you make the same two or three for every folder. So you might name them "Accounting Folder RW", "Accounting Folder RO", and "Accounting Folder FC" (for full control). Hopefully you don't have that last category, but I've had some success with delegating permission management to department heads, and that means they need to have the ability to grant permissions to subfolders and files, so that's what I call the "Full Control" group. Again, if you create "RW" and "RO" groups for one folder, then I suggest creating them for all the other folders also, even if you don't currently have ACEs with those different levels of access granted on the folders. This will help keep the folder group system clear, and make it easy to grant the different types of access in the future.

Notes:

• The above suggestions follow Microsoft best practices. Users are put into user groups. Resource groups are created and granted access to resources. Then, user groups and/or users are added to the appropriate resource groups. There are many, many reasons why this is a wise way to manage permissions, some of which I will discuss below.
• Do not add users to a user group just to give them access to a resource. For example, if you have an Accounting Users group with everyone in accounting, do not add the CEO to the Accounting Users group just to give them access to the accounting files. You never know what kind of unintended consequences may arise in the future.
• One advantage of doing it this way is that granting access to resources via group membership is faster and less prone to certain issues. For example, if you have an Accounting folder with 5,000+ subfolders and files, all inheriting permissions from the top level Accounting folder ACL, then if you add a single user to that Accounting folder ACL, that change has to propagate to all the 5,000 files and all of their ACLs have to have the new ACE added. By using a resource group, you just add the user to the group in question and they have access. Zero ACL changes made.
• Another huge advantage is that you can easily find out all the resources a specific user has access to. With explicit ACEs, the only way to see what a user can access is to audit every single ACL on the network to see if that user has an ACE in it. With resource groups, you just go to the user in AD and see what groups they are a member of.
• Probably my favorite advantage of this method is you can completely copy a user's access to all resources, because the access is tied to their account's group memberships, not to various ACLs on the network. Did your CFO have all kinds of crazy access granted to 20+ different folders all over the file server, and now they have retired and you have a new CFO? No problem! Just copy the old CFO's account, put in the new name, etc., and the new CFO now has the exact same access as the old one! Bonus: you don't have to do silly things like keep the old CFO's account working so executive team members can "log in as them to access files".
• It's also much easier to copy resource access to another resource or move the folder. If you build a new file server and copy all the files to the new server, you don't have to copy a ton of ACEs to the new server. Just grant the resource groups the appropriate permissions.
• In addition to being able to audit what access an individual user has, you can easily audit who has access to a given resource. Just look at the resource groups for the resource and you will get a list of who has what type of access to that resource.
• One last thing: I don't see why you would remove departed users from all groups. I would remove them from e-mail distribution groups, but not from security groups. Leaving them in security groups gives you a record of what access they had, and it also makes it possible to copy that account and its access after they have left. Sometimes people leave before their replacement is found, so keeping that disabled account around until the replacement starts helps enable greater continuity of operations. Also, sometimes people leave and then come back in a few months. If you use the AD recycle bin, then you could delete the account after 30 or 60 days and then still restore it a year later if the user comes back, and they could have all their permissions restored at the same time.