The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)

 

Microsoft Corporation

September 2006
Revised April 2007

The Windows Vista and Windows Server 2008 Developer Story includes content for developers, and other technology experts and managers, interested in an in-depth exploration of some of the new and extended features in Windows Vista. It is released to the Windows Vista Developer Center in the form of brief articles, published approximately once every two weeks. Those articles are only a summary of the Windows Help file, which can be downloaded here.

Note   To provide feedback about the articles, please send e-mail to Vistadev@microsoft.com.

Contents

Introduction
Why User Account Control?
How UAC Works
Will UAC Affect Your Application?
Designing Applications for Windows Vista
Deploying and Patching Applications for Standard Users
Troubleshooting Common Issues
References
Conclusion

Note   The entire contents of this article can be found in the Windows Help file, which can be downloaded here. To find this topic in the Help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Introduction

This article is intended to assist application developers with designing Windows Vista capable applications that are User Account Control (UAC) compliant. Detailed steps about the design process are included, along with code samples, requirements, and best practices. This article also details technical updates and changes to the user experience in Windows Vista.

Why User Account Control?

Application developers have consistently created Microsoft Windows applications that require excessive user rights and Windows privileges, often requiring that the executing user be an administrator. As a result, few Windows users run with the least user rights and Windows privileges required. Many enterprises, seeking to balance ease of deployment and ease of use with security, have often resorted to deploying their desktops as administrator due to standard user application compatibility problems.

The following list details additional reasons it is difficult to run as a standard user on computers running operating systems earlier than Microsoft Windows Vista.

1. Many Windows applications require that the logged on user be an administrator, but these applications do not actually require administrator-level access. These applications perform a variety of administrator access checks before being permitted to run, including:
   1. Administrator access token checks.
   2. "All access" access requests in system protected locations.
   3. Data writing to protected locations, such as %ProgramFiles%, %Windir%, and HKEY_LOCAL_MACHINE\Software.
2. Many Windows applications are not designed with the concept of least-privilege and do not separate user and administrator functionality into two separate processes.
3. Windows 2000 and Windows XP create every new user account as administrator by default; therefore, key Windows components, such as the Date and Time and the Power Management control panels do not work well for a standard user.
4. Windows 2000 and Windows XP administrators must create two separate user accounts—one for administrative tasks and a standard user account to perform day-to-day tasks. Therefore, users must log off their standard user accounts and log in again as an administrator, or use Run As to perform any administrative tasks.

With User Account Control (UAC), Microsoft provides a technology to simplify deploying standard user desktops in the enterprise and at home.

Building off of the Windows security architecture, as originally designed in the Microsoft Windows NT 3.1 operating system, the UAC team sought to implement a standard user model that was both flexible and more secure. In previous versions of Windows, one access token was created for an administrator during the logon process. The administrator's access token includes most Windows privileges and most administrative security identifiers (SIDs). This access token ensures that an administrator can install applications, configure the operating system, and access any resource on the computer.

The UAC team took a drastically different approach to designing the access token creation process in Windows Vista. When an administrator user logs on to a Windows Vista computer, two access tokens are created: a filtered standard user access token and a full administrator access token. Instead of launching the desktop (the Explorer.exe process) with the administrator's full access token, the filtered standard user access token is used. All child processes inherit from this initial launch of the desktop, which helps limit the attack surface of Windows Vista. By default, all users, including administrators, log on to Windows Vista as standard users.

Note   There is one exception to the preceding statement: Guests log on to the computer with fewer user rights and privileges than standard users.

When an administrator user attempts to perform an administrative task, such as installing an application, UAC prompts the user to approve the action. When the administrator user approves the action, the task is launched with the administrator's full administrator access token. This is the default administrator prompt behavior, and it is configurable in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy (gpedit.msc).

Note   An administrator account on a Windows Vista computer with UAC enabled is also called an administrator account in Admin Approval Mode. Admin Approval Mode identifies the default user experience for administrators in Windows Vista.

Each administrative elevation is also process specific, which prevents other processes from using the access token without prompting the user for approval. As a result, administrator users have more granular control on what applications install while greatly impacting malicious software that expects the logged on user to be running with a full administrator access token.

Standard users also have the opportunity to elevate within a task flow to perform administrative tasks by using the UAC infrastructure. When a standard user attempts to perform an administrative task, UAC prompts the user to enter valid credentials for an administrator account. This is the default standard user prompt behavior, and it is configurable in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy (gpedit.msc).

For detailed information about "Why User Account Control?" see the Windows Help file, which can be downloaded here. To find this article in the Help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

How UAC Works

This section describes the architectural and functional components of User Account Control (UAC) for application developers.

New Technologies for Windows Vista

The following sections detail new technologies for Windows Vista, including the ActiveX Installer Service, installer detection, standard user patching with Windows Installer 4.0, Security Center integration, User Interface Privilege Isolation, and virtualization.

ActiveX Installer Service

The ActiveX Installer Service enables enterprises to delegate ActiveX control installation for standard users. This service ensures that routine business tasks are not impeded by failed ActiveX control installations and updates. Windows Vista also includes Group Policy settings that enable IT professionals to define Host URLs from which standard users can install ActiveX controls. The ActiveX Installer Service consists of a Windows service, a Group Policy administrative template, and some changes in Internet Explorer. The ActiveX Installer Service is an optional component, and will only be enabled on client computers where it is installed.

Installer Detection

Installation programs are applications designed to deploy software, and most write to system directories and registry keys. These protected system locations are typically writeable only by administrator users; this restriction means that standard users do not have sufficient access to install most programs. Windows Vista heuristically detects installation programs and requests administrator credentials or administrator approval in order to run with access privileges. Windows Vista also heuristically detects updater and un-installation programs. A design goal of UAC is to prevent installations from being executed without the user's knowledge and explicit consent since installations write to protected areas of the file system and registry.

Important   When developing new installation programs, much like developing programs for Windows Vista, be sure to embed an application manifest with an appropriate

requestedExecutionLevel

element (see Step 6: Create and Embed an Application Manifest in downloadable Help file). When the

requestedExecutionLevel

is present in the embedded application manifest, it overrides Installer Detection.

Installer Detection only applies to:

1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with UAC enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

• Filename includes keywords such as "install," "setup," and "update."
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side application manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the resource file data linked in the executable.
• Targeted sequences of bytes within the executable.

Note   The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.

Ensure that you thoroughly review the entirety of this document, including "Step 6: Create and Embed an Application Manifest" in the downloadable Help File.

Note   The User Account Control: Detect application installations and prompt for elevation setting must be enabled for installer detection to detect installation programs. This setting is enabled by default and can be configured using the Security Policy Manager snap-in (

secpol.msc

) or with Group Policy (

gpedit.msc

).

General information and an overview of the Microsoft Windows Installer can be found at MSDN (https://go.microsoft.com/fwlink/?LinkId=30197).

Patching Applications in a UAC Environment

Microsoft Windows Installer version 4.0 was designed with UAC in mind to make application installations and patching easier. With the introduction of Windows Installer 4.0, patches can be applied to applications without reinstalling a newer version of the application. This method is ideal when an application is deployed in a per-computer install and patches need to be deployed by a user without requiring an administrator access token. For information about how to create and apply patches to applications, see MSDN (https://go.microsoft.com/fwlink/?LinkId=71492).

Security Center Integration

When UAC is disabled on a Windows Vista computer, the Security Center creates an alert and prompts the user to re-enable UAC. Security Center displays this alert once the computer has been restarted after the UAC setting change.

User Interface Privilege Isolation

User Interface Privilege Isolation (UIPI) is one of the mechanisms that helps isolate processes running as a full administrator from processes running as an account lower than an administrator on the same interactive desktop. UIPI is specific to the windowing and graphics subsystem, known as USER, that supports windows and user interface controls. UIPI prevents a lower privilege application from using Windows messages to send input from one process to a higher privilege process. Sending input from one process to another allows a process to inject input into another process without the user providing keyboard or mouse actions.

Windows Vista implements UIPI by defining a set of user interface privilege levels in a hierarchical fashion. The nature of the levels is such that higher privilege levels can send window messages to applications running at lower levels. However, lower levels cannot send window messages to application windows running at higher levels.

The user interface privilege level is at the process level. When a process is initialized, the User subsystem calls into the security subsystem to determine the desktop integrity level assigned in the process security access token. The desktop integrity level is set by the security subsystem when the process is created and does not change. Therefore, the user interface privilege level is also set by the User subsystem when the process is created and does not change.

All applications run by a standard user have the same user interface privilege level. UIPI does not interfere or change the behavior of window messaging between applications at the same privilege level. UIPI comes into effect for a user who is a member of the administrators group and may be running applications as a standard user (sometimes referred to as a process with a filtered access token) and also processes running with a full administrator access token on the same desktop. UIPI prevents lower privilege processes from accessing higher privilege processes by blocking the behavior listed below.

A lower privilege process cannot:

• Perform a window handle validation of higher process privilege.
• SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.
• Use thread hooks to attach to a higher privilege process.
• Use Journal hooks to monitor a higher privilege process.
• Perform DLL injection to a higher privilege process.

With UIPI enabled, the following shared USER resources are still shared between processes at different privilege levels:

• Desktop window, which actually owns the screen surface.
• Desktop heap read-only shared memory.
• Global atom table.
• Clipboard

Painting to the screen is another action that is not blocked by UIPI. Painting to the screen refers to the process of using the Paint method to display content on an external output—a monitor, for example. The USER/graphics device interface (GDI) model does not allow control over painting surfaces; therefore, it is possible for a lower privilege application to paint over the surface region of a higher privilege application window.

Note   Because the Windows Shell (the Explorer.exe process) is running as a standard user process, any other process running as standard user can still send the Windows Shell keystrokes. This is the primary reason an administrator account in Admin Approval Mode is prompted for elevation consent when the user initiates an administrative action, such as double-clicking on a setup file or clicking on a button marked with an elevation shield icon.

Virtualization

Important   Virtualization is implemented to improve application compatibility problems for applications running as a standard user on Windows Vista. Developers must not rely on virtualization being present in subsequent versions of Windows.

For detailed information about "Virtualization" see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

User Account Control Architecture

The following diagram represents the process flow for executable launches in Windows Vista.

Figure 1. UAC architecture

The following describes the process flow displayed in the UAC architecture diagram and how UAC is implemented when an executable attempts to launch.

Standard User Launch Path

The Windows Vista standard user launch path is similar to the Windows XP launch path, but includes some modifications.

1. ShellExecute() calls CreateProcess().
2. CreateProcess() calls AppCompat, Fusion, and Installer Detection to assess if the application requires elevation. The executable is then inspected to determine its requestedExecutionLevel, which is stored in the executables application manifest. The AppCompat database stores information for an applications application compatibility fix entries. Installer Detection detects setup executables.
3. CreateProcess() returns a Win32 error code stating ERROR_ELEVATION_REQUIRED.
4. ShellExecute() looks specifically for this new error and, upon receiving it, calls across to the Application Information service (AIS) to attempt the elevated launch.

Elevated Launch Path

The Windows Vista elevated launch path is a new Windows launch path.

1. AIS receives the call from ShellExecute() and reevaluates the requested execution level and Group Policy settings to determine if the elevation is allowed and to subsequently define the elevation user experience.
2. If the requested execution level requires elevation, AIS launches the elevation prompt on the callers interactive desktop (based on Group Policy), using the HWND passed in from ShellExecute().
3. Once the user has given consent or valid administrator credentials, AIS will retrieve the corresponding access token associated with the appropriate user, if necessary. For example, an application requesting a requestedExecutionLevel of highestAvailable will retrieve different access tokens for a user that is only a member of the Backup Operators group than for a member of the local Administrators group.

AIS reissues a CreateProcessAsUser() call, supplying the administrator access token and specifying the callers interactive desktop.

Will UAC Affect Your Application?

Whether or not your application will be affected by UAC depends on the applications current state. In a number of cases, no changes will be necessary to comply with Microsoft Windows® Security requirements. However, some applications, including line of business (LOB) applications, may require changes to their install, function, and update processes to properly work in a Windows Vista UAC environment.

For detailed information about "Will UAC Affect your Application?" see the Windows Help file, which can be downloaded here. To find this article in the Help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Designing Applications for Windows Vista

The following list represents a workflow for designing applications for Windows Vista.

Windows Vista application design workflow

Workflow	Description
Step One: Test Your Application for Application Compatibility.	Test your application for Windows Vista application compatibility. This testing can be easily performed by installing the Standard User Analyzer.
Step Two: Classify Your Application.	Classify your application as a standard user, administrator, or mixed user application. Administrative applications in Windows Vista often have a mixture of both administrative and standard user functionality.
Step Three: Redesign for UAC Compatibility.	Redesign your applications functionality for UAC compatibility. Use the information in this section, once you have classified your application and determined whether it must be redesigned for UAC.
Step Four: Redesign Your UI for UAC Compatibility.	Redesign your application user interface. Closely adhering to these guidelines in your applications development will ensure that your application will have a consistent and predictable user experience in Windows Vista.
Step Five: Redesign Your Installer.	Redesign your application installer. The best practices in this section are for well-behaved application installations in a Windows Vista or UAC environment.
Step Six: Create and Embed an Application Manifest.	Create and embed an application manifest with your administrative applications. The correct way to mark your applications is to embed an application manifest within your program that tells the operating system what the application needs.
Step Seven: Test Your Application.	Test your redesigned or new application for application compatibility using the Standard User Analyzer.
Step Eight: Authenticode Signature.	Sign the application with an Authenticode signature to prevent tampering with the executable.
Step Nine: Windows Vista Logo Program.	Participate in the Windows Vista Logo Program.

For detailed information about "Designing Applications for Windows Vista" see the Windows Help file, which can be downloaded here. To find this article in the Help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Impact of UAC on the Windows User Experience

The biggest and most immediate impact on the user experience will be felt by administrators. Administrator users will now need to provide permission to accomplish administrative tasks. Coupled with that, standard users will now gain the ability to perform administrative tasks within the currently logged in session by providing valid administrator credentials.

Goals of the UAC User Experience

The overall goal for UAC user experience is to provide predictability.

• For an administrator, this means that the user always know when he/she will need to give permission to run an elevated task.

This is the act of requesting the user's own administrator access token so that he/she can make administrator-required changes.

• For standard users, this means that they will know when they:
  • Will need to provide administrator credentials (home and unmanaged environments) for administrative tasks.
  • OR when they cannot complete a task (managed environments where elevation is explicitly disallowed) and must contact the help desk.

Elevation Prompt

The elevation prompt is built upon an existing Windows user interface. The elevation prompt displays contextual information about the executable requesting elevation, and the context is different depending on whether the application is Authenticode signed. The elevation prompt is seen in two variations: the consent prompt and the credential prompt.

Consent Prompt

The consent prompt is displayed to administrators in Admin Approval Mode when they attempt to perform an administrative task. This is the default user experience for administrators in Admin Approval Mode and can be configured in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy.

The following illustration is an example of a User Account Control consent prompt.

Figure 2. User Account Control consent prompt

Credential Prompt

The credential prompt is displayed to standard users when they attempt to perform an administrative task. This is the default user experience for standard users and can be configured in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy.

The following illustration is an example of a User Account Control credential prompt.

Figure 3. User Account Control credential prompt

Deploying and Patching Applications for Standard Users

This section discusses how to ensure that your application can be deployed for standard users. For detailed information about "Deploying and Patching Applications for Standard Users," see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Troubleshooting Common Issues

This section lists common development and installation issues that arise in Microsoft .NET applications. For detailed information about "Troubleshooting Common Issues," see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

References

This section includes a virtualization reference and a security settings reference. For detailed information about "Virtualization Reference," see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Conclusion

With User Account Control (UAC), Microsoft has provided a technology designed to simplify deploying standard user desktops in the enterprise and at home.

Building off the Windows security architecture, the UAC team sought to implement a standard user model that is both flexible and more secure.