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
  

Note
Windows Vista protects %systemroot% files and folders with permissions designed for Windows Resource Protection (WRP), which can only be accessed by the System service. Administrators can read system files and folders but cannot write to them. Note that this differs from previous versions of Windows.

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

Admin Approval Mode

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

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.

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

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.

Note
Virtualization will not be supported on native Windows 64-bit applications. These applications are required to be UAC aware and to write data into the correct locations.

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