Pulling Local Admin Rights without causing the App-ocalypse

Or, what I like to call “Hah!, neener neener, No, you can’t go behind my back and install iTunes anymore!

(Disclaimer: There’s undoubted way more knowledgeable readers than me, especially in more Security related skills, that will cringe and tear apart what I’m about to write. But, this worked for my specific issue and it severely limits the security repercussions of using Local Admin. So, use these tips at your own discretion)

You know them, you hate them.

The poorly coded Windows software that simply will not run without Local Administrator privileges.

So, you’re forced to give your Users way more privileges than they need, simply to support some critical software that was designed wrong.

Well, I’ve found ways to fix this by changing only privileges on a granular, more focused level instead of the global use of Administrator accounts.

First some real world background on what caused me to need to learn this stuff.

We’re, (as of this writing but upgrading very soon), a Windows 2003R2 Domain. (don’t judge)

Plus we have some VERY expensive, and now irreplaceable, critical Enterprise line of business software from the XP era that was written to require Local Admin rights of the user or it simply didn’t run.

The software in question, since I’m going to reference it later, is called Agile Advantage. It’s some niche software for Product Lifecycle Management used in the Manufacturing industry.

Agile was an awesome company, but back in 2006 Oracle bought them and shut them down. Well, the software is essentially the spinal cord of our company, so here I am trying to keep it working as the Windows world advances along.

Ok, so Security Nightmare Number One. I am (now WAS, but we’re getting to that) required to give everyone who uses this software Local Admin privileges. Which, was essentially the whole company.

Now, leading into Security  Nightmare Number Two, as I mentioned above, we’re a 2003R2 Domain so we use a KIX script at log-in to map network drives. I know there are much better ways to do it, even under 2003R2, like Powershell, but it has been in place for a long time, and it works. Well, here’s the thing.

Security Nightmare Number Two The User Account Control (UAC), in Windows 7 forward, blocks the KIX script when ran under Local Administrator level accounts.

(Something I didn’t know before this, when ran under Local User UAC runs with the same privileges as Windows Explorer so it doesn’t cause this problem)

You can probably see where this is going.

Combine these two and now I’m giving Local Administrator to all my Users on Windows 7 PCs, AND turning off UAC. Both highly not recommended but I had no choice.

Moving on to the reason you’re reading this. I finally had enough and undertook the massive project of trying to turn this train wreck around.

(Tool #1 for you TL;DR visitors)
Being a huge fan of the Microsoft SysInternals suite of tools, I finally realized I could use Process Monitor to get a view of exactly what was going on behind the scenes in Windows when Agile Advantage was running.

Now, I at least have not been able to get Process Monitor to run except under Local Admin so this was a brief bump in my plan as the whole point was to test this application under Local User.

The solution in my case was to log into Windows with Local Admin privileges and then do a Right-Click Run As on the Agile Advantage exe and select a Local User level account.

This essentially tricks the application into behaving as if I was logged in as a local user but lets Process Monitor run as intended.

Process Monitor, if you happen to not know already, scans every single active system call that is going on in Windows. So, the critical trick to using it is Filters because it goes nuts when you first run it because it’s really a busy place behind the scenes of Windows.

By adding a filter for Process Name is, in this case AgileAdvantage.exe, to Include and then a filter for Result is Denied I was able to focus the background noise down to just the traffic I was looking for.

Keep in mind Process Monitor is highly customizable so I recommend playing around with the filters so you can get it to do just what you want for your specific situation.

This lead me to seeing Denied attempts against two local files in the C:\Windows and C:\Program Files(x86)\Agile Advantage 2006\ directories and also Denied against several Registry keys in the HKCR and HKLM hives.

By targeting those specific entries and changing the Advanced Security Properties for of each one to give LOCALPCNAME\Users Admin level privileges to just those files I then got Agile to run. There was a couple instances in the Registry keys where the LOCALPCNAME\Users account wasn’t even on the Security tab, so I just added it as needed.

Now, I used the Local\Users group because my intention is to create a generic image for future PC roll-outs and I don’t want to re-do this every time for each specific Active Directory account that might use the PC.

Ok, so I’ve gotten the application to run, but it was still acting squirrely. Some functions that normally worked immediately were now taking a couple minutes, etc. Details are going to be different for each person and each application.

For my specific case, this lead me to poke around forums for other possible tools to use to get a deeper view of what was going on. This lead me to

(Tool #2 for you TL;DR visitors)
The Microsoft Application Compatibility Toolkit. Now, this software does way more than I even know, or needed in this project so I’d recommend playing around with it more. The part I specifically used is called the Standard User Analyzer (SUA) under Developer and Tester Tools. When I directed SUA to my target application and launched it, I got some more in-depth views of the system calls on the various tabs.

On the Registry tab there was a couple more HKLM and HKU keys getting denied and on the Other Objects tab there was a sub-directory in the hidden C:\ProgramData directory that was trying to get written to and getting denied.

So, essentially what I’m saying is to use both of the tools listed above for your troubleshooting investigation.

Another similar tool that was brought to my attention by Chris Jackson, an Architect at Microsoft (@appcompatguy on Twitter) is called LUA Buglight.

For my specific instance I didn’t need this tool but it looks to be very useful for this and generates a concise text file report of the issues it runs into.

These steps fixed my specific problem that I’ve been fighting for years. It was a giant pain in the butt and I repeated these steps for a couple other key applications but combining all this work with a reference PC that I plan to use for imaging future systems, all the effort now will make future issues non-existent.

Now, some further adjustments I made because I’ve just found a lot of Windows Weirdness in the Event log over the years on systems running as Local User.

In Computer Management, Local Users and Groups, I added the following accounts to the following Groups.

NT AUTHORITY\Authenticated Users and DOMAIN\Domain Users added to the Distributed COM Users group. Again, I did Domain\Users versus a specific person because I’m creating a generic image system.

I also added them to a few others, like Event Log Readers, Performance Log Users, Performance Monitor Users, etc. just to make any future work I might need to do on the individuals computer under their account later easier. This is just something you can decide for your own individual instances.

Happy Hunting and I hope my project steps here help others in similar situations.

To reference back to my initial Disclaimer above. I’m sure there are reasons why what I did are probably not recommended by some professionals but I weighed the potential issues against allowing global Administrator privileges and decided these options were far preferable.