12

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!

PHLiGHT
  • 1,041
  • 10
  • 25
  • 3
    For a while I had our Filesystem ACLs, all in an XML file, and I had a script setup, that would periodically run that would update the filesystem ACLs reflect the XML file. The XML file included comments. I never really got all the bugs worked out though. But my point was that you should see if you can make your documentation documentation be part of the tool that sets the ACLs. – Zoredache Jan 17 '13 at 22:19
  • I would look into changing my policies to not require me to track the history of file permissions at the file level, honestly. If you are actually required to do this by an outside entity, you're probably going to need a FIM solution (file integrity monitoring) like Tripwire, which can do metadata as well as file changes. – mfinni Jan 29 '13 at 14:07

7 Answers7

2

If you already have a ticketing system in place, I'd suggest creating a new group, or tag, etc in your application for these types of requests and have users send in tickets for permission changes. If your ticketing system allows you to forward tickets to other users, or add them into the ticket, add in the required managers and ask for verify. This would allow you to keep a record to cover your work.

As mentioned above, create a security group for every share. In my environment, we would have shares named FIN_Yearly, GEN_Public, MGM_Reports (each dept has its own acronym). Security groups would then be named SG_FIN_YearlyAdmin, SG_FIN_YearlyUser, SG_GEN_PublicAdmin etc. User is read only, Admin is read/write.

From here you could create, for example SG_FinancialsManager; security groups that include other security groups in order to simplify access based on the jobs that they do. We personally do not do this as it muddies up tracking a bit. Rather than checking a share's SG and seeing a bunch of SGs with permissions, we have a list of users instead. Personal preference, really, and will depend on the size of your site. We usually use user templates for managing new users to specific positions.

If your ticketing system allows you to search through previous tickets you're pretty much done. If someone requests you to remove a user's permissions, you can track it. If a user then questions why they no longer have access, you can provide them with the ticket. If a manager asks you who has access to what, printscreen the requested security group.

Insomnia
  • 507
  • 4
  • 10
  • Ticketing system +1. That is a very good point. We have ticketing system, but never pay attention to this usage(or question). – John Siu Jan 28 '13 at 04:45
2

There are actually several commercial applications for doing this. The area is sometimes referred to as "Data Governance".

A couple of examples:

Varonis Data Governance Suite
http://www.varonis.com/products/data-governance-suite/index.html

Quest One Identity Manager – Data Governance Edition
http://www.quest.com/identity-manager-data-governance

I don't use these but having researched the topic and seeing a few demos, the scope of what may can be required would explain the marketplace. These applications are very complex, and not inexpensive. Some of them have very sophisticated methods of hooking into storage platforms for tracking access control lists. Even if it is not in your budget, the demos can be useful to get an idea of what an application like this does from a functional perspective.

One observation I had while reviewing this is they typically do not audit at the file level. If they did, there would be no way it would scale up to hundreds of millions or billions of documents. So they typically only track permissions at the directory level.

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • Thanks for informing me of the term data governance. These seem like tools that are for the much larger players. It seems like a solution aimed at SMB is needed. – PHLiGHT Feb 04 '13 at 21:44
1

I don't know about documenting/tracking them, but I assign them with groups.

User A needs access to resource #1. They get permission and I add them to the access group.
They go on about their business until one day they get reassigned/fired/whatever, at which point I remove them from the access group.

My account modification audit logs tell me when they gained/lost access so there's a record of that, and the resource-access groups are typically departmental groups (HR, IT, Sales, Finance, etc.) so managing reassignments typically means changing their group membership anyway.

This tends to work best in smaller environments - for larger environments or ones where the ACLs get really complex Zoredache makes a good point about having the system that does the ACL-tweaking also do the documenting to some extent

For initiating the request to add/remove access, reassign users, etc. I would suggest electronic paper (a ticketing system) - this ensures users won't slip through the cracks, but requires overall corporate buy-in to use the electronic system religiously.
The advantage over paper is you get something you can search, and everyone can do their part of the process from their desk (managers can approve more quickly since there's no inter-office mail envelope moving around, IT can grant/revoke the access as soon as the ticket appears in someone's bin, etc.)

Community
  • 1
voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • I would also suggest that you delegate management of the groups to an appropriate person in the business. If they have an email address and appear in the GAL then they can be managed through the Address Book in Outlook in a very user friendly way. – dunxd Jan 25 '13 at 14:57
1

Best way I find to do a permissions setup is role based.

GG_HR GG_Finance Etc, generally mapped to the position or business unit.

From there you create local groups that have permission on the resource Ie the printer, or the Finance directory. LG_RoomXPrinter LG_Finance_Read LG_Finance_FullControl

You create Global Groups for these Local group LG->GG, then in your role based Global Groups you add the permission based Global groups.

GG_Finance <- LG_Finance_FullControl, LG_RoomXPrinter

Makes it easy when people get into a role you just add their account to one group and their permissions flow from that role and much easier to track. (Also great if you use some kind of Identity Management System). Much easier then tracking who has what individual permissions, you know that if they are in the HR group they have X permissions.

You can just track their group movement when they are requested via your job management system or run scripts to spit out who is in which role based groups.

Mark
  • 93
  • 1
  • 1
  • 7
1

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.

August
  • 3,114
  • 15
  • 17
0

Two great utilities:

  1. AccessEnum: http://technet.microsoft.com/en-us/sysinternals/bb897332
  2. AccessChk: http://technet.microsoft.com/en-us/sysinternals/bb664922

AccessEnum also allows you to save its results and then compare them in the future, which will be useful for looking for changes.

Sammitch
  • 2,072
  • 1
  • 20
  • 34
0

You should really consider enabling auditing of file/folder permission changes and then collect file server Security logs (manually or using any event log management tool or SIEM, like Splunk) and use it for your documentation. Analyze all changes to file DACLs. Plus you complement this with AccessEnum and AccessChk as suggested above.

And this does not release you from setting up proper security permissions and assigning them via groups only.

Netwrix
  • 1
  • 1