AC: User Account Control

Article
10/14/2010

User Account Control

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 you log on as a member of the administrator's 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 the 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 may 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 is dependent upon how the application was written.
Control panel applications that perform administrative tasks and make global changes might not function properly and may 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 solution for custom installers:

A user can 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 and apply the Windows XP SP2 compatibility mode from the Compatibility tab.

Quick solution 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 may help applications that attempt to write 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 the "Links" section.
Wrap a "Run DLL as an app" DLL call in a separate EXE and include a manifest for this EXE to require elevated privileges.

Compatibility test

Any install, uninstall, 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 User Account Control 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 capability solution

Windows Vista and Windows Server 2008 based applications need to:

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 (formerly known as RunLevel).
Separate all administrative and non-administrative functions into separate EXEs. All functions that need higher privileges should be in a separate executable EXE with manifested execution level or a COM object running with administrative privileges. Launch the administrative tasks only when required. This 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 EXE to update the target application.
Control panel applications must move away from .cpl files to .exe files, and include a manifest for their EXE-based control panel applications that specifies the execution level required.
DLLs running under RunDLL32.EXE that need elevation should be modified into an executable EXE 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.