Auditing Local Admin Rights

This article contains information on:
  • How to avoid making users local administrators
  • How to script reports on local administrators

When I first worked for a shop moving from "Wintendo" to Windows 2000 Professional we did it right:  we decremented local administrator permissions.  Users couldn't install applications, couldn't modify the registry, and couldn't install ActiveX controls.

Perhaps most importantly they couldn't open an e-mail attachment and unwittingly unleash a virus on our network.  Hell, we even had a senior admin with the forethought to remove the "Run" functionality and command prompt from the Start menu.

We ran into problems.  For one Microsoft's own MapPoint application (this was *years* ago, mind you) accessed the HKLM registry key in write rather than the minimal read required.  Users couldn't do their jobs.  It sucked and we were blessed to have leadership in the organization that endorsed our efforts and let us work through problems.

Nowadays vendors are slowly getting the idea that users need to execute their applications without having carte blanche on the box.  Slowly.  At a glacial pace, in fact.

If you have an application that mysteriously won't run upon removing admin-level access you have options:

1. Grant them local admin rights.  Have them log out and back in.  Run the app.  Log out.  Remove local admin rights.  Have them log back in.

2. Blindly grant access to files and registry locations.  C:\Program Files\CrazyApplication is a great place to start.  Its counterpart in the registry is HKLM\Software\CrazyApplication

3. To find out for sure visit sysinternals (now part of the... empire).  Download these:

Filemon - monitors file access.  Tweak the filter for "Access Denied" events.  Also filter out irrelevant data like your AV scanner, and the normal flood of stuff like explorer and the like that are part of running any Windows OS. 

Regmon - monitors registry access.  Again tweak the filter for "Access Denied" events and irrelevant data.

Procmon - a healthy combination of the above utilities and more.

4. Once you've got Filemon and Regmon running and the results analyzed do the sane thing:  Grant "Modify" access to the necessary files and/or registry keys.  (Note:  Full Control is overused and often unecessary - giving the users the potential to set their own permissions on the object.) 

Remember:  giving out "Modify" access to all Domain Users on the C:\Program Files\CrazyApplication folder is one thing, giving out "Modify" to %WINDIR%\SYSTEM32  or worse, %SYSTEMDRIVE% is another.

Same rule of thumb applies to the registry.  HKLM\SOFTWARE\CrazyApplication is fine.  Granting them modify on all of HKLM\ bad.  Quite bad, in fact.

5. Grant Power Users.  Know that when you do you're giving them access to core OS files (read ntoskrnl.exe).  Others have said it better like my hero Mark Russinovich does here.  May as well just

6.  Grant local administrator access. 

Don't add user Joe Blow to the local administrators group

Do add user Joe Blow to the RYANBOYER.NET\CrazyAppsAdmins domain group then nest that group inside local administrators on the workstation.  Because RYANBOYER.NET\CrazyAppsAdmins is a domain group I can configure it to be restricted.  You'll also need to have sufficient permissions in Active Directory before you can go modifying it.

If you resort to #6 audit your machine population every once and again.  Dump out a list of local administrators.  If you can keep individual users out of the administrators local groups any that find their way in will stick out like a sore thumb when you look over your report.

Here's how I get a quick-and-dirty audit of my machine population every week:


I welcome comments for additional steps before resorting to granting local admin. 

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    Response: check my blog
    Nice Site, Preserve the good job. With thanks.

Reader Comments (2)

Can't say enough good things about procmon. We had a royal pain of an application the other day at the grind and procmon kept our upgrade going smoothly.

Run procmon on the machine and start capturing events. If the computer is running a ton of bloatware or antivirus or whatever you'll quickly start seeing thousands of entries flash by on the capture screen as normal operations generate a lot of legit read/writes to the registry and file system. Use the filter option liberally.

Once I had filtered out things like rtvscan, vp.exe, explorer.exe, svchost.exe ("Process Name" > like > and EXCLUDE) I started looking for anomalies outside of the SUCCESS status column. This made "file not found" and "ACCESS DENIED" entries really stand out.

Our problem? The application was looking for .dll in the WOW64 directory (short for "Windows on Windows" subsystem - that's how 64-bit versions of Windows run 32-bit applications). I copied the necessary .dll's to the folder and the application ran.

(In this particular case the .dll's didn't need a regsvr32.)

Love procmon.


February 18, 2010 | Registered CommenterTallarico

Great script, but would be great if it could traverse the entire domain and dump the results to a single file..

October 8, 2014 | Unregistered Commenteranon

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>