My friend Danny is a systems administrator and all-around IT guy at a manufacturing company in Indianapolis. He recently came up with a pretty useful little script, and wanted me to pass it on to the world.
Recently I needed to find out which folders a certain person was able to access on our Windows network. Apparently, this was extremely easy in Novell. Since it isn’t 1995 anymore, I tried to find a way to do this on the Internet. I couldn’t, so I set about making my own.
Microsoft has a utility called xcacls.vbs (if you’re using Vista, you’ll have to make sure WMI is installed, and modify the script. If you can’t do that comfortably, you probably don’t want to be messing with the rest of this anyway). It will allow you to change and view ACL’s from a command line. Since I’m not that interested in modifying the ACL’s in a script, the usage is fairly simple “xcacls c:\windows” will result in a listing of who has entries in the ACL and what the entry is (n.b. you’ll also have to have the default script host be cscript. Wscript won’t work).
In order for this to be useful, we really need to be able to have it run automatically on several, if not all, folders on a computer. The first step would be to get a list of the folders we want to run this on. I chose to limit it to one folder and all its subfolders only (c:\ will do everything, while c:\windows will only do the folders in c:\windows. If you want to do c:\windows and c:\program files only, you’ll have to run it twice).
What I was looking for was basically a text file that just had all the folders. This command will create exactly that:
dir "c:\program files" /s /b /o:gn /a:d > c:\batch\xcacls\dirlist.txt
Now that we’ve got a list of all the folders we need to search, we need to actually loop through it.
For /F "tokens=*" %%i in (dirlist.txt) do c:\batch\xcacls\aclSearch.bat administrator %%i
C:\batch\xcacls\aclSearch.bat is another batch file which takes two parameters (I’ll show you it in a minute). I call the other batch file so I don’t have to worry about how DOS handles variables (it doesn’t like to evaluate them during runtime, and will wait until the loop is done and use the final value for each iteration. It’s weird, I know).
A caveat about the for loop: when using for in an interactive CLI you use a single % sign in front of the i, when using it in a batch file, it’s a double %. Don’t ask me why.
aclSearch.bat contains the following
call c:\batch\xcacls\xcacls.vbs "%2" > c:\batch\xcacls\xcaclsResults.txt
find /i %1 c:\batch\xcacls\xcaclsResults.txt
if %errorlevel%==0 goto Found
goto End
:Found
echo %2 >>c:\batch\xcacls\%1results.txt
:End
This calls xcacls.vbs (from Microsoft) passing it the folder name. The quotes are there to handle filenames with spaces. It then sends the results into a temporary file called xcaclsResults.txt
Next we do a find using the search string (the first item passed – administrator in this example) on that file. If Find finds a match, the errorlevel is 0; if not, it is 1. If the errorlevel is 0, then the folder name is put into a results file named whatever the search string is, with results.txt appended (in this example it’d be administratorresults.txt).
So, how do you actually use all this? FindPermission.bat contains:
dir %1 /s /b /o:gn /a:d>"c:\batch\xcacls\dirlist.txt"
for /F "tokens=*" %%i in (dirlist.txt) do c:\batch\xcacls\aclSearch.bat %2 %%i
To search the c:\program files directory for anything the administrators group has access to you’d type:
Findpermission.bat "c:\program files" administrators
The results will be in the same folder you ran findpermissons from and be called administratorsResults.txt. To search the C drive for anything Danny Parrott has access to, you’d need:
Findpermission.bat c:\ "Danny Parrott"
The results from this one will be in Danny Parrottresults.txt.
This does require that Findpermission.bat, aclSearch.bat, and xcacls.vbs be either in the same folder, or in a folder that’s in the path variable. It will work for either users or groups. This process is also not instantaneous. The xcacl.vbs script can take upwards of half a second to run, so on larger systems, this is something you’d want to start and come back to later. On the plus side, though, it hardly uses any system resources while running (5MB RAM and 2-4% CPU time on a four-year-old server at work) so you can run it during the day.
