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.

There’s a handy little query you can run in SQL to retrieve the identity (primary key) value of a record you just created. So, you can do something like this:

INSERT INTO
  People (
    Name
  ) VALUES (
    'Joe'
  );
  SELECT @@IDENTITY AS NewName;

This query will create a new person and also return the identity value of the newly created record. It can be useful for all kinds of things - I use it frequently.

We recently upgraded to ColdFusion 8 here at Purdue, and my code started breaking.

It turns out that CF8 attempts to “help” you by automatically running SELECT @@IDENTITY after any INSERT query. This is problematic in two ways - it cancels out your own @@IDENTITY query, and it arbitrarily names the result Generated_Keys.

So instead of being able to do something like this:

<cfset TheNewName = People.NewName>

You must use this:

<cfset TheNewName = People.Generated_Keys>

It’s really more annoying than anything else. It seems like a good idea to include the code automatically, but I think it would probably be a little better if there were a conditional in there that prevents CF8 from inserting its automatic query if a SELECT @@IDENTITY query is already present.