Why User Account Control?

Why User Account Control?

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

The following list details additional reasons why it is difficult to run as a standard user on pre-Microsoft Windows Vista® computers:

1. Many Windows applications require that the logged-on user be an administrator but do not actually require administrator-level access. These applications perform a variety of administrator access checks before being permitted to run, including:

   1. Administrator access token checks.

   2. "All access" access requests in system protected locations.

   3. Data writing to protected locations, such as %ProgramFiles%, %Windir%, and HKEY_LOCAL_MACHINE\Software.

2. Many Windows applications are not designed with the concept of least-privilege and do not separate user and administrator functionality into two separate processes.

3. Windows® 2000 and Windows® XP create each new user accounts as administrators by default; therefore, key Windows components, such as the Date and Time and the Power Management control panels, do not work well for a standard user.

4. Windows 2000 and Windows XP administrators must create two separate user accounts—one for administrative tasks and a standard user account to perform day-to-day tasks. Therefore, users must log off of their standard user accounts and log back in as an administrator or use Run As in order to perform any administrative tasks.

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

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

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

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

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

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

Windows Vista Updates

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 (as indicated by an "access denied" error 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).

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 user accounts are then created as standard users.

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.

Elevation Prompts for Background Applications Are Minimized to the Taskbar

Background applications will automatically prompt the user for elevation on the taskbar, rather than automatically switching to the secure desktop for elevation. The elevation prompt will appear minimized on the taskbar and will blink to notify the user that an application has requested elevation. An example of a background elevation occurs when a user browses to a Web site and begins downloading an installation file. The user then goes to check e-mail while the installation downloads in the background. Once the download completes in the background and the install begins, the elevation is detected as a background task rather than a foreground task. This detection prevents the installation from abruptly stealing focus of the user's screen while the user is performing another task: reading e-mail. This behavior creates a better user experience for the elevation prompt. Information about how application developers can ensure that their applications are not minimized to the taskbar when they request elevation is available later in this document.

Elevations Are Blocked in the User's Logon Path

Applications that start when the user logs on and require elevation are now blocked in the logon path. Without blocking applications from prompting for elevation in the user's log on path, both standard users and administrators would have to respond to a User Account Control dialog box on every logon. Windows Vista notifies the user if an application has been blocked by placing an icon in the system tray. The user can then right-click this icon to run applications that were blocked from prompting for elevation as the user logged on. The user can also manage which startup applications are disabled or removed from this list by double-clicking on the system tray icon.

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 account is the only active local administrator account, Windows Vista will leave the account enabled and place the account in Admin Approval Mode (UAC enabled). In addition, 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 the disabled built-in administrator account to log on. Instead, any local administrator account can be used to log on. If the last local administrator account is inadvertently demoted, disabled, or deleted, then safe mode will allow the disabled built-in administrator account to logon for disaster recovery.

Domain Joined

In all cases on a domain-joined computer, the disabled built-in administrator account 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.

User Account Control and Remote Scenarios

When an administrator logs on to a Windows Vista computer remotely—through Remote Desktop, for instance—the user is logged on to the computer as a standard user by default. Remote administration has been modified to be restrictive over a network. This restriction helps prevent malicious software from performing application "loopbacks" if a user is running with an administrator access token.

Local User Accounts

When a user with an administrator account in a Windows Vista computer's local Security Accounts Manager (SAM) database remotely connects to a Windows Vista computer, the user has no elevation potential on the remote computer and cannot perform administrative tasks. If the user wants to administer the workstation with a SAM account, the user must interactively logon to the computer that he or she wishes to administer.

Domain User Accounts

When a user with a domain user account logs on to a Windows Vista computer remotely, and the user is a member of the Administrators group, the domain user will run with a full administrator access token on the remote computer and UAC is disabled for the user on the remote computer for that session.

New Default Access Control List (ACL) Settings

The ACLs on certain Windows directories have been changed to enable data sharing and collaboration in data directories and outside of a user's protected directories. A user's protected directory is the user's profile (e.g., C:\Users\Denise\Pictures\), while an example of a data directory is location outside of the operating system partition on a data drive (e.g., D:\Pictures\). Because the root directory, C in this instance, is protected by more restrictive ACLs, users were previously unable to use data directories in earlier versions of Windows Vista.

These ACL changes ensure that users can share and edit files without having to provide approval to a User Account Control dialog box. Additionally, users can now make a folder private. This change ensures that users can still easily maintain data confidentiality and integrity on data drives. These private folders will still be readable by other administrators if they elevate and should be used to keep data private from standard users.

The following are the default ACL settings on %systemroot% and the data drives in Windows XP.

Windows XP %systemroot% and data drive ACL settings

The following table details the new Windows Vista data drive ACL settings for data drives created with format.exe.

Windows Vista data drive ACL settings

The following table details the new Windows Vista operating system root (%systemroot%) ACL settings.

Windows Vista %systemroot% ACL settings

New UAC Security Settings and Security Setting Name Changes

The new security settings and security setting name updates are detailed in the UAC References section of this document.