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:
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:
Administrator access token checks.
"All access" access requests in system protected locations.
Data writing to protected locations, such as %ProgramFiles%, %Windir%, and HKEY_LOCAL_MACHINE\Software.
Many Windows applications are not designed with the concept of least-privilege and do not separate user and administrator functionality into two separate processes.
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.
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.
Note
There is one exception to the preceding statement: Guests log onto the computer with fewer user rights and privileges than standard users.
When an administrator user attempts to perform an administrative task, such as installing an application, UAC prompts the user to approve the action. When the administrator user approves the action, the task is launched with the administrator's full administrator access token. This is the default administrator prompt behavior, and it is configurable in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy (gpedit.msc).
Note
An administrator account on a Windows Vista computer with UAC enabled is also called an administrator account in Admin Approval Mode. Admin Approval Mode identifies the default user experience for administrators in Windows Vista.
Each administrative elevation is also process-specific, which prevents other processes from using the access token without prompting the user for approval. As a result, administrator users have more granular control on what applications install while greatly impacting malicious software that expects the logged on user to be running with a full administrator access token.
Standard users also have the opportunity to elevate within a task flow to perform administrative tasks by using the UAC infrastructure. When a standard user attempts to perform an administrative task, UAC prompts the user to enter valid credentials for an administrator account. This is the default standard user prompt behavior, and it is configurable in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy (gpedit.msc).
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.
Note
The built-in administrator account is created during setup with the user name Administrator.
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.
Note
If a domain administrator account has never logged on before, then the computer must be started in Safe Mode with Networking since Windows Vista will not have cached the user's credentials.
Note
Once the computer is disjoined from the domain, it will revert back to the non-domain joined behavior previously described.
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
User or Group |
Access Control Entry |
|---|---|
BUILTIN\Administrators |
Full control |
NT AUTHORITY\SYSTEM |
Full control |
CREATOR OWNER |
Full control |
BUILTIN\Users |
Read Special access: FILE_APPEND_DATA Special access: FILE_WRITE_DATA |
Everyone |
Read |
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
User or Group |
Access Control Entry |
|---|---|
BUILTIN\Administrators |
Full control |
NT AUTHORITY\SYSTEM |
Full control |
NT AUTHORITY\Authenticated Users |
Modify |
BUILTIN\Users |
Read and execute Generic read, generic execute |
The following table details the new Windows Vista operating system root (%systemroot%) ACL settings.
Windows Vista %systemroot% ACL settings
User or Group |
Access Control Entry |
|---|---|
BUILTIN\Administrators |
Full control |
NT AUTHORITY\SYSTEM |
Full control |
BUILTIN\Users |
Read and execute |
NT AUTHORITY\Authenticated Users |
Modify Append data |
Mandatory Label\High Mandatory Level |
No write |
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.