Configuring Windows applications to run under non-Administrator accounts

While many Windows users continue to run as accounts with local Administrator rights, this practice increases the potential damage from malware. For this reason more users, particularly business users, are locking down access to local desktops. These restricted rights can cause many programs to function improperly or not at all if they were not written with restricted rights in mind -- and, historically, most haven't been.

The main reason behind reduced functionality is due to permissions issues -- that is file system (NTFS) and/or registry permissions. If you are encountering issues running an application as a User, check these common permission problems:

* The program attempts to write files to the Program Files folder or sub-folder. The Users group has read-only permission to this folder by default. Many programs attempt to save data or configuration files to their installation path. The simplest solution is to grant Users Modify permission only to the affected application's installation folder.

* The program attempts to write files to a Windows folder. Granting the user additional rights to a system folder would eliminate a major reason for restricting administrative rights in the first place. In this case the recommended solution is to run the program as an Administrator to create the files required, then grant Users Modify permission to those particular files. If you aren't sure which files were created or being access, we recommend Filemon (more details on this below).

* The program attempts to create or alter entries in the HKEY_LOCAL_MACHINE registry hive. HKEY_LOCAL_MACHINE contains system-wide settings and is therefore read-only to non-administrative users. Security conscious applications will save user settings in HKEY_CURRENT_USER, though many do not do this. The simplest solution is to grant the Users group Modify access to the affected keys, which will typically be found under HKEY_LOCAL_MACHINE\Software\>company or application name<. Windows XP and later users can use REGEDIT to change permissions. Windows 2000 or NT users must use REGEDT32.

* The program attempts to create or alter files or folders in another restricted-access folder. The program may create files or folders in another folder to which Users have restricted access. To locate these files you can use Filemon. When running this utility will monitor all attempts to access files and note if they were successful or not. Start logging activity with Filemon, attempt to run the program, then stop the capture. Review the logs with particular attention paid to failed attempts to create or modify files or folders, then grant permissions as appropriate.

* The program attempts to create or alter registry keys or values in a restricted-access hive or key. Filemon's counterpart Regmon will monitor registry access. As described above, start logging activity with Regmon, attempt to run the program, then stop the capture. Review the Regmon logs for failures and grant permissions to the affected keys.

If none of the above solutions work, on Windows 2000 and later systems you can also configure individual programs to Run As another user with administrative rights. The RunAs Service on Windows 2000 or the Secondary Logon service on Windows XP must be running in order to use alternate credentials in this way. See article 294676 on Microsoft's website for more information on configuring applications for alternate credentials. Also see this Techbyte for a script which can be used to add the Run As... option to the right-click context menu for all .MSI and .MSP installation packages.

Author: ASAK
Created: Oct 5 2005 (last modified Jan 31 2007)
Categories: Windows
TechByte #43

Warning: By visiting this site and/or by using any information contained herein, you agree to the Techbytes.ca terms of use.