Application Compatibility: UAC: Standard User Changes

Статья
07/18/2012

User Account Control: Standard User Changes

Feature Impact

High

Brief Description

A fundamental step toward increasing the security of Windows® is enabling interactive users to run with a standard user account, which gives them access to only a limited set of permissions and privileges. By default, Windows Vista® and Windows Server® 2008 will run every application as a standard user even if a user logs on as a member of the Administrators group. Conversely, when users attempt to launch an application that has been marked as requiring administrator permissions, the system will explicitly ask them to confirm their intention to do so. Only applications running with Administrator privileges can modify system and global settings and behavior. This feature of Windows Vista and Windows Server 2008 is User Account Control (UAC).

Manifestation

Custom installers, uninstallers, and updaters might not be detected and elevated to run as Administrator.
Standard user applications that require administrative privileges to perform their tasks might fail or might not make this task available to standard users.
Applications that attempt to perform tasks for which the current user does not have the necessary permissions might fail. How the failure manifests itself depends on how the application was written.
Control Panel applications that perform administrative tasks and make global changes might not function properly and might fail.
DLL applications that run using RunDLL32.exe might not function properly if they perform global operations.
Standard user applications writing to global locations will be redirected to per-user locations through virtualization.

Remedies

Quick solutions for custom installers:

Launch the installer or updater by right-clicking and selecting Run this program as administrator.
Apply an application-compatibility fix to indicate that specific installers require elevation. To do so, right-click the shortcut or the .exe file and apply the Windows XP SP2 compatibility mode from the Compatibility tab.

Quick solutions for applications that require administrative privileges to perform system modifications or write to privileged areas:

Corporate users will be able to apply an application-compatibility fix to indicate that the legacy application requires Administrator permissions or privileges to run correctly.
Reducing the restrictions of access control lists (ACLs) on certain restricted files might help applications that attempt to write to these files.
Check the virtualized folders or registry keys to see if applications are accessing something that requires administrator privileges. This information can be used to remove the requirements of accessing administrator-protected locations from future versions of the application. For more information about virtualized files, folders, and locations, see "Shell: Themes and My Documents Location" in Application Compatibility: Windows Driver Display Model.
Wrap a "Run DLL as an app" DLL call in a separate executable program and include a manifest for this program to require elevated privileges.

Compatibility test:

Any installation, uninstallation, or update scenario should prompt the user for consent or credentials. Upon receiving user approval, the action should succeed.
Attempt to reproduce the failing scenario as the built-in-administrator. If this scenario passes, the failure is probably due to a lack of privileges.
Use the UAC predictor tool of the Application Compatibility Toolkit's Compatibility Administrator to identify those areas of an application that are performing Administrator operations.

Leverage Windows Vista and Windows Server 2008 capability solution:

Follow the prescribed guidelines found in the Windows Vista and Windows Server 2008 LOGO programs and user experience (UX) guidelines documentation (see the "Links" section).
Use embedded manifests to indicate their specific requestedExecutionLevel attribute (formerly known as RunLevel).
Separate all administrative and non-administrative functions into separate executable programs. All functions that need higher privileges should be in a separate executable program with manifested execution level or a COM object running with administrative privileges. Launch the administrative tasks only when required (holds true for all applications).
For applications that are not specifically administrative in nature, modify code to eliminate need for Administrator permissions or privileges.
For applications that are only used by administrators, mark the application so it will run with Administrator permissions or privileges.
When updating an application, use a separate updater program to update the target application.
Control panel applications must move away from .cpl files to .exe files, and include a manifest for their .exe file-based Control Panel applications that specifies the execution level required.
DLLs running under RunDLL32.exe that need elevation should be modified into an executable program with its elevation level indicated in its manifest.
Always open files and registry keys with read-only access when possible. Use read-write access only when needed and revert the permissions back to read-only once the operation is complete.