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.