dumpDirSec - a utility to help report on NTFS shared directory permissions
Summary
This utility works similarly to the Somarsoft DumpSec utility except that it doesn't just report on which groups are assigned to a resource. Instead, it displays a list of end users and their access rights so you don't have to manually chase out group memberships to see who has what access rights. The main idea was to create a utility that could be used to audit the results of assigning a particular group access to a shared folder and the resulting report should be easy enough for even an end-user to interpret.
Background
At my workplace, we have a file server that shares out parts of its filesystem to help our users collaborate on departmental projects. These projects span everything from company budgets to performance reviews to documentation of business practices and policies. Since much of these documents are sensitive and need to be only available to a limited number of employees, we employ NTFS permissions to limit users' access to the various directories on the server. The problem that then arises is that it's difficult for the end-users to easily determine exactly who has access to a particular directory.
As a result of the above issue, I sometimes get tasked with creating a report of which employees have access to a particular directory on the server, and for some reason which baffles me, Microsoft never created a way to generate a simple access report that I could simply email to the end user. Consequently, it's been a time consuming, manual process every time I get one of these requests. About a month ago, I decided I'd had enough of manually chasing out group memberships, so I set out to create a tool to do the job for me.
dumpDirSec is the result of my efforts to make the process more user friendly. Since my work environment includes a management ethos that prevents me from writing any sort of program while on the job, I created the program in my spare time and now I'm providing it to you for free under the GPL.
To begin developing the program, I started out searching the web for a suitable toolkit that would make the development go a bit faster using c# and .Net as a development environment. Thankfully, I managed to find this project which simplifies much of the work necessary to decode the access control list(ACL) associated with a shared directory. The only problem the above library had was that it couldn't take a text based SID and back-convert it into a binary SID. Since some of the entries in our Active Directory use SID History, I added that functionality to the library. My emails to the original author to insert my added code have gone unanswered, so I'm providing a copy of the modified library with the source code. If you are affiliated with gotdotnet.com and you can get me in contact with the author of the library, email me.
Program Requirements
In short you need this:
- .Net 1.1 runtime or higher
- File Server joined to an Active Directory domain with at least 1 global catalog server
- All access controls have to use domain local groups, at a minimum. Groups local to the server are not currently supported
- The workstation/server the tool is used on must be Windows based. This is because Linux and other alternative OS's don't have the support libraries needed to decode the access control list.
To use this program, you must have the .Net 1.1 runtime installed on your workstation. I personally would recommend you download the .Net 2.0 runtime since it's backwards compatible with .Net 1.1 programs and it includes all of the service packs and security updates for .Net 1.1. dumpDirSec is a .Net 1.1 program, so you can get away with the older runtime if that's what you currently have installed. Furthermore, since the gotDotNet library uses native Win32 API calls to decode the ACL, your workstation will need to be running Windows 2000, Windows XP, or Windows Server 2003. Sorry, but trying to get this program working under Linux or BSD is beyond the current scope of the project.
As for the expected infrastructure, our fileserver is running MS Windows Server 2003, and our infrastructure is based on a Windows Server 2003 Active Directory. As far as I'm aware, it should work fine on a Windows 2000 based infrastructure, but it definately will not work under anything older than that. Furthermore, the program expects you to have used domain local groups when assigning permissions to the folder. It will then search for that group in Active Directory using the global catalog and enumerate the membership of the group searching for the end-users. Beyond that, you can nest groups within groups to any number of levels that your Active Directory will allow and the program will search through them all recursively to find the names of the users. If duplicate user entries are found during this process, they are removed to make the final report easier to read.
The older practice of using a group local to the server to assign permissions isn't expected and may cause some unsual or incomplete results. My workplace stopped using this method of assigning permissions because it became too difficult to move the data between servers when implementing disaster recovery plans. Successful recovery meant that the server's SAM had to be recovered and since that meant the name of the server and it's operating system couldn't be changed, we abandoned the practice almost as soon as we implemented Active Directory. Today, I would expect this to be the norm in most work environments. Of course, I'm open to any suggestions or code contributions that would improve the ability of the program to handle a wider array of permission assignment methods.
Using the program
To keep the use of the program as simple as possible, the program uses a wizard-like set of dialogs to get information from the user. The directory on which to report as well as various options are asked of the user to help determine what the format of the report should be and what information should be included in the report. As a result, you can generate a list of email addresses, telephone numbers, or even OU names as a result of just filling in the options in the wizard. On the last page of the wizard, you can choose to save the report to either a text or CSV format file for further processing. When the wizard is finished, the text format report is displayed in a dialog where it can then be copied/pasted into another application. Note that UNC directories may be specified when saving reports or selecting which directory to report on.
In the event the program doesn't list the particular attribute you require, the code is designed to be easily modified so you can report on any Active Directory attribute you require. The only limitation is your ability to program in C# and the availability of a .Net compiler. I used Microsoft Visual Studio 2003 to create this program, but other compilers should work as well. If you do make changes, please feel free to contribute those changes back to the project.
Closing Thoughts
By all means, as the program stands right now, it's less than perfect. For instance, I purposely skipped over any access control list entries that start with the word BUILTIN such as BUILTIN\Administrators. I did that to keep the final report simple/easy for the end user to understand. Technically speaking, the Administrators group has to be in the access control list or the administrators of the server wouldn't be able to change the access list very easily, and most end-users expect that their support department has access to the files anyway. On the other hand, I didn't exclude entries that begin with NT AUTHORITY even though that particular prefix is almost the same as BUILTIN. The program also doesn't expect to chase group memberships through domain and forest trusts. My environment didn't have that as a requirement, so I didn't take the time to work around that issue during development. In short, you should expect some unpolished areas in the program.
There is no installer for this program. You will need to have the W32Security.dll file and the dumpDirSec.exe file in the same directory on your PC, but that's about all the support there is for installing this as an application. It seemed excessive to create an installer just to copy 2 files to a folder and create a shortcut, so I didn't bother with it.
Finally, if you aren't an administrator of a shared directory or the file server on which the shared directory resides, please consult with your system administration department before you try running this utility. I can't accept responsibility if the program causes a problem for your sys admins and I doubt your administrators would support your use of this utility. You can ask them nicely if using this tool is ok and that's probably the best way to proceed. Don't be surprised, though, if they don't immediately embrace the idea, however.
Download