Introduction
One of the most common scenarios in a Windows enterprise environment is dealing with applications that puke UAC all over the user when they’re launched. A lot of sys-admins will immediately take the route of either turning off User Account Control or “UAC”, or adding the user to the local Administrators group. Both of these choices are bad. BAD. BAD. BAD. Very bad.
Not that I’m saying there’s never a reason to add someone to the Administrators group, but taking that approach as the first option is just dumb as hell. I’m talking dumb like ordering Pad Thai from a Burger King. There are much better ways to handle these situations. Let’s look at a few.
Preface
If you’re familiar with the art of software repackaging and deployment, this is old hat, so you can go back to sleep now. Just don’t do it at your desk. Do what one of my clients does and sneak off to the restroom to snore.
Remember, UAC is there to protect vital parts of the system from being modified without explicit approval. If you disable it, you allow *anything* to do what it wants to do. If you leave it alone, but add users to the Administrators group casually, it’s like giving everyone in your town a key to your home.
Try to think of this as if a neighbor, whom you don’t really know, needs to be able to get something from your house every morning without bothering you to hand it over. You’d probably find a location where you could leave the item so that it was accessible to the other person, while not causing concern about them walking into an area you don’t want them in.
It comes down to three steps: Identify, Plan, and Respond. In this case, identify what resources the application needs to modify; plan what to modify so that it can access them without running into UAC; and finally, putting the plan into action.
Step 1 – Identifying Resources
I bet you thought that the word “forensics” meant you had to put on those funky glasses and bust out the blue laser light to dust for finger prints. I’m talking about computer forensics. Otherwise referencing the practice of investigating things that happen on, or inside of, computers and their software aspects.
Some really useful tools for this sort of work include Sysinternals Process Monitor (aka “ProcMon”), any decent Log File parsing utility (I like the CMtrace utility that ships with System Center Configuration Manager 2012 R2), the Windows Event Log, and a few others.
Process Monitor
This utility combines the features of monitoring files, folders and registry keys into one interface. Start/Stop/Filter, and so on. It lets you see what’s going on under the hood.
The trick with using this for something like UAC testing is to practice your mouse clicking skills. You will need to launch ProcMon, pause the capture, clear the results, and then comes the tricky part. Start the ProcMon capture, then quickly launch the application you intend to troubleshoot. As soon as the UAC prompt appears, cancel it, and immediately stop the ProcMon capture.
Once you start playing with the filtering tools inside of ProcMon you should have an “a-ha!” moment. Note the folders, files and registry keys that appear to be causing UAC to jump out at you.
Step 2 – Planning
Assuming you were successful in identifying the appropriate file system and registry items, you can then try adjusting the security permissions on them to see how they impact the UAC situation. If certain changes appear to work, make sure you document what you modified.
Files and Folders
For manipulating file and folder security permissions you can employ quite a few alternatives to suit your needs. You can use command line tools like XCACLS, scripting methods within PowerShell, or create a shim using Application Compatibility Toolkit (ACT). Some folks like to use SubinACL, an older Microsoft utility, but whatever you prefer, if it works and doesn’t create additional problems, you’re good.
Registry Keys
For manipulating registry key permissions (you can’t apply security rights to values, only to keys), you can use the old REGINI command and a formatted input file, or the SUBINACL command with the appropriate parameters.
Services
Setting permissions on services involves two main aspects: The account used to launch the service, and the security descriptor data in the registry. The first aspect (account) can be viewed and manipulated using the SC command, or via WMI from almost any scripting or programming interface that supports WMI interaction.
The second (registry) can be viewed using the REG command. To apply changes, you could hack some code, which is often painful, or modify the value on a reference computer, export the settings to a .REG file and then use REG IMPORT to apply it to other computers.
Step 3 – Opening up Holes
I’ve already spoiled the plot here, but to reiterate a bit, your goal is to punch surgical holes in the protective layer around specific things, rather than taking down the entire defense shield. Better to keep the shields up in case the alien zombies attack from planet gorgitron or whatever.
SubinACL, REGINI, XCACLS, REG, SC, scripting tools, ACT shims, and so on, are often more than enough. If the problem is too big for those, the vendor needs to be dunked in a sewage pit and hung out to dry.
Conclusion
There’s no reason for making software in 2014 that doesn’t play well in a “best practices” secure environment. Especially and typical “out-of-the-box” environment for Windows 7 and Windows 8 computers.
I’m not talking about a Top Secret, SCIF type lock-down security box. I’m just referring to leaving things like Windows Firewall, UAC and so forth alone as much as possible. The application should bend to the rules, not the rules bending for the application. I know that’s wishful thinking for some situations, but that’s just my preference.
Skatterbrainz Blog 