Tracking user access in a corporate network is one of those, “Don’t say that very loudly!” topics. No one likes to think about it because everyone knows they suck at it and trying to get it under control is a frustrating exercise. But what if you absolutely have to do this?
If you’re like most small- and medium-sized companies, you use some sort of Windows-based file server and manual permissions management with Active Directory user accounts. Nothing could be messier when not managed properly. I’ve recently had the pleasure (?) of tackling such a project in my company. If you’ve ever utilized cacls/acls tools to dump permissions lists in folder shares, you know they can fill up all the rows in a .csv file and more, even for a medium-sized file server.
Here is my approach in four major steps: 1) take inventory, 2) file permission organization, 3) account organization, and 4) data ownership. The goal of this project is to be able to answer the following questions: Who can access data X? What does person Y all have access to? What is the process for requesting access to data Z?
1. Take inventory
The first order of business is to measure the pain. Grab a trusty Windows permission enumation tool and dump the permissions on all your file server shares, including all subdirectories. I recommend limiting yourself to folders and not including files. Windows files are very annoying in their permissions and will inject a lot of weird data into your intial acl dumps. The best tool I’ve come across for reporting on permissions is ScriptLogic’s Enterprise Security Reporter. This is a commercial tool which does more reports than just permissions, but the ability to report permissions in configurable ways is invaluable. They have a 30-day trial on this product. You can create reports that pull out what a user has access to, as well as who all has access to a particular folder including pulling users from groups in AD. Check out your file servers and all the folders you expect to have different permissions and see how accurate things are or are not. Take a deep breath, and move on.
2. file permission organization
Next, you have to determine how you will be doing permissions in the future. Here are my recommendations:
– Do not use the DENY right! This rarely shows up in reporting tools and is just frustrating to use.
– Do not use complicated subdirectory permission changes. You want to use permission inheritance as much as possible. The reason for this is accidental changes to permissions that are pushed down to all subfolders and files will overwrite all subdirectory differences. Oops! Eliminate the possibility of this very real mistake by being as flat as possible. Do only one or two levels of permissions differences; I prefer just one level. Our file server for departmental and team folders is I: on the desktops. From there, we do I:\Accounting, I:\Sales, and so on. Each of those folders has its own permission structure, and that’s it. No odd I:\Accounting\SuperSecret\ folders with different permissions. If they need that, it can become I:\SuperSecret\ and be on the same level. Anyone who has worked with complicated permissions structures will no doubt be able to tell amazing horror stories.
– Use only those permissions that you need to use. For almost everyone, this can be narrowed down to Modify and Read-Only. Don’t get fancy with Change or List or others.
– Use as few explicit permissions on folders as possible.
– Do not use EVERYONE or AUTHENTICATED USERS. User Domain Users if you absolutely must have a share open to “everyone.”
By following these guidelines, you accomplish a few things:
– Reduce the chance of permission inheritance mistakes.
– Improve the ability to pull accurate permissions reports.
– Decrease the amount of time and effort needed to make permissions changes and re-establish permissions (you can just push down permissions from I:\Accounting to all subdirectories and not worry about what you’re wiping out).
3) account organization
While ScriptLogic has a nice tool to pull access reports, it is still yet another program for staffers to learn and, really, you can do much the same thing with some effective use of Active Directory accounts and groups.
For every folder on your file server that needs different permissions, create two groups to hold the users who will use those permissions: Read-Only and Modify. For I:\Accounting, I would make the groups Accounting Folder-Read-Only and Accounting Folder-Modify. Then anyone who needs Modify access to Accounting should be placed into the Accounting Folder-Modify group. Apply both of these groups to the explicit permissions on the folder with their respective permissions. This should mean you will have only a few explicit permissions on each folder: SYSTEM (likely), Adminstrators (likely), the Modify group, and the Read-Only group. Nice and clean!
One caveat to this approach is in the way Windows handles group tokens. When a user logs into their computer, the logon process will inform that computer which groups the user is a member of. If the user’s group memberships change, their current session will not get the updated group membership information until the user logs out and logs back in (I typically just tell people to reboot, as they understand that better).
So all permissions changes will now require you to put that user or groups of users into the proper permission group, and then have them reboot. In a way, this is much easier than logging into the file server and updating permissions directly on the folders.
The biggest benefit, however, is in the ability to report on access. If you want to see what John Smith has access to, you just have to see which groups he is a member of. You’ll see Accounting Folder-Modify, and it is quite obvious what he has access to. Likewise, if you check the members of the Accounting Folder-Modify group, you will see who all has access to that folder. Quick and simple!
One last note about AD organization, it really helps to have a very updated and group-based AD organization. Every employee in the company should be set to report to someone else in the Ogranization tab, and they should belong to some sort of role-based group. Accounting employees should be in the Accounting group, and so. This way you can use groups instead of individual users when placing people into their Modify and Read-Only groups. This is tough, however, if HR is not very clear about the roles people play, or if the department and team names change frequently and without warning.
4) data ownership
Lastly, if a company is going to take permissions and access seriously, then ongoing support needs to be able to question requests made for those access levels. John Smith shouldn’t just be able to request access to the Sales folder to the Help Desk himself. Someone has to authorize this access. Unfortunately, while most would think his manager is an appropriate authority, in reality, his manager typically has no idea what sort of information is in the store and will likely not do anything that prevents his employee from being productive.
A solution to this is similar to the Discretionary Access Control (DAC) method where data owners are assigned to data stores. The Accounting folder would be assigned an owner. This owner is then responsible for authorizing who has access to that folder. As part of that responsibility, that data owner should also know what sort of data they are a custodian of. If there are sensitive documents in the data store that some departments should not be privvy to, the data owner should know this.
Accounting or Human Resource file shares are perfect examples of this sensitivity. The Help Desk should not be blindly granting this access just because a user requested it.
Some other tasks:
– regularly report permissions, both in AD groups and in explicit permissions. This will definitely show you how Windows “copy” screws with permissions. Likely, you’ll want to regularly “re-push” inheritance down through each folder so that you can refresh the cleanliness of your permissions reports.
– reports should be given to data owners for their review
– make sure all permissions change requests are clear, explicit, and tracked, such as in a help desk ticket system. Don’t assume Bob J. means Bob Jones. The requestor should be as explicit as possible so that Bob Johnson doesn’t accidentally get access to HR.
There are plenty of other caveats and approaches to doing user access security in a Windows environment, and quite a lot more work than is described here, but this should at least give some good ideas on an approach that I think works pretty darn well.