Windows – How to document/track your permissions

active-directoryauditwindows

I'm a Windows Admin so those that integrate with Windows will likely be most helpful. My main challenge at this point is just with file shares but as SharePoint use increases it will only make this harder.

I've got all my directories setup and many security groups that are setup with the policy of least access needed is allowed. My problem is tracking it all for HR and compliance reasons.

User A needs permission to resource 1. He needs to get approval from the manager of resource 1 and then the manager of the managers needs to approve this access as well. Once all of that is done I can make the change. At this point we're just tracking it on paper but it's such a burden and likely to fall out of compliance when user A is re-assigned and no longer should have access to resource 1 among other scenarios.

I know what I'm looking for should already exist but I haven't known where to look and I'm reaching out to the community.

EDIT:

Thanks for the responses. I think they touch on the technical side and hopefully my question isn't off-topic. I should have made myself clearer on my goal. What systems do you use to show an auditor that on X date user A had permission added/removed and it was approved by manager Y? I have a basic ticketing system in place currently but I don't see it delivering what I need in an easy to understand format.
In my mind I'm picturing something that would have a report on user A that would show all the changes that had been made to their permissions. Ideally something linking to Active Directory would be ideal but at this point I'm hoping to find something more basic. I'm hoping that there is an application specifically for this. I feel like this must be a requirement for larger enterprises and such software exists.

Thanks!

Best Answer

You need a ticketing system that provides 3 things:

  1. Timestamp of when permissions were changed (added or removed) for a particular user
  2. Why they were changed
  3. Ability to search for these changes

Pretty much all ticketing systems already provide you with #1 in the form of a ticket creation date, modified date, etc. #2 is up to you to document in the ticket. Usually it is an approval e-mail from the resource manager pasted into the ticket saying they can have access (or access should be removed) and what kind. #3 is the most important and depends on the ticketing system, but if you have a system that is not easy to search then your work is cut out for you. If you can just search by the user so that all permission tickets are tied to their contact info in the ticketing system then you are good, otherwise you are essentially documenting your changes into a black hole.

Outside of a ticketing system that can do this to track changes (you mention that you have a basic ticketing system so maybe you need to get a better one that allows for better searching/reporting capability), any application, utility, or script you use will provide a snapshot of permissions only. You are still stuck with the "why?" of who has access to what, which can only be properly documented separately from the application since you'll likely need to capture the original e-mail or other approval text from the resource manager. Once you have that, where do you put it to associate it with the application's results?

Running an app or script to determine current permissions in a file structure also does not provide you with a nice audit trail of permission changes for a user either. You are essentially stuck with a big snapshot of current permissions at a single point in time. When you run it again, you will have another big snapshot of file permissions. Even if you retained the first permissions capture and compared it to the recent capture, and permissions have changed, how do you tie that to the reason for the change? Again, this brings us back to the ticketing system since #s 1,2,and 3 above will all be documented in one place.

Another issue you brought up is permission creep (when a user is reassigned to another permission and no longer needs access to resource X, but retains it anyway, because the fact that they no longer need access to resource X wasn't run by the IT Dept during the transition). The ONLY way to control this is to tell HR or whoever handles employee reassignments that IT needs to be notified when an employee gets reassigned so they can assign and revoke permissions appropriately. That's it. There is no magic application that will tell you a user has access to resource X but shouldn't anymore because their job is now Y. Human notification in some form has to be given to IT when this happens.

Related Topic