Understanding and Configuring User Account Control in Windows Vista

Enterprises today face a daunting task of enforcing desktop standardization. This challenge is intensified since the majority of users run as local administrators on their computers. As a local administrator, a user can install and uninstall applications and adjust system and security settings at will. As a result, IT departments often cannot gauge the holistic health and security of their environments. In addition, every application that these users launch can potentially use their accounts’ administrative-level access to write to system files and the registry and to modify system-wide data. Common tasks like browsing the Web and checking e-mail can become unsafe in this scenario. In addition, all of these elements increase an organization’s total cost of ownership (TCO).

IT departments must be given a solution that is both resilient to attack and protective of data confidentiality, integrity, and availability. For this reason, the Windows Vista® development team chose to redesign the way that the Windows core security infrastructure and applications interact. User Account Control (UAC) was the outcome of this redesign process.

Why UAC?

A History of the Windows Administrator Account

By default, when Microsoft Windows® XP is initially installed, the Windows XP Setup Wizard creates all user accounts as local administrators. This account type enables users to install, update, and run software since an administrator account has system-wide access. When a user is added to the local administrators group, that user is automatically granted every Windows privilege. A privilege is an authorization attribute that affects computer-wide policies. For example, SeBackupPrivilege allows a user to backup files and directories. Privileges should not be confused with permissions, though; permissions apply to objects while privileges apply only to user accounts. These privileges are collected and maintained in a user’s access token. The access token also contains user specific data for authorization purposes; Windows uses access tokens to track what resources a user can access. Every Windows resource has an Access Control List (ACL), which is a list that records which users and services have permission to access the resource and what level of permission they have. Windows' authorization model uses the data contained within a user's access token to determine what access the user is permitted/denied in a resource's ACL.

Administrative users automatically have:

• Read/Write/Execute permissions to all resources
• All Windows privileges

While it may seem clear that all users should not be able to read, alter, and delete any Windows resource, many enterprise IT departments have no other option but to make all of their users administrators.

The following are some reasons why enterprises run as administrator today:

• Application installation (members of the Users group cannot install or uninstall applications): Many enterprises have no centralized method for deploying applications to their users, such as Microsoft Systems Management Server® (SMS), Group Policy software installation (GPSI), or another similar application deployment technology. Enterprises that do utilize software deployment technologies allow users to run as administrator because of ad hoc application installations for specialized applications for specific departments (a custom spreadsheet application for the Marketing department, for instance).
• Custom Web applications (ActiveX controls): With the growth of the independent software vendor (ISV) community, many companies are opting to have custom applications designed for their specific business requirements. Many of these custom applications include a Web browser front-end, which requires an ActiveX control to be installed. Because ActiveX controls are executable files and can contain malware, Windows prevents members of the Users group from installing them.
• Perceived lower TCO (reduced help desk calls versus reduced attack surface): Many enterprises believe that allowing users to install their own applications will help limit the number and cost of Help Desk calls. Unfortunately, running your enterprise workstations as administrator also makes your network vulnerable to “malware”—the overarching term for all malicious software, including viruses, Trojan horses, spyware, and some adware. Malware can exploit a local administrator account’s system-level access to damage files, change system configurations, and even transmit confidential data outside of the network.

Ensuring that all users run as standard users is the primary way to help mitigate the impact of malware. A standard user account is a user account that has the least amount of user rights and privileges required to perform basic desktop tasks. However, while a standard user account does exist by default in Windows XP, many routine tasks, including changing the Windows time zone and installing a printer, require that a user have administrative privileges. Many applications also require users to be administrators by default, as they check group administrator group membership before running. No user security model existed for Windows 95 and Windows 98. As a result, application developers designed their applications assuming that they would be installed and run as an administrator. A user security model was created for Windows NT, but all users were created as administrators by default. In addition, a standard user on a Windows XP computer must use Run as or log on with an administrator account in order to install applications and perform other administrative tasks.

Until the development of Windows Vista, there was no built-in method within the Windows operating system for a user to “elevate” in flow from a standard user account to an administrator account without logging off, switching users, or using Run as. As a result, most people continue to browse the Web and read e-mail as an administrator.

Reducing the Total Cost of Ownership

Because UAC enables users to easily run as standard users, IT departments can have more confidence in the integrity of their environments, including system files, audit logs, and system-wide settings. In addition, administrators no longer need to devote large blocks of time to authorizing tasks on individual computers. This saves the IT staff time that can be redirected to overall system maintenance, reducing an organization’s TCO for its enterprise software platform. Furthermore, IT administrators gain better control over software licensing because they can ensure that only authorized applications are installed. As a result, they will no longer have to worry about unlicensed or malicious software endangering their network, causing system downtime and data loss, or creating licensing liabilities.

How UAC Works

In response to the challenges customers encounter when attempting to run as a standard user, Microsoft began researching how to make running as a standard user easier for everyone.

The Windows Vista development team took a dual approach:

1. Work with Microsoft software developers and third-party software developers to eliminate unnecessary requests for excessive administrative-level access to Windows resources.
2. Fundamentally change the way applications run by standard users interact with the operating system by enabling access control security policy.

UAC is a significant focus of Windows Vista and a fundamental component of Microsoft’s overall security vision.

Refining User Modes

In Windows Vista, there are two types of user accounts: standard user accounts and administrator accounts. Standard users are equivalent to the standard user account in previous versions of Windows. Standard users have limited administrative privileges and user rights—they cannot install or uninstall applications that install into %systemroot%, change system settings, or perform other administrative tasks. However, standard users can perform these tasks if they are able to provide valid administrative credentials when prompted. With UAC enabled, members of the local Administrators group run with the same access token as standard users. Only when a member of the local Administrators group gives approval can a process use the administrator’s full access token. This process is the basis of the principle of Admin Approval Mode.

The following table details some of the tasks a standard user can perform and what tasks require elevation to an administrator account.

Standard Users	Administrators
Establish a Local Area Network connection	Install and uninstall applications
Establish and configure a wireless connection	Install a driver for a device (E.G. a digital camera driver)
Modify Display Settings	Install Windows updates
Users cannot defragment the hard drive, but a service does this on their behalf	Configure Parental Controls
Play CD/DVD media (configurable with Group Policy)	Install an ActiveX control
Burn CD/DVD media (configurable with Group Policy)	Open the Windows Firewall Control Panel
Change the desktop background for the current user	Change a user's account type
Open the Date and Time Control Panel and change the time zone	Modify UAC settings in the Security Policy Editor snap-in (secpol.msc)
Use Remote Desktop to connect to another computer	Configure Remote Desktop access
Change user's own account password	Add or remove a user account
Configure battery power options	Copy or move files into the Program Files or Windows directory
Configure Accessibility options	Schedule Automated Tasks
Restore user's backed-up files	Restore system backed-up files
Set-up computer synchronization with a mobile device (smart phone, laptop, or PDA)	Configure Automatic Updates
Connect and configure a Bluetooth device	Browse to another user's directory

Migrating from the Power Users Group

The Power Users group in Windows XP was designed to enable members of the group to perform system tasks, such as installing applications without granting full administrator permissions. Power Users also had write access to areas of the file system and registry that normally only allow administrator access. Power Users enabled some level of application compatibility; unfortunately, this did not address a fundamental problem: applications requiring unnecessary privileges and user rights. UAC does not leverage the Power Users group, and the permissions granted to the Power Users group on Windows XP have been removed from Windows Vista. UAC enables standard users to perform all common configuration tasks. The Power Users group, however, is still available for backwards compatibility with other versions of Windows. To use the Power Users group on Windows Vista, a new security template must be applied to change the default permissions on system folders and the registry to grant Power Users group permissions equivalent to Windows XP.

Admin Approval Mode

Enabling Admin Approval Mode for an administrator account makes it safer for a user to perform administrative tasks by making a distinction between a standard user task and an administrative task. For example, modifying the system registry should always be an administrative task browsing the Internet should always be a standard user task. The UAC access token model makes this distinction even clearer. An administrator account in Admin Approval Mode is prompted for consent by the application or component that is requesting permission to use the user’s full administrative access token.

UAC Architecture

While the Windows Vista logon process externally appears to be the same as the logon process in Windows XP, the internal mechanics have greatly changed. The following illustration details how the logon process for an administrator differs from the logon process for a standard user.

When an administrator logs on, the user is granted two access tokens: a full administrator access token and a "filtered" standard user access token. By default, when a member of the local Administrators group logs on, the administrative Windows privileges are disabled and elevated user rights are removed, resulting in the standard user access token. The standard user access token is then used to launch the desktop (Explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all applications run as a standard user by default unless a user provides consent or credentials to approve an application to use a full administrative access token. Contrasting with this process, when a standard user logs on, only a standard user access token is created. This standard user access token is then used to launch the desktop.

A user that is a member of the Administrators group can now log in, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows Vista automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured in the Security Policy Editor (secpol.msc) snap-in and with Group Policy. For information about how to adjust UAC Group Policy settings, see the "Configuring UAC Settings" section within this document.

Each application that requires the administrator’s access token must prompt the administrator for consent. The one exception is the relationship that exists between parent and child processes. Child processes will inherit the user’s access token from their parents. Both the parent and child processes, however, must have the same integrity level.

Windows Vista protects processes by marking them with integrity levels. Integrity levels are measurements of trust. A “high” integrity application is one that performs tasks that modify system data, such as a disk partitioning application, while a “low” integrity application is one that performs tasks that could potentially compromise the operating system, such as a Web browser. Windows Vista prevents applications with lower integrity levels from modifying data in applications with higher integrity levels.

When a standard user attempts to run an application that requires an administrator access token, UAC requires that the user provide valid administrator credentials. The "UAC User Experience" section in this document details this process.

The following diagram details the UAC architecture.

Application Information Service

The Application Information Service (AIS) is a SYSTEM service that facilitates launching applications that require one or more elevated privileges or user rights to run, such as Administrative Tasks, as well as applications that require higher integrity levels. AIS facilitates launching such applications by creating a new process for the application with an administrative user’s full access token when elevation is required and (depending on Group Policy) consent is given by the user to do so. This is a new service for Windows Vista.

Virtualization

Because the enterprise environment has long been a place where system administrators have been attempting to lock down systems, many line-of-business (LOB) applications are designed to not require a full administrator access token. As a result, IT administrators will not need to replace the majority of pre-Windows Vista applications when running Windows Vista with UAC enabled.

Windows Vista includes file and registry virtualization technology for applications that are not UAC compliant and that have historically required an administrator's access token to run correctly. Virtualization ensures that even applications that are not UAC compliant will be compatible with Windows Vista. When a non-UAC-compliant administrative application 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, using a copy-on-write strategy. The virtualized copy is maintained under the user's profile. As a result, a separate copy of the virtualized file is created for each user that runs the non-compliant application.

The virtualization technology ensures that non-compliant applications will not silently fail to run or fail in a non-deterministic way. UAC also provides file and registry virtualization and logging by default for pre-Windows Vista applications that write to protected areas.

Most application tasks will operate properly using virtualization features. Although virtualization allows the overwhelming majority of pre-Windows Vista applications to run, it is a short-term fix and not a long-term solution. Application developers should modify their applications to be compliant with the Windows Vista Logo program as soon as possible, rather than relying on file, folder, and registry virtualization.

Guidance about how ISVs can design their applications to be UAC compliant is available in the Windows Vista Development Requirements for User Account Control Compatibility document.

Requested Execution Levels

In Windows Vista, the application manifest, an XML file that describes and identifies the shared and private side-by-side assemblies that an application should bind to at run time, now includes entries for UAC application compatibility purposes. Administrative applications that include an entry in the application manifest will prompt the user for permission to access the user’s access token. Most pre-Windows Vista administrative applications, however, can run smoothly without modification even though they lack an entry in the application manifest by using application compatibility fixes. Application compatibility fixes are database entries that enable applications that are not UAC compliant to work properly with Windows Vista.

All UAC compliant applications should have a requested execution level added to the application manifest. If the application requires administrative access to the system, then marking the application with a requested execution level of “require administrator” will ensure that the system will identify this program as an administrative application and will perform the necessary elevation steps. Requested execution levels allow the system know the specific privileges required for an application. If an existing application requires administrative access in order to run correctly on Windows Vista, see the "Configuring Pre-Windows Vista Applications for Compatibility" with UAC section within this document.

Installer Detection Technology

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 an administrator user, which means that standard users do not have sufficient access to install programs. Windows Vista heuristically detects installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows Vista also heuristically detects updater and uninstallation programs. Note that a design goal of UAC is to prevent installations from being executed without the user's knowledge and consent since they write to protected areas of the file system and registry.

Installer Detection only applies to:

1. 32 bit executables

2. Applications without a requestedExecutionLevel

3. Interactive processes running as a Standard User with LUA enabled

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

• Filename includes keywords like "install," "setup," "update," etc.
• 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 manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the RC data linked in the executable.
• Targeted sequences of bytes within the executable.

Ensure that you thoroughly review the entirety of this document, including the "Step Five: Create and Embed an Application Manifest with Your Application" section.

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

Core Changes in Functionality

The following updates are reflective of the cumulative core changes in functionality that have occurred in Windows Vista.

UAC is Enabled by Default

As a result, you might encounter some compatibility problems with different applications that have not yet been updated for the Windows Vista UAC component. If an application requires an administrator access token (this is indicative from an "access denied" error being returned when you attempt to run the application), you can run the program as an administrator by using the Run as administrator option on the context menu (right-click). How to do this is documented later in this document in the "Running Programs as an Administrator" section.

All Subsequent User Accounts are Created as Standard Users

Both standard user accounts and administrator user accounts can take advantage of the UAC enhanced security. On new installations, by default, the first user account created is a local administrator account in Admin Approval Mode (UAC enabled). All subsequent accounts are then created as standard users.

Built-in Administrator Account is Disabled by Default on New Installations

The built-in Administrator account is disabled by default in Windows Vista. If Windows Vista determines during an upgrade from Windows XP that the built-in Administrator is the only active local administrator account, Windows Vista leaves the account enabled and places the account in Admin Approval Mode. The built-in Administrator account, by default, cannot log on to the computer in safe mode. Please see the following sections for more information.

Non-Domain Joined

When there is at least one enabled local administrator account, safe mode will not allow logon with the disabled built-in Administrator account. Instead, any local administrator account can be used to logon. If the last local administrator account is inadvertently demoted, disabled or deleted, safe mode will allow the disabled built-in Administrator account to logon for disaster recovery.

Domain Joined

The disabled built-in Administrator account in all cases cannot logon in safe mode. A user account that is a member of the Domain Admins group can log on to the computer to create a local administrator if none exists.

Elevation Prompts are Displayed on the Secure Desktop by Default

The consent and credential prompts are displayed on the secure desktop by default in Windows Vista.

New UAC Security Settings and Security Setting Name Changes

The "Configuring UAC Settings" section of this document details the UAC security policies.

Standard User Analyzer

To test for application compatibility with UAC, IT administrators and application developers can use the Standard User Analyzer. This tool produces a log of an application’s elevated operations that would normally fail when run as a standard user – providing a roadmap for adjusting these tasks and achieving UAC compliance. In addition, the Windows Vista audit process tracking setting can be used to determine which applications are not running as a standard user in an enterprise environment. To ensure the Windows user experience is not diminished by UAC, Microsoft recommends testing all components and applications with these tools. The Configuring Pre-Windows Vista Applications for Compatibility with UAC of this document provides more information about these tools, including configuration information and procedures.

UAC User Experience

The user experience differs for standard users and administrators in Admin Approval Mode when UAC is enabled. The following sections detail those differences and explain the design of the UAC user interface.

The recommended, more secure method of running Windows Vista to make your primary user account a standard user account. Running as a standard user is also a requirement to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account. The default, built-in UAC elevation component for standard users is called the credential prompt.

The alternative to running as a standard user is to run as an administrator in Admin Approval Mode. With the built-in UAC elevation component, members of the local Administrators group can easily perform an administrative task by providing approval. The default, built-in UAC elevation component for an administrator account in Admin Approval Mode is called the consent prompt. The UAC elevation prompting behavior is configurable with the local Security Policy Editor snap-in (secpol.msc) and with Group Policy. The "Administering UAC with the local Security Policy Editor and Group Policy" section of this document details UAC security settings and their values.

The Consent and Credential Prompts

With UAC enabled, Windows Vista either prompts for consent or for credentials for a valid administrator account before launching a program or task that requires a full administrator access token. This prompt ensures that no malicious application can silently install.

The Consent Prompt

The consent prompt is presented when a user attempts to perform a task that requires a user's administrative access token. The following is a screenshot of the User Account Control consent prompt.

The following example shows how the consent before performing an administrative operation occurs.

To view the consent prompt

1. Log on to a Windows Vista computer with an administrator account in Admin Approval Mode.

2. Click the Start button, right-click My Computer, and then select Manage from the menu.

3. At the User Account Control consent prompt, click Continue.

The Credential Prompt

The credential prompt is presented when a standard user attempts to perform a task that requires a user's administrative access token. This standard user default prompt behavior is configurable with the Security Policy Manager snap-in (secpol.msc) and with Group Policy. Administrators can also be required to provide their credentials by setting the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode value to Prompt for credentials.

The following screenshot is an example of the User Account Control credential prompt.

The following example illustrates how a standard user is prompted for credentials when attempting to perform an administrative task.

To view the credential prompt

1. Log on to a Windows Vista computer with a standard user account.

2. Click the Start button, right-click My Computer, and then select Manage from the menu.

3. At the User Account Control credential prompt, click the user name for the appropriate administrator, enter the password for that user account, and then click Submit.

Application Aware Elevation Prompts

The UAC elevation prompts are color-coded to be application-specific, enabling for immediate identification of an application's potential security risk. When an application attempts to run with an administrator's full access token, Windows Vista first analyzes the executable to determine its publisher. Applications are first separated into three categories based on the executable's publisher: Windows Vista, publisher verified (signed), and publisher not verified (unsigned). The following diagram illustrates how Windows Vista determines which color elevation prompt to present to the user. The following illustration details the elevation prompt logic for corresponding levels of trust.

The following details the elevation prompt color-coding:

• Red background and red shield icon: The application is from a blocked publisher or is blocked by Group Policy.
• Blue/green background: The application is a Windows Vista administrative application, such as a control panel.
• Gray background and gold shield icon: The application is Authenticode signed and trusted by the local computer.
• Yellow background and red shield icon: The application is unsigned or signed but not yet trusted by the local computer.

The color-coded elevation prompts align with the color-coded dialog boxes in Microsoft Internet Explorer.

Shield Icon

Some control panels, such as the Date and Time Properties control panel, contain a mix of administrator and standard user operations. Standard users can view the clock and change the time zone, but a full administrator access token is required to change the local system time. The following image is a screenshot of the Date and Time Properties Control Panel.

When a user needs to modify the time, the user clicks the Shield icon button. The Shield icon indicates to the system to launch the process with a full administrator access token, which requires a User Account Control elevation prompt.

Securing the Elevation Prompt

The elevation process is further secured by directing the prompt to the secure desktop. The consent and credential prompts are displayed on the secure desktop by default in Windows Vista. Only Windows processes can access the secure desktop. In addition to the recommendations for administrators and standard users, Microsoft also strongly recommends that the User Account Control: Switch to the secure desktop when prompting for elevation setting should be kept enabled for higher levels of security.

When an executable requests elevation, the interactive desktop (also called the user desktop) is switched to the secure desktop. The secure desktop renders an alpha-blended bitmap of the user desktop and displays a highlighted elevation prompt and corresponding calling application window. When the user clicks Continue or Cancel, the desktop switches back to the user desktop.

It is worthwhile to note that malware can paint over the interactive desktop and present an imitation of the secure desktop, but when the setting is set to prompt for approval the malware does not gain elevation should the user be tricked into clicking Continue on the imitation. If the setting is set to prompt for credentials, malware imitating the credential prompt may be able to gather the credentials from the user. Note that this does also does not gain malware elevated privilege and that the system has other protections that mitigate malware from automated driving of user interface even with a harvested password.

This setting is enabled by default in Windows Vista and can be configured with the local Security Policy Editor snap-in (secpol.msc) or centrally with Group Policy. The "Administering UAC with the local Security Policy Editor and Group Policy" section of this document details the available settings and configurations.

Maintaining Pre-Windows Vista Applications

Some applications, however, will not be redesigned for a variety of reasons. UAC has built-in protections in for such pre-Windows Vista applications, including requested execution levels and file, folder, and registry virtualization.

Developing UAC Compliant Applications for Windows Vista

While the concept of running applications with the least privileges and user rights required has been widely accepted within the software development community, it has often been overlooked by application vendors who choose to instead concentrate on simplifying the use of software or on refining the user interface.

Many application developers will be required to change their applications so that they will work properly with UAC. Applications that unnecessarily require administrative rights should be redesigned to be UAC-compliant. This redesign will enable standard users to run many applications on Windows Vista that they are unable to run on Windows today.

Microsoft has provided guidance and tools for application developers to help facilitate this redesign process. For more information, please see the Application Compatibility page on MSDN (https://go.microsoft.com/fwlink/?LinkId=49973).

Even with these changes, there will still be tasks that require a full administrator access token. Some examples include managing user accounts, installing device drivers, and running enterprise management software. With Windows Vista, application developers will need to determine which of the two levels of access (standard or administrative) their application needs for specific tasks. If an application does not need a full administrator access token for a task, then it should be written to require only standard user access checks. For example, a UAC-compliant application should write data files to the user’s profile, as opposed to the Program Files directory tree.

Windows Vista Logo Program

The Windows Vista Logo Program will be a major benefit of creating UAC-compliant applications. The program will enforce strict certification guidelines, providing assurance to customers that certified products will integrate properly with Windows Vista.

The Windows Vista Logo certification provides a competitive differentiator and credibility for Independent Software Vendors (ISVs). Customers will know when they purchase certified applications that they are fully compatible with Windows Vista and that the ISV is dedicated to the integrity and security of their customers’ data. Microsoft is currently building beta tools to handle the workflow for ISVs generating and signing manifests. The Logo Certificate will ship in-the-box, displaying the certification prominently. More information about the Windows Vista Logo certification process is available at the Microsoft Windows Logo home page.

Deploying Applications for Standard Users

One of the most challenging tasks for enterprises is controlling application installation. Deployment tools like Microsoft Systems Management Server (SMS) help IT departments centralize application deployment and reduce the overall TCO for the enterprise. With the introduction of UAC user model in Windows Vista, SMS have an even greater impact on the TCO and ease of manageability.

Maximizing the Security of Application Deployment

IT departments can use the following three levels of security to help model their application deployment scenario:

• High: All applications are packaged and deployed using SMS, GPSI, or another similar application deployment technology.
• Medium: Applications are installed on a case-by-case basis by the IT department.
• Low: Standard users can install applications at will.

The following are scenarios for the previous three levels of security.

High: All applications are deployed using SMS, GPSI, or Another Similar Application Deployment Technology

In this scenario, all applications, operating systems, and security patches are installed using an application deployment technology. The benefits of using technologies like SMS and GPSI in this instance include:

• Ease of administration: By administering applications centrally, an IT department can easily maintain a list of installed applications and prevent unwanted applications from being installed.
• Fewer malware installs: Because malware is often “bundled” with legitimate software, removing the ability for users to install such software will help prevent many malware installations.
• Overall lower TCO: Fewer malware installs and limitation of malware to per-user locations.

Requirements for this level of security include:

• Microsoft SMS 4.0 is installed on a dedicated server (if using SMS as the application deployment technology. If not, modify this requirement with the chosen technology).
• All users have standard user accounts and log into their computers with the standard user account.
• Domain administrators have two accounts—a standard user account and a domain administrator account with UAC enabled.
• The User Account Control: Run all administrators in Admin Approval Mode setting is enabled and administered centrally using Group Policy.
• The User Account Control: Switch to the secure desktop when prompting for elevation setting is enabled and is administered centrally using Group Policy.
• The User Account Control: Behavior of the elevation prompt for standard users setting is configured as Prompt for credentials and is administered centrally using Group Policy.

Benefits: There are several benefits of implementing UAC in this manner. By centrally administering the UAC security settings with Group Policy, the IT department can ensure that local computer policy cannot be changed to circumvent the department's policy. Because users log on to their computers as standard users and do not know the user name or password for a local administrator account, they cannot modify system settings, install software and malware, and unintentionally or intentionally tamper with the machine. Although users are all standard users, they can still install and update applications with SMS. The specific benefits of SMS software deployment were previously discussed in this section.

Medium: Applications are installed on a case-by-case basis by the IT department

While this level has a “medium” security level, it is the most difficult to manage. In this scenario, all users would have to submit a request to the helpdesk each time they wanted to install an application. The helpdesk would then have to either use Remote Desktop to install the application or physically input the credentials at the user’s computer. While the IT department, in theory, should know what applications are installed on which computer, the process of tracking this can be cumbersome and difficult to manage. In addition, if the credentials for a local administrator account are disclosed to a standard user even once, it must be assumed that the security policy is then compromised.

Low: Users can Install Applications at Will

In this scenario, there are three possible configurations. The following configurations are presented in decreasing levels of security, with the first being the most secure:

1. Users are standard users but know the user name and password for a local administrator.
   1. The User Account Control: Run all administrators in Admin Approval Mode setting is enabled.
   2. Users log in with their standard user accounts and provide credentials for a local administrator account in the User Account Control credential prompt when they want to perform administrative tasks.
   3. Impact: There is no efficient way for the IT department to track application installations or to track a computer's health index. Additionally, users can still inadvertently install malware by providing credentials on a User Account Control credential prompt for an executable that they cannot identify.
2. Users are local administrators.
   1. The User Account Control: Run all administrators in Admin Approval Mode setting is enabled.
   2. Users log in with their administrator accounts and provide consent for the User Account Control consent prompt when they want to perform administrative tasks.
   3. Impact: Although UAC is enabled, because all users log on as administrators, any user can easily install software, manipulate system settings, and circumvent the computer's security policy. Additionally, there is no efficient way for the IT department to track application installations or to track a computer's health index.
3. UAC is disabled and users are local administrators.
   1. The User Account Control: Run all administrators in Admin Approval Mode setting is disabled.
   2. Users log in with their administrator accounts and perform administrative tasks.
   3. Impact: When UAC is disabled, users are not notified when administrative applications attempt to use their administrative access token. As a result, there is no efficient way for the IT department to track application installations or to track a computer's health index. In addition, malware can silently install because users are not prompted for approval or credentials before an administrative executable can run.

Testing Applications for the Standard User

In order for more applications to be more standard user compatible, application developers must ensure that they test their applications as standard users. Guidance about testing for Windows Vista compliant applications is available in the Windows Vista Development Requirements for User Account Control Compatibility document.

Repackaging Applications

Windows Installer 4.0 was designed to be fully UAC aware and compliant. Systems Administrators that require application customization and repackaging for their IT environments can use the FLEXnet AdminStudio 7 SMS Edition to repackage software with Windows Installer for SMS deployment. FLEXnet AdminStudio 7 SMS Edition provides businesses with the ability to prepare, publish, and distribute software packages using SMS 2003 without ever touching the SMS server console, significantly improving the efficiency of application management efforts.

The FLEXnet AdminStudio 7 SMS Edition provides a wizard-based repackager component that makes it easy to convert any setup—even difficult-to-package InstallScript Windows Installer setups—into 100 percent Windows Installer packages. The repackager includes: InstallMonitor for snapshot-free repackaging, SmartScan for extracting the maximum information from InstallScript setups during conversion to Windows Installers, Setup Intent for helping to ensure Windows Installers do not miss important files, and the Packaging Process Assistant for pointing you to the correct packaging process.

The FLEXnet AdminStudio 7 SMS Edition is a free download from the SMS site (https://go.microsoft.com/fwlink/?LinkId=71355).

The following resources provide additional information about software repacking:

• Repackaging Wizard in SMS (https://go.microsoft.com/fwlink/?LinkId=71350)
• Windows 2000 Server Repackaging Guide (https://go.microsoft.com/fwlink/?LinkId=71352)
• Windows 2000 Server Step by Step Guide to Repackaging (https://go.microsoft.com/fwlink/?LinkId=71353)
• Partners for Repackaging for Application Compatibility (https://go.microsoft.com/fwlink/?LinkId=71354)

UAC Deployment Scenario

In this section, we will explore one UAC deployment scenario for the company Litware, Inc, a medium-sized organization. The following scenario is intended to help IT departments scope potential issues that may arise from running in a Windows Vista environment with UAC enabled.

Litware, Inc (Medium Organization)

After installing Windows Vista on a computer at the Litware, Inc main office, a user logins in as an administrator in Admin Approval Mode and navigates to a shared folder where the department’s specific line-of-business (LOB) applications are kept. This share has a folder for each application and the software utilizes many different technologies to install applications, including Windows Installer, bootstrapper.exe, and an xcopy type installer.

Litware, Inc. has 2,500 Windows XP desktops and has decided to upgrade to Windows Vista in order to take advantage of UAC. The IT department must find a way to install the company's various LOB applications as a standard, but they have identified the following problems:

• No one in the IT department has experience with Group Policy software installation (GPSI) or Microsoft Systems Management Server (SMS). As a result, the company will have to invest in training for one person on staff.
• Converting the LOB applications to install with Windows Installer could become costly because there are no tools to assist with the process. For example: “We can package them all up but we can’t set the install settings easily.”
• The IT department has developed some logon scripts to perform application installations and does not want to abandon the time, resources, and effort invested in their creation.

Administrator in Admin Approval Mode Solutions

This problem is not unique to Windows Vista. Enterprises have been working toward installing applications as standard users for quite some time with varying degrees of success. The following solutions are presented in increasing levels of preference: good, better, and best solutions.

Good

Allow the users to install from the existing share and rely on heuristic installer detection to identify the LOB applications as installers and to then invoke the elevated requested execution level. Because silent elevation is turned off, users will not see a consent prompt or credential prompt but will instead be silently running with the full administrator access token when they run applications from those shares.

For more information about heuristic installer detection in Windows Vista, see the "Installer Detection Technology" section within this document.

Unfortunately, there are limitations to this approach. There could be a number of cases where the Windows Vista installer detection identifies an application as an installer and automatically elevates the application. There are also some application compatibility concerns if the application was not designed to be installed in the Windows Vista environment.

Better

As a company invests more in locking down the corporate environment, one of the first things that an IT department will do is to catalog all of the applications that run on users’ computers. In this scenario, a member of the IT department has already consolidated these applications into a single location – a network share. Because of the consolidation of these applications, we can easily overcome the limitation mentioned in the previous section by explicitly marking the installers with a requested execution level to run as an administrator. Marking applications with requested execution levels involves adding entries to the application compatibility database for the applications. Applications can also be marked to run with a lower requested execution level if they are falsely being identified as installers.

A script could also be created to traverse the share and mark all of the applications with the RunAsAdmin application compatibility database levels. More guidance about marking applications with requested execution levels is provided in the "Marking Applications with Requested Execution Levels for Application Compatibility" section within this document.

The application database markings are associated with a Group Policy object (GPO) that is then deployed throughout the enterprise with Group Policy. After deploying this policy, every user in the enterprise will be guaranteed that the applications are consistently marked to run with the requested execution level that was explicitly specified.

Best

Now that the IT staff understands the various applications that users install, the department can begin to control those applications’ installation and prevent other applications from being installed. The first step is to turn off installer detection and create explicit requested execution level markings for each application that installs a product in the company. The simple assertion here is that the IT department now understands all of the applications that users will be installing, and since each are now marked with a requested execution level, installer detection is no longer necessary.

Because application installation is now more controlled, users no longer need to install from CDs or other external media – everything will be available on the network. To prevent users from installing applications that use a Windows Installer from external, removable media, you can perform the following procedure to set the Prevent removable media source for any install value in the Windows Installer Administrative Template file:

To prevent removable media sources for installations

1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.

2. In the Console pane, expand User Configuration, expand Administrative Templates, expand Windows Components, and select Windows Installer.

3. In the Details pane, right-click Prevent removable media source for any install and select Properties.

4. In Properties, select Enable, and then click OK.

Another benefit of the consolidation of the applications to a single network share is the ability to sign all of the binaries. After you have completed signing the binaries, you can provide your enterprise with an added layer of safety by enabling the User Account Control: Only elevate executables that are signed and validated setting.

In addition, Software Restriction Policies (SRP) can be added to prohibit unauthorized executables from running.

Standard User Solutions

The following solutions are presented in reverse order of preference: good, better, and best solutions.

Better

The IT department should assume that standard users will generally not be able to install any applications and that they will have a minimum set of user rights added to their access token. The users will no longer have the ability to run as an administrator and will instead need a service running as an administrator to alter the system state for them. Fortunately, Windows provides an installation service to do this: Windows Installer Server. There is also a Group Policy Software Installation Extension, which allows applications to be distributed to a user’s computer without any user interaction being required ruing the installation.

See the Group Policy Software Installation Extension documentation (https://go.microsoft.com/fwlink/?LinkId=71356) for more information.

Another option is to deploy the applications using a technology like SMS. The fundamental idea is the same – a standard user needs a backend service to do the tasks that the user does not have the privileges or user rights to do.

Guidance about how to deploy applications with SMS is available on TechNet (https://go.microsoft.com/fwlink/?LinkId=71357).

One of the challenges of using the GPSI extension is that the applications must be distributed in Windows Installers. In order to convert an application’s installer binaries into a Windows Installer you need to go through a process called “repackaging.” This includes determining the application specific settings for the application as well as understanding the proper execution order for the various events. There are tools that aid in this process, such as InstallShield’s DevStudio.

Repackaging applications is sometimes a daunting task and many enterprises have entire teams dedicated to it. More information about repacking applications is provided in the "Repackaging Applications" section within this document.

Best

This scenario alludes to the many considerations of software deployment. Typically, there is a core set of LOB applications that every enterprise user needs on his/her computer. This is an excellent set of software to target for enterprise wide deployment through either GPSI Publishing or Advertisement. In an enterprise where many computers are deployed, it would likely make sense to create an image library with these applications already installed.

The System Preparation Tool (sysprep.exe), which is distributed with Windows, allows you to produce an image for mass deployment. By using the System Preparation Tool, create an image that contains the entire core applications required and then deploy the image to all computers throughout the environment. This type of deployment circumvents the resource impacts of multiple, large installations over the network. Finally, use the organizational units (OUs) for each division to advertise the supplemental packages to the users with GPSI.

Configuring UAC settings

Now that you understand how UAC works and some potential issues that may arise during your Windows Vista deployment in your environment, we can move on to discussing how to configure UAC to optimize security and ease of use.

This section details two main methods for configuring UAC:

• Administering UAC with the local Security Policy Editor and Group Policy
• Auditing Application Elevations and Process Creation

Administering UAC with the local Security Policy Editor and Group Policy

Prior to Windows Vista, standard users working on a personal computer or in a network setting often had the option of installing applications. The key difference then was that, although administrators could create Group Policy settings to limit application installations, they did not have access to limit application installations for standard users as a default setting. In a UAC environment, they do, and administrators can still use Group Policy to define an approved list of devices and deployment.

There are nine Group Policy object (GPO) settings that can be configured for UAC. The following sections detail the different UAC GPO settings and provide recommendations.

User Account Control: Admin Approval Mode for the Built-in Administrator account

This setting determines whether UAC is applied to the default built-in Administrator account.

Configuration options:

• Enabled - The built-in Administrator will be run as an administrator in Admin Approval Mode.
• Disabled - The administrator runs with a full administrator access token.

Default value:

• Disabled for new installations and for upgrades where the built-in Administrator is NOT the only local active administrator on the computer.
• Enabled for upgrades when Windows Vista determines that the built-in Administrator account is the only active local administrator on the computer. If Windows Vista determines this, the built-in Administrator account is also kept enabled following the upgrade.

Recommendation: In an enterprise, we recommend that you configure this setting to Disabled since domain administrators will still have administrative access to the computer.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

This setting defines how UAC prompts administrators to elevate.

Configuration options:

• No prompt – The elevation occurs automatically and silently. This option allows an administrator in Admin Approval Mode to perform an operation that requires elevation without consent or credentials. Note: this scenario should only be used in the most constrained environments and is NOT recommended.
• Prompt for consent – An operation that requires a full administrator access token will prompt the administrator in Admin Approval Mode to select either Continue or Cancel. If the administrator clicks Continue, the operation will continue with their highest available privilege.
• Prompt for credentials – An operation that requires a full administrator access token will prompt an administrator in Admin Approval Mode to enter an administrator user name and password. If the user enters valid credentials, the operation will continue with the applicable privilege.

Default value: Prompt for consent

Recommendation: We recommend that you set this value to Prompt for consent since there is a possibility that an attacker could imitate (spoof) the elevation prompt. If the elevation prompt is spoofed and the administrator provides consent by clicking Continue, the attacker will only be able to elevate the single process. However, if the elevation prompt is spoofed when the setting is configured to Prompt for credentials, the attacker could gain access to the administrator's user name and password.

User Account Control: Behavior of the elevation prompt for standard users

This setting defines how and whether UAC prompts standard users to elevate.

Configuration options:

• No prompt – No elevation prompt is presented and the user cannot perform administrative tasks without using Run as administrator or by logging on with an administrator account.
• Prompt for credentials – An operation that requires a full administrator access token will prompt the user to enter an administrative user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.

Default value: Prompt for credentials

Recommendation: For an enterprise that is currently using standard user desktops, we recommend that you configure this setting as No prompt. Using this setting can help reduce support calls to your help desk.

User Account Control: Detect application installations and prompt for elevation

This setting controls whether Windows Vista uses heurists to identify installation applications. When a user runs an installer, Windows identifies the program as installation application and presents the user with an elevation prompt.

Configuration options:

• Enabled - The user is prompted for consent or credentials when Windows Vista detects an installer.
• Disabled - Application installations will fail to run and will either not notify the user of the problem or display an error message that might not be clear or helpful to the user to determine why the installation failed.

Default value: Enabled

Recommendation: For enterprises that are running standard user desktops and have implemented delegated installation technologies like GPSI or SMS, we recommend that you configure this setting to Disabled. If your organization has not implemented a delegated installation technology, we recommend that you configure this setting to Enabled in order to reduce support calls to your help desk. Alternatively, you can configure this setting to Disabled and instruct your users to right-click installation files and then click Run as administrator in order to elevate the process.

User Account Control: Only elevate executables that are signed and validated

This setting configures whether Windows Vista should check whether a program is signed before it can be elevated. This check is performed after the process is interactively launched (i.e. a user double-clicking an installation file on the desktop).

Configuration options:

• Enabled - Only signed executable files will run. This policy will enforce PKI signature checks on any interactive application that requests elevation.

• Disabled - Both signed and unsigned applications will run.

Default value: Disabled

User Account Control: Only elevate UIAccess applications that are installed in secure locations

This setting controls whether a lower privileged application can communicate with applications that are running at a higher privilege level. uiAccess is an attribute in an application's manifest file, which the developer packages with the application.

Configuration options:

• Enabled - Windows will prevent applications that are run from the Program Files or Windows directories from access higher privileged processes unless their application manifests define the uiAccess attribute as True. The ACLs on the Program Files and Windows directories are configured by default to prevent standard users from modifying the directories' contents. If an application's manifest file defines it as a uiAccess application, but the application is not located under the Program Files or Windows directories, Windows will not run the application with the additional privilege to access higher privileged process (e.g. although the developer identified the application as requiring uiAccess, it was installed in an insecure location that may be modifiable by standard users.
• Disabled - Windows will not verify whether the program is installed under the Program Files or Windows directories, and the application will be launched with the user's full access token upon user approval.

Default value: Enabled

Recommendation: We recommend that you configure this setting to Enabled. When this setting is enabled, Windows prevents lower privilege applications installed in insecure locations from accessing higher privilege applications.

User Account Control: Run all administrators in Admin Approval Mode

This setting defines whether Windows creates two access tokens for administrators (standard user and administrator) and whether standard users have the ability to elevate an application to administrator level.

Configuration options:

• Enabled - Both administrators and standard users will be prompted when an application attempts to run as an administrator. The User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode setting determines how the prompt is displayed to the user.
• Disabled - Users are not prompted when an application attempts to run as an administrator and the application automatically runs with the user's full administrator access token. As a result, UAC is essentially turned off and the AIS service is disabled from automatically starting. Windows Security Center will also notify the logged on user that the overall security of the operating system has been reduced and will give the user the ability to enable UAC.

Default value: Enabled

Recommendation: We recommend that you configure this setting to Enabled. If this setting is disabled, administrators will be unaware when an application runs as an administrator (including malicious software) and standard users will be unable to run applications as an administrator.

User Account Control: Switch to the secure desktop when prompting for elevation

This setting defines whether the elevation prompt is displayed on the user desktop or secure desktop.

Configuration options:

• Enabled - The UAC elevation prompt is displayed on the secure desktop, an area that can only receive messages from Windows processes. When this setting is enabled and an application requests to elevate to administrator-level rights, the desktop background is grayed out, and the elevation prompt is displayed to the user. The user cannot interact with any other element of the desktop until he/she approves or denies the elevation, either by clicking Continue or Cancel in the case of a consent prompt or by providing valid administrator credentials or clicking Cancel in the case of a credential prompt.
• Disabled - The UAC elevation prompt is displayed on the interactive (user) desktop.

Default value: Enabled

Recommendation: We recommend that you configure this setting to Enabled. If the elevation prompt is not displayed on the secure desktop, an attacker can potentially imitate the elevation prompt in order to elevate malicious software. We also recommend that you use this setting in conjunction with the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode setting configured to Prompt for consent. This configuration mitigates an attacker collecting an administrator's credentials by displaying an imitated credential prompt.

User Account Control: Virtualize file and registry write failures to per-user locations

This setting defines virtualization settings for 32-bit applications. Virtualization does not apply to 64-bit applications.

Configuration options:

• Enabled - If a 32-bit application with no manifest file attempts to write to a protected location like the Program Files directory, virtualization will redirect those operations to a locations in the file system and registry that all users can access. This setting enables standard users to run pre Windows Vista applications that have historically required the user running the program to be an administrator.
• Disabled - If a 32-bit application with no manifest file attempts to write to a protected location like the Program Files directory, the write will fail and the application will silently fail to run.

Default value: Enabled

Recommendation: Keep this setting enabled in environments where software must be run that is not fully compliant with UAC. Any 32-bit non-administrative application without an application manifest file or an application database entry is not UAC compliant. Many enterprises must run pre Windows Vista software, and therefore, should keep this setting configured to Enabled.

Configuring UAC Group Policy settings

Perform the following procedure to configure the UAC Group Policy settings. You must be logged in as a member of the local administrator’s group to perform the procedure. You can also perform the procedure as a standard user if you are able to provide valid credentials for an administrator account at the User Account Control credential prompt.

To configure the UAC Group Policy settings:

1. Click the Start button, type secpol.msc in the Start Search box, and then press ENTER.

2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

3. In Security Settings, expand Local Policies, and then select Security Options.

4. In the details pane (the right pane), right-click the relevant UAC setting and select Properties.

5. Use the drop-down list-box to choose the appropriate value for the setting.

Audit application elevations and process creation

The audit process tracking setting enables real-time monitoring of process elevations. For example, the IT department can enable audit process tracking with Group Policy and track each time an administrator in Admin Approval Mode or a standard user elevates a process to a full administrator process.

To audit process tracking

1. Click the Start button, type secpol.msc in the Start Search box, and then press ENTER.

2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

3. In the Console pane, expand Local Policies, and then select Audit Policy.

4. In the Details pane, right-click Audit process tracking and select Properties.

5. In Audit process tracking Properties, select Success.

The audit privilege use setting enables real-time monitoring of elevated process creations.

To audit privilege use

1. Click the Start button, type secpol.msc in the Start Search box, and then press ENTER.

2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

3. In the Console pane, expand Local Policies, and then select Audit Policy.

4. In the Details pane, right-click Audit privilege use and select Properties.

5. In Audit privilege use Properties, select Success, and then click OK.

UAC Services

The following service is associated with UAC.

Service

Description

Application Information Service (AIS)

Facilitates the running of interactive applications with a full administrator access token in Windows Vista. If this service is stopped, users will be unable to launch applications with the additional administrative privileges they may require to perform desired user tasks. As a result, applications that require a full administrator access token may not function correctly unless the Application Information service is running.

UAC Security Considerations

Each IT department should carefully consider UAC security considerations. While the UAC Group Policy settings enable IT departments to choose how to configure UAC, there are some considerations that they might weigh before creating the new security policy.

Imitating the Elevation Prompt

Windows Vista includes a new security setting to prevent the elevation prompt from being imitated. This new setting (User Account Control: Switch to the secure desktop when prompting for elevation) switches the active user desktop to the secure desktop when a process requests elevation. The secure desktop is only accessible to core Windows processes, and malware cannot communicate with the secure desktop. As a result, all elevation prompts on the secure desktop cannot be controlled by applications on the user desktop. All elevations occur on the secure desktop by default in Windows Vista.

Setting a Password for the Built-in Administrator Account

The following details the status of the built-in Administrator account in Windows Vista:

• Disabled for new installations and for upgrades where the built-in Administrator is NOT the only local active administrator on the computer. The built-in Administrator account is disabled by default for installations and upgrades on domain-joined computers.
• Enabled for upgrades when Windows Vista determines that the built-in Administrator account is the only local active administrator on the computer. If Windows Vista determines this, the built-in Administrator account is also kept enabled following the upgrade. The built-in Administrator account is disabled by default for installations and upgrades on domain-joined computers.

If the built-in Administrator account is disabled, Microsoft strongly recommends setting a password for the account to disable offline attacks on the account.

Disabling UAC

Disabling the User Account Control: Run administrators in Admin Approval Mode setting turns UAC “off.” Files and folders are no longer virtualized to per-user locations for non-UAC compliant applications and all local administrators are automatically logged in with a full administrative access token. Disabling this setting essentially causes Windows Vista to revert to the Windows XP user model. While some non-UAC compliant applications may recommend turning UAC off, it is not necessary to do so since Windows Vista includes folder and registry virtualization for pre-Windows Vista or non-UAC compliant applications by default. Turning UAC off opens your computer to system-wide malware installs. If this setting is changed, a system restart will be required in order for this change to go into effect.

Disabling Unused UAC Group Policy Settings

When to disable virtualization:

Virtualization is intended as a bridge technology to enable applications that are not UAC compatible to work properly in Windows Vista. If the IT department knows that only UAC compatible applications will be run in the enterprise, the UAC: Virtualize file and registry write failures to per-user locations Group Policy setting then becomes extraneous.

When to disable installer detection:

Because installers write to protected areas, such as the Program Files directory, the Win32 model requires installers to run in an administrative context. The User Account Control: Detect application installations and prompt for elevation setting invokes an elevation prompt when an installer is detected. In enterprises with locked-down desktops, where all available applications are deployed with SMS or another technology, elevation on installs is not necessary since the elevation will be done automatically by the installer service, which runs as SYSTEM.

Administrative Tasks on Remote Computers

A user that is a member of the domain administrators group, or another similarly privileged network group, should only use that administrator enabled account when the user is performing administrative tasks. The following scenario highlights this in more depth:

Carol Philips, a help desk technician at Litware, Inc, has two domain user accounts: a domain administrator account and a standard domain user account. The domain administrator account is a member of her workstation’s local administrators group. Carol has been told by her supervisors to only use her domain administrator account when she is performing tasks that require a full administrator access token. As a result, Carol logs on to her workstation with her and either uses Run as or Terminal Services when she needs to perform administrative tasks. One day, Carol notes that her computer’s hard disk has not been backed up for some time. She uses Run as to open a command prompt, enters the credentials for her administrator account, types secedit at the command prompt, and presses Enter. At the same time, she is also browsing the Web as a standard user and accidentally downloads malware from the Web. However, the malware is unable to affect other computers on the network since Carol was browsing the Internet with a standard user account.

Configuring Pre-Windows Vista Applications for Compatibility with UAC

The final, but most important, step in configuring UAC is ensuring that your software was either designed to be UAC compliant or has been configured by the IT department to work properly with Windows Vista.

For new applications that are Windows Vista Logo–complaint, the application must either run with a standard user account or, in the case of an administrative application, be marked with an application manifest entry. When a user attempts to launch an application with an application manifest entry, Windows Vista informs the user that he/she is trying to launch an administrative application and the user needs to provide approval. For more information about Microsoft’s Logo program, visit the Microsoft Windows Logo home page (https://go.microsoft.com/fwlink/?LinkId=71358).

IT departments may find during the rollout of Windows Vista that their existing line of business (LOB) applications no longer function properly. This problem is most likely due to application incompatibility with the enhancements incorporated in Windows Vista. Microsoft provides an Application Compatibility Toolkit that will assist IT departments in identifying the compatibility problems and aid in the creation of application compatibility fixes--small amounts of code that are used to fix application compatibility problems.

IT departments may find that some programs need to be able to perform administrative operations in order to function correctly on Windows Vista. For this to occur, the program needs to be marked so that users will be prompted for approval before the application can run with a full administrator access token. The process of marking applications in this manner is called marking an application with a requested execution level. The Application Compatibility Toolkit 5.0 provides the means to build and install the application compatibility database entries, which facilitate the requested execution level marking mechanism.

Fore more information about application compatibility and the Application Compatibility Toolkit 5.0, visit TechNet (https://go.microsoft.com/fwlink/?LinkId=23302).

Marking Applications with Requested Execution Levels for Application Compatibility

The requested execution level selected for an application depends on what type of system-level operations the application is performing. The following are the three different available requested execution levels.

RunAsInvoker: The application should run with the same Windows privileges and user rights as the parent process. This setting is the equivalent as not having an application compatibility database for the application. The application launches with the same privileges as the parent process launching it, which reduces the application’s security exposure. This is because for most applications, the parent is Explorer.exe, which runs as a Standard User application. RunAsInvoker applications started from a cmd.exe shell running as full admin would “run as invoker” with a full administrator access token.

RunAsHighest:

• The application should run with the highest Windows privileges and user rights the current user can obtain, but the application does not necessarily require the user to be an administrator. This marking is used for two classes of applications.
• The application can be run by both administrators and standard users, and it adapts its behavior based on the user’s privileges and user rights.
• The application requires privileges and user rights greater those of a standard user, but it does not require the user to be a member of the local Administrators group. A user that is a member of Backup Operators group is one example. This class of user cannot run applications that require a full administrator access token but can run backup applications. In this case, the pre-Windows Vista backup application should be marked as RunAsHighest.

RunAsAdmin: The application should run only for administrators, must be launched with a full administrator access token, and will not run correctly in a standard user context. This requested execution level marking is reserved for pre-Windows Vista applications that require the user to be a member of the local Administrators group. One difference between Windows Vista and previous versions of Windows, such as Windows XP, is that the operating system will take care of making sure that the application is run with a full administrator access token if it is marked RunAsAdmin in the application compatibility database. In the case where Windows Vista cannot get an administrator access token the application is never started.

Virtualization Marking

IT departments can use the following setting to control file and folder virtualization.

NoVirtualization: The application should run without file and folder virtualization. NoVirtualization would be set for two reasons:

1. Reduce Attack Surface: Applications that allow virtualization are attackable by other standard user applications. There is no mechanism in Windows Vista to differentiate between applications that are allowed to write to specific virtual locations. By turning off virtualization on applications that run well as a standard user, the risk of malware (running as a standard user) attacking the application is greatly reduced.
2. Reduce the time and cost of helpdesk debugging of virtualized data. If you know the application is working well as a standard user application, turning off virtualization will help your helpdesk personnel debug the application because they will not have to look in both the real and virtualized location to examine application configuration data.

Application Compatibility Database Marking and Application Launch Behavior

Whether an application can run and obtain a full administrator access token at runtime is dependent on the combination of the application’s requested execution level in the application compatibility database and the privileges and user rights available to the user account that launched the application. The following tables identify the possible run-time behavior based on such possible combinations.

An Administrator in Admin Approval Mode

Parent Process Access Token	Consent Policy	None or RunAsInvoker	RunAsHighest	RunAsAdmin
Standard user	No prompt	Application launches as a standard user	Application launches with a full administrative access token; no prompt	Application launches with a full administrative access token; no prompt
Standard user	Prompt for consent	Application launches as a standard user	Application launches with a full administrative access token; prompt for consent	Application launches with a full administrative access token; prompt for consent
Standard user	Prompt for credentials	Application launches as a standard user	Application launches with a full administrative access token; prompt for credentials	Application launches with a full administrative access token; prompt for credentials
Administrator (UAC is disabled)	NA	Application launches with a full administrative access token; no prompt	Application launches with a full administrative access token; no prompt	Application launches with a full administrative access token; no prompt

A Standard User Account

Parent Process Access Token	Consent Policy	RunAsInvoker	RunAsHighest	RunAsAdmin
Standard user	No prompt	Application launches as a standard user	Application launches as a standard user	Application fails to launch
Standard user	Prompt for credentials	Application launches as a standard user	Application launches as a standard user	Prompt for administrator credentials before running application
Standard user (UAC is disabled)	NA	Application launches as a standard user	Application launches as a standard user	Application fails to launch

A Standard User with Additional Privileges (E.G. Backup Operator)

Parent Process Access Token	Consent Policy	RunAsInvoker	RunAsHighest	RunAsAdmin
Standard user	No Prompt	Application launches as a standard user	Application launches as a standard user	Application fails to launch
Standard user	Prompt for credentials	Application launches as a standard user	Application launches as a standard user	Prompt for administrator credentials before running application
Standard user (UAC is disabled)	NA	Application launches as a standard user	Application launches as a standard user	Application fails to launch

Using the Application Compatibility Toolkit 5.0 to Create Application Fixes

The Application Compatibility Toolkit 5.0 is a suite of free applications from Microsoft that IT departments can use to create application compatibility fixes. The Application Compatibility Toolkit has been enhanced for Windows Vista with the ability to create application compatibility fix database entries, which are used to mark applications with a requested execution level.

The procedures in this section use the following two tools, which are included in the Application Compatibility Toolkit 5.0 download:

• Compatibility Administrator: A graphical user interface tool that assists enterprise administrators in creating program compatibility fixes for pre- Windows Vista applications.
• Sdbinst.exe: A command-line tool that assists administrators in installing application compatibility fixes for pre- Windows Vista applications.
• Standard User Analyzer: A graphical user interface tool that assists enterprise administrators with identifying applications that have application compatibility problems.

Use the following workflow to identify administrative dependencies in applications and to mark applications with requested execution levels:

• Step One: Install the Application Verifier.
• Step Two: Install the Application Compatibility Toolkit 5.0.
• Step Three: Use the Standard User Analyzer to identify pre-Windows Vista administrative applications that do not run correctly on Windows Vista.
• Step Four: Determine the requested execution level for each administrative application.
• Step Five: Run the Compatibility Administrator program to create an application compatibility fix database.
• Step Six: Install the application compatibility fix on a test computer with the sdbinst.exe command.

Step One: Install the Application Verifier.

The Application Verifier is a free download on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=120411). The Application Verifier is a prerequisite for the Microsoft Standard User Analyzer installation, which is part of the Application Compatibility Toolkit.

Step Two: Install the Application Compatibility Toolkit 5.0.

The Application Compatibility Toolkit 5.0 is a free download on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=23302).

Step Three: Use the Standard User Analyzer to identify pre-Windows Vista administrative applications that do not run correctly on Windows Vista.

The following procedure illustrates how to identify pre-Windows Vista administrative applications that do not run correctly on Windows Vista by using the Standard User Analyzer.

To identify application compatibility problems for pre-Windows Vista applications

1. Log on to a Windows Vista computer as a standard user.

2. Click Start, click All Programs, click Microsoft Application Compatibility Toolkit 5.0, click Developer and Tester Tools, and then click Standard User Analyzer.

3. In the Standard User Analyzer, for Target Application, specify the full directory path for an application to test or click the Browse button to locate the program's executable file with Windows Explorer.

4. Click Launch and then provide administrator credentials at the User Account Control credential prompt.

5. After the test application launches, perform standard administrative tasks in the application, and close the application when you have completed.

6. In the Standard User Analyzer, examine the output on each tab. Use this data to identify the compatibility issues that the program might have.

You can also run Application Verifier tests as administrator in the case of a hard privilege failure. For example, if the application, while running as non-administrator, encounters an access violation, which results in the application exiting, you will have only tested the code paths only up to the access violation. If you run the same application as an administrator, you can, in some cases, pass the access violation and exercise the remaining code paths. The logs will still depict those operations that would have normally failed as a standard user.

Step Four: Determine the requested execution level for each application.

Use the data collected from step three to determine the correct requested execution level for the application.

After identifying an application's compatibility problems with the Application Verifier, use the following procedure to mark the application with a requested execution level.

Step Five: Run the Compatibility Administrator program to create an application compatibility fix database.

This procedure is written with the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode setting configured for Prompt for consent.

To mark an administrative application with the Compatibility Administrator

1. Log on to a Windows Vista computer as an administrator in Admin Approval Mode.

2. Click Start, click All Programs, click Accessories, right-click Command Prompt and select Run as administrator, and then click Continue at the User Account Control elevation prompt.

3. In the Command Prompt, type "C:\program files\Microsoft Application Compatibility Toolkit\Compatibility Administrator\Compatadmin.exe" and press Enter.

4. In Compatibility Administrator, click the Fix icon.

5. On the Create new Application Fix page, under Program information, enter the program name for Name of the program to be fixed, enter the vendor name for Name of the vendor for this program, and enter the program file location for Program file location, and then click Next.

6. In Compatibility Modes, select None and then click Next.

7. For Compatibility Fixes, select the desired requested execution level and click Next.

8. In Matching Information, select the matching information for the application, and click Finish.

9. Click File, and then click Save.

10. Enter a name for the Application Compatibility database and click OK.

11. In Save databaseName, select a name for the database file and click Save.

Step Six: Install the application compatibility fix on a test computer with the sdbinst.exe command.

To install the application compatibility fix

1. Click Start, click All Programs, click Accessories, right-click Command Prompt and select Run as administrator and then click Continue at the User Account Control consent prompt.

2. In the Command Prompt, type "cd %windir%" and click Enter.

3. In the Command Prompt, type "sdbinst.exe databaseName.sdb" and click Enter.

Removing an Application Compatibility Database Fix

An administrator can remove previously installed application compatibility database entries through Programs and Features in the Control Panel. Uninstalling application compatibility database entries is useful if an application is no longer used in the environment but the fix is still present, or if the application compatibility fix itself requires modification.

To remove an application compatibility fix

1. Log on to a Windows Vista computer as an administrator in Admin Approval Mode.

2. In Control Panel Home, under Programs, select Uninstall a program, and then click Continue at the User Account Control consent prompt.

3. Right-click the application compatibility fix and select Remove.

Deploying Application Compatibility Fixes with Group Policy

This section describes how to deploy the application compatibility database fixes created in the Running compatAdmin.exe section using Group Policy. The IT department can perform the following steps:

1. Create a custom installer Microsoft Visual Basic script (VBScript).
2. Create a Windows Installer package for each .sdb database.
3. Authenticode sign the Windows Installer package.
4. Test the Windows Installer package.
5. Deploy the Windows Installer package with Group Policy.

Create a Custom Installer Microsoft Visual Basic Script (VBScript)

Before creating the Windows Installer package, the IT department must create a VBScript that will perform the custom installation. This process only has to be done once, and the same script file can be used for all other Windows Installer packages.

The following is an example script:

'--------------------------------------------------------------------------------------
'  Filename         : setsdb.vbs
'  Description      : Installs SDB entry in appcompat database
'  Version          : 1.0
'--------------------------------------------------------------------------------------
' History:
'   07-19-2005:  Created version 1.0

dim Ws
myCmdArgs = Session.Property("CustomActionData")
setDir = "%ComSpec% /C sdbinst.exe -q " & chr(34) & myCmdArgs & chr(34)
set Ws = CreateObject("WScript.Shell")
retval = Ws.Run( setDir, 2, true )

Create a Windows Installer Package for Each .sdb Database with Visual Studio 2005

The following example shows how to create a Windows Installer package to deploy the application compatibility fixes using Microsoft Visual Studio 2005.

To create the Windows Installer package

1. Click Start, click All Programs, and double-click Visual Studio 2005.

2. In Visual Studio, click File, and then click New Project.

3. On the New Project page, expand Other Projects, and select Setup and Deployment Project in the left-hand pane. Select Setup Project in the right-hand pane, enter a name for the application compatibility fix deployment, and then click OK.

4. In Solution Explorer in the right-hand pane, right-click the name of the deployment project, point to Add, and then click File….

5. In Add Files, browse to the location of the .sdb database file, and then click Open.

6. Repeat steps 4 and 5 and add the name of the custom action VBScript created previously.

7. In Solution Explorer in the right-hand pane, right-click the name of your deployment project, point to View, and then click Custom Actions.

8. On the Custom Actions tab, right-click the Commit folder, and then click Add Custom Action.

9. In Select Item in Project, double-click the Application folder, select the VBScript file, and then click OK.

10. Right-click the Commit action called setsdb.vbs in the left-hand pane, and then click the Properties window.

11. Add the following line to the CustomActionData property: [ProgramFilesFolder][Manufacturer]\[ProductName]\[FILENAME].sdb.

12. On the File menu, click Build, and then click BuildSolution. After the build completes, the Windows Installer package will be added to the debug folder.

Authenticode Sign the Windows Installer Package

After the IT department creates the Windows Installer package, Microsoft recommends that it be Authenticode signed before being deployed by using Group Policy. This document is written with the assumption that the IT department has already created a signing key for the enterprise with which to sign their deployment Windows Installer packages. The signing and verification tools used in the following examples are included in the Microsoft .NET Framework SDK (https://go.microsoft.com/fwlink/?LinkId=32131).

The following is an example of how to sign the Windows Installer package with the enterprises' signing key:

signcode –v <path>yourkey.pvk –spc <path>yourkey.spc (deployment package).msi

To include a timestamp in the signature, include the following parameter on the command line:

–t http://timestamp.verisign.com/scripts/timstamp.dll 

The IT department can verify the signature with the following command:

ckhtrust (deployment package).msi

If the file validates and the signing certificate chains to a trusted publisher certificate in your environment, chktrust.exe will simply return with a success return code.

Additional information about Microsoft Authenticode Technology can be found at MSDN (https://go.microsoft.com/fwlink/?LinkId=71361).

Test the Windows Installer Package

After the IT department has created the Windows Installer package, it can test the package by copying the Windows Installer file to a target computer and double-clicking it to open the Microsoft Windows Setup Wizard. The following procedure provides an example of how to test a Windows Installer package.

To test the Windows Installer package

1. Locate the Windows Installer (.msi) file and double-click it to begin the setup.

2. On the [NameofWindowsInstallerPackage] Select Installation Folder page, select the installation folder and click Next.

3. On the Confirm Installation page, click Next.

4. On the Installation Complete page, click Close.

5. Click Start, click Control Panel, and then double click Programs and Features.

6. In the Programs and Features control panel, verify that the application compatibility fix installer and application compatibility fix entries are present.

Deploy the Windows Installer Package with Group Policy

By using Group Policy, the IT department can ensure that any application compatibility fixes they create can be deployed to all their client machines automatically. This section contains the basic steps that the IT department could use to set up this deployment. Additional information about staging Group Policy deployments can be found at TechNet (https://go.microsoft.com/fwlink/?LinkId=71349).

The first step is to place the Windows Installer deployment package on a file share that is available to all the computers that should receive the fix. This can be the entire domain, or restricted to organizational units (OUs). Microsoft recommends that the IT department ensure that the Windows Installer package has the proper Access Control List (ACL) entry on the file share to allow access only to appropriate computers.

Perform the following procedure once the Windows Installer file is in place. You must log in as a Domain Administrator to perform this procedure.

Add the Group Policy to Active Directory

1. Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

2. Right-click the domain name in the console (left-hand) pane, and then click Properties.

3. On the Properties page, click the Group Policy tab.

4. On the Group Policy tab, click New and then enter a name for the new Group Policy object (GPO).

5. Highlight the newly created GPO and click Properties.

6. Because application compatibility fixes are being applied to the computers in the domain and not the users, select the Disable User Configuration settings check box. If a confirmation dialog box appears click Yes.

7. Click the Security tab and add any necessary ACLs to allow the domain computers access. Ensure that Read and Apply Group Policy is selected, and then click OK.

8. On the Properties page, click Edit.

9. In the Group Policy Management Console (GPMC), in the Console pane, expand Computer Configuration and then expand Software Settings.

10. In the Details pane, right-click Software Installation, click New, and then click Package.

11. Select the package to deploy in the Open dialog box, and then click Open.

12. In Deploy Software, select Assigned, and then click OK.

13. Close the GPMC.

14. Close the Properties page.

15. Exit Active Directory Users and Groups.

Testing and Verifying the Windows Installer Deployment

Use the following procedure to test the Windows Installer deployment.

To test the Windows Installer deployment

1. Reboot a computer a domain-joined computer.

2. Before the user login screen is displayed, Group Policy will automatically install the Windows Installer package onto the computer.

Use the following procedure to verify the Windows Installer deployment.

To verify the Windows Installer deployment

1. Log on to the computer from the previous procedure as an administrator in Admin Approval Mode.

2. Click Start, and click Control Panel.

3. In Control Panel Home, click Programs, and then click Installed Programs.

4. In change or remove a program, verify that the Windows Installer package and application compatibility database entry is installed.

Summary

UAC offers a new approach to improving computer security by fundamentally changing the way applications interact with an operating system and its files. Microsoft is working with developers to continue to innovate and create technology that minimizes the impact of malware. With UAC and using Windows as standard users, organizations and end-users are significantly less susceptible to security vulnerabilities that compromise the system. With the release of Windows Vista, Microsoft has developed a mechanism for running applications in standard user mode and for performing common operating system configuration tasks that would normally require a full administrator access token.

Feedback

Please direct all feedback about this and other UAC documents to the User Account Control Documentation Feedback list. The UAC team will make every effort to ensure that your questions and comments are addressed.

Learn More about UAC

• Developers interested in learning how to better design their applications to work with UAC should read the Windows Vista Development Requirements for User Account Control Compatibility document on MSDN (https://go.microsoft.com/fwlink/?LinkId=66021).
• The Getting Started with User Account Control in Windows Vista document on TechNet (https://go.microsoft.com/fwlink/?LinkID=66021) is geared to provide information about UAC to Chief Information Officers and IT decision makers, as well as provide test lab information.
• The UAC team blog (https://go.microsoft.com/fwlink/?LinkID=62676) includes information for ISVs, IT professionals, and anyone else interested in learning more about UAC. Comments and questions are welcome.