There are few things I love more than hearing, “This software requires Administrator rights.” Statements like this make me irritable and elated at the same time. An odd combination. On the one hand, I am irritable at that developer who can’t be bothered to follow best practices. On the other hand, I can’t wait to prove them wrong.
Though this guide won’t fix every single application that requires admin rights, it will solve the vast majority of these issues. We can break down administrative requirements into some pretty broad categories such as: file permissions, registry permissions, and User Account Control issues. Let’s talk about solutions for these three big problems.
Fixing File, Folder, and Registry Permissions with Group Policy
Standard users can write to just a few locations on a local machine by default. The primary location they control is their own user profile. Applications that write outside of these locations need additional permissions delegated to work properly with a standard user account. We have to overcome two problems to solve this issue:
- What permissions does this application require?
- How can I distribute these permissions automatically?
If the application is nice enough to say, “Hey – I can’t write to C:\StupidApplication\”, proceed to problem 2. If the developer doesn’t follow best practices with permissions, they probably don’t write helpful error messages either. Microsoft’s Process Monitor will show us what permissions are needed and it can be downloaded from here.
Ideally, install and run Process Monitor on a dedicated VM that has little else running on it (no AntiVirus, no indexing, etc). Process Monitor can be a little overwhelming at first. Like that annoying friend with no filter, it will literally tell you everything. Start your application as a standard user and reproduce any errors that you’ve received. Stop the capture in Process Monitor. Find your application in the capture, right click and filter only to it. You should now see exactly what your application is doing and the permissions needed to do it. Looking through the logs, you can further filtered to DENIED actions and see the exact permission that are needed.
Launch the Group Policy Management Console and create a new GPO named APP_Your Application Name (ex: APP_Adobe Reader). I prefer keeping all related settings, such as security settings or preferences, in a single GPO. Navigate to Computer Configuration/Policies/Windows Settings/Security Settings.
Right click on File System and Select Add File. From here, you can browse to the exact file or folder that needs additional permissions assigned. In the screenshot below, I’ve already added C:\Program Files\Meals Plus. Group Policy will automatically change any hard coded paths (like C:\Windows or C:\Program Files) to their correct variables. If a program can be installed in multiple locations (Program Files (X86) or Program Files), create a separate File permission setting for each.
The File System security settings in Group Policy allow you to easily deploy file and folder permissions to your clients. Though rarer, some applications might also need additional permissions to the registry. For example, an application may right a license key or registration information to HKEY Local Machine. Process Monitor is still used to find the requirements and Group Policy is still used to deploy the required settings.
Registry permissions are configured at Computer Configuration/Policies/Windows Settings/Security Settings/Registry. Right click on Registry – select Add Key. Navigate to the key that needs the extra permissions assigned. If the key does not exist on your computer, you can paste a key path directly into Selected Key location. As a note, you can also paste file and folder paths directly into the This Folder box under File System.
Fixing UAC Problems with Application Compatibility Toolkit
Occasionally, you will have an application that triggers a User Account Control (UAC) prompt when the application doesn’t require elevated rights. Don’t get mad at Microsoft for this one – the unnecessary UAC prompt is a result of shoddy coding. Preventing the UAC prompt can be accomplished in two ways:
- Stupid Way: Disabling UAC
- Easy Way: Creating an Application Shim
Because readers of this blog are never stupid, let’s take the easy way and create an application shim. Start by downloading and installing the Microsoft Application Compatibility Toolkit. Currently, it is part of ADK. Launch the Compatibility Administrator tool. Under Custom Databases, select New Database and press the Fix button in the toolbar. Name your application fix and browse to the executable that needs a bit more persuasion to work right.
Under Additional compatibility modes, scroll down and select RunasInvoker. You can press Test Run now to see if the application starts correctly. If it does, continue through the rest of the wizard. This tool can also be used to set other compatibility settings such as setting an application to run in particular mode for an older OS.
Save your database and it will generate an shim with the file format .sdb. You can deploy this fix by using a startup script (in Group Policy) or an application dependency(in SCCM). The script should simply run: sdbinst.exe .\applicationfix.sdb
We covered file/folder and registry permission changes with Group Policy and creating a shim for UAC. What other tricks do you use to fix applications that require administrator right
I followd this using procmon and filtering on access denied but had no luck. I got an app with UAC disabled that runs from a network share its an exe via UNC path. But when my standard users tries I only get “You must be an administrator” to run this file. On the server with the UNC path my user has full control. Watching procmon it basically fails to write to the same file as it tries to execute. No idea where to go from here.
its Win 7 box
Hi,
Nice post!
Sometime I use this little application http://www.robotronic.de/runasspcEn.html , free for private use only
Regards,
Bogdan
Now there is an application I haven’t seen in a while! Glad to see it is still in use.
Joseph,
You mention in your last part about using an SCCM application requirement to deploy the shim. Could you expand on this? If I look at my application requirements it seems they’re primarily used to test for a condition. But I’m thinking what you mean is you could use a script as a requirement to copy the shim file from somewhere to the local machine and then run sdbinst.exe and return a success so SCCM believes it passed the requirement.
Daniel.
I am afraid I used the wrong term there Daniel. I meant to use the shim as an application dependency. You deploy the shim but make the installed application the dependency of the shim application.
This may be the greatest moment of my life.
We have this Medical Billing software that requires me to go desk-to-desk and update the program every time they push out a major update (About once every 6 months or so). At first, it wasn’t too bad. We only had about 40 people, so it was time consuming, but not a massive deal.
Fast forward 1.5 years, and we’re now at 110+ users. Now when it happens, I usually come in on a Saturday or Sunday night and spent 3 to 4 hours going desk-to-desk, powering up, logging in as the Admin (requiring me to leave a note for everyone, since 1/2 of the people will just try and type their password into the Admin password credentials, instead of noticing that the name is wrong, and changing it) and then waiting for the computer to fully boot up, installing the ‘Hot Fix’ and then shutting it down.
This could save me an eternity. Thanks, as always!
I’m glad I could be a part of it Aaron! 🙂
Let me know when you get that application fixed!
Will do. This website has been a great inspiration for an aspiring System Admin.
It will be the happiest day. Now if I can just get the company that makes it to embrace the idea of a central user database, instead of the way they have it now, which means I have to create the same person 20+ times if they’re in multiple datasets.
You can also edit this reg entry on the machines you do log into to show the last username:
HKLM\Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\LastLoggedOnUser
You just need to change to DOMAIN\UserName
Hope this helps!
Joseph,
Great post! I have been doing these fixes for quite some years now! And, like you, I love the challenge of proving to myself that no applications require admin permissions whatsoever. I’ve been creating/adapting MSIs for more than 100 different applications and managed to make every single one of them to work without administrative rights (I’m proud of having an IT environment where none of my users have admin rights).
The interesting thing about circumventing these bad apps which require admin permissions is to see how many developers exist that know nothing about best practices for software development/deployment or how Windows is structured. User data belongs to AppData (and similar) folders, not Program Files folder!! I had an application which, on every start, tried to write a temporary file on the installation dir just to check if it had write access there – it did nothing with the write access afterwards, though… plain stupid!
Fixing applications that require administrator rights is easy… tough is to combine them with AppLocker or Software Restriction Policies and still keep users from running unwanted stuff (even if on purpose) in your machines. For people looking into doing that, here are some tips for achieving what Joseph describes and still have a safe environment:
– I have managed to deploy more than a hundred MSIs without ever resorting to giving any user administrative rights on Windows. If I did it, you can also do it.
– My toolbox: virtual machine, Process Monitor (from Sysinternals), an MSI repackager and an MSI Editor (I use Instedit). Process Monitor does wonders on determining where your application is trying to write where it should not. Filtering by the executables of your application and Result = ACCESS DENIED is almost 100% bullseye. An MSI repackager and editor will give you the possibility to change how the application is installed and workaround some limitations which would, otherwise, require admin rights.
– For applications that REALLY need to have write access to C:\Program Files or some other forbidden path, you can use the method Joseph described above (using GPOs for the exception permissions), or do as I do and modify the MSI to change the permissions (and grant Write access to users) where the application needs to write to. I found it better to create a Custom Action with a vbscript on it for changing the permissions upon installation.
– Implement AppLocker or Software Restriction Policies in your environment with a whitelisting approach: basically, users should be allowed to run software only from C:\Windows (and subfolders), C:\Program Files (and subfolders) and C:\Program Files (x86) (and subfolders). Problem is: if I change the application to allow write access to a subfolder in Program Files, then the user could exploit the fact that Program Files is an allowed location and run any executable from there – he copies virus.exe to C:\Program Files\Bad Application and runs it without any issues, since AppLocker allows executables on C:\Program Files and subfolders. What should you do then? Create, in AppLocker or SRP, a Disallowed rule to block that specific folder or file.
Some issues I have overcome over the years:
– Application tries to create/write a temp file (temp.tmp) in the application folder (C:\Program Files\Bad Application). For these cases, I have pre-created the temp file during installation and gave users write permissions to it (only write/modify and no delete permissions). This way, when the application starts up, it is able to write/modify the temp file, but cannot delete it, so it stays there with the permissions in place. In AppLocker/SRP, you create a Disallowed path rule pointing to the specific temp file – this way a user is unable to overwrite it with executable code and run it afterwards.
– Application stores settings or data in an application subfolder (e.g.: “C:\Program Files\Bad Application\db\data.db” or “C:\Program Files\Bad Application\config\settings.ini” or “C:\Program Files\Bad Application\downloads”). This is an easy one: you grant modify permissions to the data/settings folder or file (either on the MSI or through GPO) and adds a Disallowed rule in AppLocker/SRP pointing to the writable folder(s) or file(s).
– Application stores settings or data in an application folder or subfolder where executable code also resides. In this case, you cannot disallow executables on the folder because of the executable code which also resides there. You have three options:
1. allow write access only to the specific file that needs to be modified (in the case there is a single and pre-created specific file storing data or settings – e.g.: C:\Program Files\Bad Application\data.db) or;
2. try to modify the application somehow in order to make it store the settings or data somewhere else;
3. Use symbolic links to point the data or settings to somewhere else??? (I have never done this, although it seems to be a possibility).
Hope this helps someone. If you feel you have an application which is unwilling to work without admin access and none of my tips have worked for you, please let me know through comments on this post. I’ll do my best to help you.
Fabio Coelho
Hi Fabio – First, thank you for all of the tips! I really like the way you store permissions in the MSI and the way you use Applocker denies to add a bit more security.
Your symbolic links should work as a nifty way to redirect a program to a safe location. I use them all of the time for personal and work use. Smoke and mirrors!