An Application Cannot Run as a Standard User

  • Article

Applies To: Windows 7, Windows Server 2008 R2

Symptom

An application cannot run as a standard user in Windows 7.

Cause

The standard user account type in Windows 7 provides a limited set of permissions needed for most non-administrative application scenarios.

Some application tasks are considered administrative tasks that always require administrative privileges. These tasks cannot be accomplished by using a standard user account. However, an application may require administrative privileges when the privileges are not necessary. For example, an application may require that a log file be written to a restricted folder, such as C:\. In operating systems prior to Windows Vista, administrators had to either loosen the access control list (ACL) on the restricted folder or add the user to the local Administrators group in order to run the application. This violates the principal of least privilege and creates greater potential for malicious software (malware) to run.

To help secure your network, assign the least amount of permissions to user accounts that allow users to perform their required tasks. This is known as the principal of least privilege. This reduces the capability and impact of malware if it does run on a user's computer. The principal of least privilege is employed in Windows 7 by restricting non-administrative users to standard user accounts.

Windows 7 includes file and registry virtualization technology for applications that are not User Account Control (UAC) compliant and that require an administrator's access token to run correctly. When an application that is not UAC compliant attempts to write to a protected directory, such as Program Files, UAC gives the application its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile. This strategy creates a separate copy of the virtualized file for each user that runs the non-compliant application.

Please note the following exceptions:

  • Virtualization does not apply to applications that are elevated and run with a full administrative access token.

  • Virtualization is not supported on native Windows 64-bit applications. These applications are required to be compatible with UAC and to write data into the correct locations.

  • Virtualization is disabled for an application if the application includes an application manifest with a requested execution level attribute.

Resolution

The following tasks are designed to help you troubleshoot an application that cannot run as a standard user. The tasks are presented in the order that they should be completed. Information is provided to help you test and resolve the issue.

Analyze the behavior of the application

You may investigate the behavior of the application by using tools that monitor file and registry activity. There are several free tools available to help you analyze the behavior of the application:

Check if there is an update that fixes the issue

Fixing problems with the application can be as simple as upgrading to the latest published version. For older applications, updates or bug fixes may no longer be an option.

Verify that this is a standard user compatibility issue

Verify that the problem is actually related to running with lower privilege and not related to another Windows 7 compatibility issue. To determine whether there is a standard user compatibility issue, on a test computer, attempt to run the application with a user account that is a member of the Administrators group.

Important

Because testing for standard user compatibility can cause permanent configuration changes that can affect the reliability and repeatability of further application compatibility testing, this should be done only on a computer that is set up for testing purposes.

Some programs are designed to perform legitimate administrative actions and therefore require administrative permissions. For example, if the application is designed to install or manage software on the computer, then it requires administrator-level permissions to perform these actions. Tools that manage system resources generally require administrative permissions and need to run with a user account that is a member of the Administrators group. These tools can be used only by users who are logged on as members of the local Administrators group or users who can provide administrative credentials.

To test for standard user compatibility, right-click the application icon, and then click Run as administrator.

Note

In some cases, Windows 7 may present an unexpected UAC elevation prompt. This is due to the heuristics used in determining whether the application is a software installer. For example, if the application is named Setup.exe, Windows 7 assumes that it is an application installer and must run with a user account that is a member of the Administrators group. For this situation, you can use the SpecificNonInstaller application compatibility database to run the application. For information about application compatibility databases, see "Create an Application Compatibility Database" in User Account Control: Planning and Deploying Application Compatibility Databases in Windows 7 (https://go.microsoft.com/fwlink/?LinkID=148442).

If the application has a compatibility issue when running as standard user, you can attempt to resolve the issue by installing one or more application compatibility databases. Application compatibility databases modify the behavior of the application in ways that address common standard user compatibility issues. Because each database changes the system behavior for the targeted application, it is possible that the database may introduce a separate compatibility problem with the application. Therefore, you should only install the application compatibility databases that are required for the application to run.

For information about application compatibility databases and how to use them, see "Create an application compatibility database" in User Account Control: Planning and Deploying Application Compatibility Databases in Windows 7 (https://go.microsoft.com/fwlink/?LinkID=148442).

Convert computer-wide data to per-user data

When you convert computer-wide data to per-user data, the data is maintained in the user's profile and available only to that user. However, if multiple users are accessing and changing the same data, there may be multiple versions of the data with no clear understanding of which data is the most current and no way to merge the data.

Two examples of converting computer-wide data to per-user data are:

  1. Identify HKEY_CLASSES_ROOT (HKCR) keys that the application writes to and create those keys under \HKCU\Software\Classes in the registry.

  2. Identify .ini files that the application writes to and create IniFileMapping entries for those files in \HKEY_LOCAL_MACHINE\Microsoft\WindowsNT\IniFileMapping in the registry.

For information about adding Windows registry keys, see How to add, modify, or delete registry subkeys and values by using a registration entries (.reg) file (https://go.microsoft.com/fwlink/?LinkID=84245).

Modify the ACL for a file or folder

Modify the ACL for one or more of the files or folders in shared locations that are used by the application. Use the following guidelines to help you determine what changes to make:

Warning

Modifying the ACL on a file or folder may introduce a security risk to the computer. To limit the security risk of giving standard users additional permissions to files and folders in the application installation folder, you should determine exactly which files and folders are affected and then grant additional permissions to only those files and folders.

  1. Make ACL changes to application-specific resources only. ACL changes should be considered only on application-specific resources, not on operating system resources. While it may be acceptable to change the ACL on %ProgramFiles%\PublisherName\ApplicationName\DataFolder, you should never change the ACL on %SystemRoot%\System32.

  2. Limit ACL changes to files that are not used by administrators. Avoid changing ACLs on resources that are used by administrators or services, particularly executable files such as .exe and .dll files. Doing so increases the risk of "elevation of privilege" that can lead to compromising the entire system. If you must change ACLs for resources used by administrators, the exposure to attacks still remains far smaller than it would be if all files always ran as an administrator.

  3. Avoid ACL changes on binaries. To prevent malware from infecting or replacing program files, avoid changing ACLs on program files (for example, .exe, .dll, or .ocx files).

  4. Limit ACL changes to a single standard user. Ideally, the resource should be one that is accessed by a single standard user only. If the resource is accessed by multiple standard users, there is increased risk of one user causing another user's account to be compromised.

  5. Grant the least additional privileges possible. You should grant the least amount of additional access to the smallest possible number of resources and to the smallest possible number of users to allow the application to function properly. Granting Full Control to the Everyone group on a large number of the system files or the registry should never be necessary.

    Granting the additional access only to the primary user of the computer is optimal but may be difficult to manage across a large number of computers when each computer has a different primary user. If you can define a set of users who need to use the program, add them to a group and grant the access to that group.

  6. Grant access to the Interactive group. Another alternative to consider is to grant access to the Interactive group. This grants the additional access only to those who are logged on interactively at the time without granting additional remote access to the resource.

    Some of the group security identifiers (SIDs) do not correspond to an actual security group in Active Directory Domain Services (AD DS) or a Security Accounts Manager (SAM) database. Instead, they represent properties of the method of logon. For the Interactive group, an Interactive SID is present in an access token, but the Interactive group does not exist in AD DS or a SAM database. This SID is present in an access token when the user's logon type is Interactive. Access to an object whose discretionary access control list (DACL) contains this SID is different for a given user depending on how the user is logged on (whether or not the SID for the Interactive group is present in the user's access token).

Note

In a Remote Desktop or Fast User Switching scenario, there can be multiple simultaneous users on the computer that have the Interactive SID in their tokens.

Run the one application as an administrator

If no other solution works, run the single non-compliant application as an administrator. As an alternative to running the application as an administrator, investigate applications that help standard users run the applications that they require without granting additional privileges to the user or the application.

Additional resources