Windows – Restrict access to certain USB drives

Group Policy depends on Active Directory, whether for security or normal policies, and therefore, it is crucial to understand Active Directory and its structure.

I would like you to go through this Microsoft KB article. I hope this will be useful for you, and the link I'm posting is for Windows 2000 as you did not mention for which Windows version you want to restrict.

For sake of time, search for a third party tool, as today there are many third party tools available which are made to manage Active Directory in an easy way.

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.