User Account Control (UAC) is a technology and security infrastructure introduced with Microsoft's Windows Vista and Windows Server 2008operating systems, with a more relaxed version also present in Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 and Windows 10. It aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase or elevation. In this way, only applications trusted by the user may receive administrative privileges, and malware should be kept from compromising the operating system. In other words, a user account may have administrator privileges assigned to it, but applications that the user runs do not inherit those privileges unless they are approved beforehand or the user explicitly authorizes it.
UAC uses Mandatory Integrity Control to isolate running processes with different privileges. To reduce the possibility of lower-privilege applications communicating with higher-privilege ones, another new technology, User Interface Privilege Isolation, is used in conjunction with User Account Control to isolate these processes from each other. One prominent use of this is Internet Explorer 7's "Protected Mode".
Operating systems on mainframes and on servers have differentiated between superusers and userland for decades. This had an obvious security component, but also an administrative component, in that it prevented users from accidentally changing system settings.
Early Microsoft home operating-systems (such as MS-DOS, Windows 95, Windows 98 and Windows Me) did not have a concept of different user-accounts on the same machine. Under Windows 95, Windows 98, and Windows Me, all applications enjoyed system-wide privileges rivaling those of the operating system itself; under MS-DOS and Windows versions 1.0 to 3.11 all applications had privileges equivalent to the operating system. Windows NT introduced multiple user-accounts, but in practice most users continued to function as an administrator for their normal operations. Further, some applications would require that the user be an administrator for some or all of their functions to work. Subsequent versions of Windows and Microsoft applications encouraged the use of non-administrator user-logons, yet some applications continued to require administrator rights. Microsoft does not certify applications as Windows-compliant if they require administrator privileges; such applications may not use the Windows-compliant logo with their packaging.
Microsoft developed Vista security firstly from the Limited User Account (LUA), then renamed the concept to User Account Protection (UAP) before finally shipping User Account Control (UAC). Introduced in Windows Vista, User Account Control (UAC) offers an integrated, balanced approach to encourage "super-user when necessary". The key to UAC lies in its ability to elevate privileges without changing the user context (user "Bob" is still user "Bob"). As always, it is difficult to introduce new security features without breaking compatibility with existing applications.
When someone logs into Vista as a standard user, the system sets up a logon session and assigns a token containing only the most basic privileges. In this way, the new logon session cannot make changes that would affect the entire system. When a person logs in as a user with membership in the Administrators group, the system assigns two separate tokens. The first token contains all privileges typically awarded to an administrator, and the second is a restricted token similar to what a standard user would receive. User applications, including the Windows Shell, then start with the restricted token, resulting in a reduced-privilege environment - even when running under an Administrator account. When an application requests higher privileges or when a user selects a "Run as administrator" option, UAC will prompt standard users to enter the credentials of an Administrator account and prompt Administrators for confirmation and, if consent is given, continue or start the process using an unrestricted token.
In Windows 7 Microsoft included a user interface to change User Account Control settings, and introduced one new notification mode: the default setting. By default, UAC does not prompt for consent when users make changes to Windows settings that require elevated permission through programs stored in %SystemRoot% and digitally signed by Microsoft. Programs that require permission to run still trigger a prompt. Other User Account Control settings that can be changed through the new UI could have been accessed through the registry in Windows Vista.
Windows 8 and 8.1 add a design change. When UAC is triggered, all applications and the taskbar are hidden when the desktop is dimmed.
Windows 10 copies the same layout as Windows 8.1, but the Anniversary Update has a more modern look. Also, Windows 10 adds support for Windows Hello in the User Account Control dialog box.
Tasks that trigger a UAC prompt
Tasks that require administrator privileges will trigger a UAC prompt (if UAC is enabled); they are typically marked by a security shield icon with the 4 colors of the Windows logo (in Vista and Windows Server 2008) or with two panels yellow and two blue (Windows 7, Windows Server 2008 R2 and later). In the case of executable files, the icon will have a security shield overlay. The following tasks require administrator privileges:
- Running an Application as an Administrator
- Changes to system-wide settings or to files in %SystemRoot% or %ProgramFiles%
- Installing and uninstalling applications
- Installing device drivers
- Installing ActiveX controls
- Changing settings for Windows Firewall
- Changing UAC settings
- Configuring Windows Update
- Adding or removing user accounts
- Changing a user’s account type
- Turning on Guest account (Windows 7 and 8.1)
- Turning on file sharing or media streaming
- Configuring Parental Controls
- Running Task Scheduler
- Restoring backed-up system files
- Viewing or changing another user’s folders and files
- Running Disk Defragmenter
- Running Registry Editor
- Installing or uninstalling display languages (Windows 7)
- Running the Windows Experience Index assessment
- Troubleshoot audio recording and playing, hardware / devices and power use
- Change power settings, turning off Windows features, uninstall, change or repair a program
Common tasks, such as changing the time zone, do not require administrator privileges (although changing the system time itself does, since the system time is commonly used in security protocols such as Kerberos). A number of tasks that required administrator privileges in earlier versions of Windows, such as installing critical Windows updates, no longer require administrator privileges in Vista. Any program can be run as administrator by right-clicking its icon and clicking "Run as administrator", except MSI or MSU packages as, due to their nature, if administrator rights will be required a prompt will usually be shown. Should this fail, the only workaround is to run a Command Prompt as an administrator and launch the MSI or MSP package from there.
User Account Control asks for credentials in a Secure Desktop mode, where the entire screen is temporarily dimmed, Windows Aero disabled, and only the authorization window at full brightness, to present only the elevation user interface (UI). Normal applications cannot interact with the Secure Desktop. This helps prevent spoofing, such as overlaying different text or graphics on top of the elevation request, or tweaking the mouse pointer to click the confirmation button when that's not what the user intended. If an administrative activity comes from a minimized application, the secure desktop request will also be minimized so as to prevent the focus from being lost. It is possible to disable Secure Desktop, though this is inadvisable from a security perspective.
Applications written with the assumption that the user will be running with administrator privileges experienced problems in earlier versions of Windows when run from limited user accounts, often because they attempted to write to machine-wide or system directories (such as Program Files) or registry keys (notably HKLM). UAC attempts to alleviate this using File and Registry Virtualization, which redirects writes (and subsequent reads) to a per-user location within the user's profile. For example, if an application attempts to write to a directory such as "C:\Program Files\appname\settings.ini" to which the user does not have write permission, the write will be redirected to "C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\settings.ini". The redirection feature is only provided for non-elevated 32-bit applications, and only if they do not include a manifest that requests specific privileges.
There are a number of configurable UAC settings. It is possible to:
- Require administrators to re-enter their password for heightened security;
- Require the user to press Ctrl+Alt+Del as part of the authentication process for heightened security;
- Disable only file and registry virtualization
- Disable Admin Approval Mode (UAC prompts for administrators) entirely; note that, while this disables the UAC confirmation dialogs, it does not disable Windows' built-in LUA feature, which means that users, even those marked as administrators, are still limited users with no true administrative access.
Command Prompt windows that are running elevated will prefix the title of the window with the word "Administrator", so that a user can discern which instances are running with elevated privileges.
A distinction is made between elevation requests from a signed executable and an unsigned executable; and if the former, whether the publisher is 'Windows Vista'. The color, icon, and wording of the prompts are different in each case; for example, attempting to convey a greater sense of warning if the executable is unsigned than if not.
Internet Explorer 7's "Protected Mode" feature uses UAC to run with a 'low' integrity level (a Standard user token has an integrity level of 'medium'; an elevated (Administrator) token has an integrity level of 'high'). As such, it effectively runs in a sandbox, unable to write to most of the system (apart from the Temporary Internet Files folder) without elevating via UAC. Since toolbars and ActiveX controls run within the Internet Explorer process, they will run with low privileges as well, and will be severely limited in what damage they can do to the system.
A program can request elevation in a number of different ways. One way for program developers is to add a requestedPrivileges section to an XML document, known as the manifest, that is then embedded into the application. A manifest can specify dependencies, visual styles, and now the appropriate security context:
Setting the level attribute for requestedExecutionLevel to "asInvoker" will make the application run with the token that started it, "highestAvailable" will present a UAC prompt for administrators and run with the usual reduced privileges for standard users, and "requireAdministrator" will require elevation. In both highestAvailable and requireAdministrator modes, failure to provide confirmation results in the program not being launched.
An executable that is marked as "" in its manifest cannot be started from a non-elevated process using . Instead, will be returned. or must be used instead. If an is not supplied, then the dialog will show up as a blinking item in the taskbar.
Inspecting an executable's manifest to determine if it requires elevation is not recommended, as elevation may be required for other reasons (setup executables, application compatibility). However, it is possible to programmatically detect if an executable will require elevation by using and setting the parameter to . If elevation is required, then will be returned. If elevation is not required, a success return code will be returned at which point one can use on the newly created, suspended process. This will not allow one to detect that an executable requires elevation if one is already executing in an elevated process, however.
A new process with elevated privileges can be spawned from within a .NET application using the "" verb. An example using C#:
In a native Win32 application the same "" verb can be added to a or call:
In the absence of a specific directive stating what privileges the application requests, UAC will apply heuristics, to determine whether or not the application needs administrator privileges. For example, if UAC detects that the application is a setup program, from clues such as the filename, versioning fields, or the presence of certain sequences of bytes within the executable, in the absence of a manifest it will assume that the application needs administrator privileges.
UAC is a convenience feature; it neither introduces a security boundary nor prevents execution of malware.
Leo Davidson discovered that Microsoft weakened UAC in Windows 7 through exemption of about 70 Windows programs from displaying a UAC prompt and presented a proof of concept for a privilege escalation.
Stefan Kanthak presented a proof of concept for a privilege escalation via UAC's installer detection and IExpress installers.
Stefan Kanthak presented another proof of concept for arbitrary code execution as well as privilege escalation via UAC's auto-elevation and binary planting.
There have been complaints that UAC notifications slow down various tasks on the computer such as the initial installation of software onto Windows Vista. It is possible to turn off UAC while installing software, and re-enable it at a later time. However, this is not recommended since, as File & Registry Virtualization is only active when UAC is turned on, user settings and configuration files may be installed to a different place (a system directory rather than a user-specific directory) if UAC is switched off than they would be otherwise. Also Internet Explorer 7's "Protected Mode", whereby the browser runs in a sandbox with lower privileges than the standard user, relies on UAC; and will not function if UAC is disabled.
Yankee Group analyst Andrew Jaquith said, six months before Vista was released, that "while the new security system shows promise, it is far too chatty and annoying." By the time Windows Vista was released in November 2006, Microsoft had drastically reduced the number of operating system tasks that triggered UAC prompts, and added file and registry virtualization to reduce the number of legacy applications that triggered UAC prompts. However, David Cross, a product unit manager at Microsoft, stated during the RSA Conference 2008 that UAC was in fact designed to "annoy users," and force independent software vendors to make their programs more secure so that UAC prompts would not be triggered. Software written for Windows XP, and many peripherals, would no longer work in Windows Vista or 7 due to the extensive changes made in the introduction of UAC. The compatibility options were also insufficient. In response to these criticisms, Microsoft altered UAC activity in Windows 7. For example, by default users are not prompted to confirm many actions initiated with the mouse and keyboard alone such as operating Control Panel applets.
In a controversial article, New York Times Gadgetwise writer Paul Boutin said "Turn off Vista's overly protective User Account Control. Those pop-ups are like having your mother hover over your shoulder while you work." Computerworld journalist Preston Gralla described the NYT article as "...one of the worst pieces of technical advice ever issued."
- ^"What is User Account Control?". What is User Account Control?. Microsoft. January 2015. Retrieved 2015-07-28.
- ^Windows 7 Feature Focus: User Account Control, An overview of UAC in Windows 7 by Paul Thurott
- ^"The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)". The Windows Vista and Windows Server 2008 Developer Story Series. Microsoft. April 2007. Retrieved 2007-10-08.
- ^Marc Silbey, Peter Brundrett (January 2006). "Understanding and Working in Protected Mode Internet Explorer". Microsoft. Retrieved 2007-12-08.
- ^ abcTorre, Charles (March 5, 2007). "UAC - What. How. Why"(video). Retrieved 2007-12-08.
- ^Howard, Michael; LeBlanc, David (2010). Writing Secure Code for Windows Vista. O'Reilly Media, Inc. ISBN 9780735649316. Retrieved 2013-08-06.
- ^ abcKerr, Kenny (September 29, 2006). "Windows Vista for Developers – Part 4 – User Account Control". Retrieved 2007-03-15.
- ^Bott, Ed (2007-02-02). "What triggers User Account Control prompts?".
- ^"Living with and benefiting from User Account Control". Microsoft. 2014-12-09.
- ^Allchin, Jim (2007-01-23). "Security Features vs. Convenience". Windows Vista Team Blog. Microsoft.
- ^"User Account Control Overview". TechNet. Microsoft.
- ^"User Account Control Prompts on the Secure Desktop". UACBlog. Microsoft. 4 May 2006.
- ^ abBott, Ed (2 February 2007). "Why you need to be discriminating with those Vista tips". Ed Bott's Windows Expertise.
- ^"Determine How to Fix Applications That Are Not Windows 7 Compliant". TechNet. Microsoft. Retrieved 2013-09-09.
- ^"Chapter 2: Defend Against Malware". Windows Vista Security Guide. Microsoft. November 8, 2006.
- ^User Account Control: Virtualize file and registry write failures to per-user locations
- ^"Administrator Marking for Command Prompt". UACBlog. Microsoft. 1 August 2006.
- ^"Accessible UAC Prompts". Windows Vista Blog. Microsoft.
- ^ abRussinovich, Mark (June 2007). "Inside Windows Vista User Account Control". TechNet Magazine. Microsoft.
- ^Friedman, Mike (10 February 2006). "Protected Mode in Vista IE7". IEBlog. Microsoft.
- ^Carlisle, Mike (10 March 2007). "Making Your Application UAC Aware". The Code Project.
- ^Zhang, Junfeng (18 October 2006). "Programmatically determine if an application requires elevation in Windows Vista". Junfeng Zhang's Windows Programming Notes. Microsoft.
- ^"Understanding and Configuring User Account Control in Windows Vista". TechNet. Microsoft. Retrieved 2007-07-05.
- ^"Disabling User Account Control (UAC) on Windows Server". Microsoft Support Knowledge Base. Microsoft. Retrieved 2015-08-17.
- ^Russinovich, Mark. "Inside Windows 7 User Account Control". Microsoft. Retrieved 2015-08-25.
- ^Johansson, Jesper. "The Long-Term Impact of User Account Control". Microsoft. Retrieved 2015-08-25.
- ^Russinovich, Mark. "Inside Windows Vista User Account Control". Microsoft. Retrieved 2015-08-25.
- ^Davidson, Leo. "Windows 7 UAC whitelist: - Code-injection Issue - Anti-Competitive API - Security Theatre". Retrieved 2015-08-25.
- ^Kanthak, Stefan. "Defense in depth -- the Microsoft way (part 11): privilege escalation for dummies". Full disclosure (mailing list). Retrieved 2015-08-17.
- ^Kanthak, Stefan. "Defense in depth -- the Microsoft way (part 31): UAC is for binary planting". Full disclosure (mailing list). Retrieved 2015-08-25.
- ^Trapani, Gina (31 January 2007). "Geek to Live: Windows Vista upgrade power tips". Lifehacker.
- ^"Disable UAC in Vista".
- ^Evers, Joris (2006-05-07). "Report: Vista to hit anti-spyware, firewall markets". ZDNet. CBS Interactive. Archived from the original on 2006-12-10. Retrieved 2007-01-21.
- ^Espiner, Tom (11 April 2008). "Microsoft: Vista feature designed to 'annoy users'". CNET. CBS Interactive.
- ^Boutin, Paul (14 May 2009). "How to Wring a Bit More Speed From Vista". New York Times – Gadgetwise. Retrieved 2015-01-04.
- ^Gralla, Preston (14 May 2009). "NYT Offers Bad Tech Advice". PCworld.com. Retrieved 2015-01-04.
Although the built-in capabilities for accounts cannot be changed, user rights for accounts can be administered. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories. User rights are different from permissions because they apply to user accounts, whereas permissions are attached to objects. Keep in mind that changes made to user rights can have a far-reaching effect. Because of this, only experienced administrators should make changes to the user rights policy.
Microsoft defines user rights in two types of categories: Logon Rights and Privileges. These are defined as follows:
Logon Right: A user right that is assigned to a user and that specifies the ways in which a user can log onto a system. An example of a logon right is the right to log on to a system remotely.
Privilege: A user right that is assigned to a user and that specifies allowable actions on the system. An example of a privilege is the right to shut down a system.
User rights define capabilities at the local level. Although they can apply to individual user accounts, user rights are best administered on a group account basis. This ensures that a user logging on as a member of a group automatically inherits the rights associated with that group. By assigning rights to groups rather than individual users, user account administration can be simplified. When users in a group all require the same user rights, they can be assigned the set of rights once to the group, rather than repeatedly assigning the same set to each individual user account.
User rights that are assigned to a group are applied to all members of the group while they remain members. If a user is a member of multiple groups, the user's rights are cumulative, which means that the user has more than one set of rights and privileges. The only time that rights assigned to one group might conflict with those assigned to another is in the case of certain logon rights. For example a member of multiple groups who is given the "Deny Access to This Computer from the Network" logon right would not be able to log on despite the logon rights granted to the user by other groups. The user would be logged on locally with cached credentials, but when attempting to access the domain resources would receive the following message:
In general, however, user rights assigned to one group do not conflict with the rights assigned to another group. To remove rights from a user, the administrator simply removes the user from the group. In this case, the user no longer has the rights assigned to that group.
The following lists show the logon rights and privileges that can be assigned to a user.
Some of the privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all other users, including members of the Backup Operators group. A user privilege, in this case, the right to perform a backup, takes precedence over all file and directory permissions. The privileges, which can override permissions set on an object, are listed below.
Take Ownership of Files or Other Object
Manage Auditing and Security Log
Back Up Files and Directories
Restore Files and Directories
Bypass Traverse Checking
The Take Ownership of Files or Other Object (TakeOwnership) privilege grants WriteOwner access to an object. Backup and Restore privileges grant read and write access to an object. The Debug Programs (debug) privilege grants read or open access to an object. The Bypass Traverse Checking (ChangeNotify) privilege provides the reverse access on directories. This privilege is given, by default, to all users and is not considered security relevant. The Manage Auditing and Security Log (Security) privilege provides several abilities including access to the security log, overriding access restrictions to the security log. The Event Logger is responsible for enforcing the Security privilege in this context. The TakeOwnership, Security, Backup, Restore, Debug privileges should only be assigned to administrator accounts (See Appendix C, User Rights and Privileges, of the Windows 2000 Security Configuration Guide, for the restrictions of the assignment of privileges to be in accordance with the Evaluated Configuration).
The special user account LocalSystem has almost all privileges and logon rights assigned to it, because all processes that are running as part of the operating system are associated with this account, and these processes require a complete set of user rights.
Appendix C – User Rights and Privileges, of the Windows 2000 Security Configuration Guide, contains a cross-reference table of user rights and privileges to applicable Security Target requirements that should be used as reference when implementing a user rights policy that must address specific ST requirements.
Assigning User Rights
User rights are assigned through the Local Policies node of Group Policy. As the name implies, local policies pertain to a local computer. However, local policies can be configured and then imported into Active Directory. Local policies can also be configured as part of an existing Group Policy for a site, domain, or organizational unit. When this is done, the local policies will apply to computer accounts in the site, domain, or organizational unit.
User rights policies can be administered as follows:
Log on using an administrator account.
Open the Active Directory Users and Computers tool.
Right-click the container holding the domain controller and click Properties.
Click the Group Policy tab, and then click Edit to edit the Default Domain Policy.
In the Group Policy window, expand Computer Configuration, navigate to Windows Settings, to Security Settings, and then to Local Policies.
Select User Rights Assignment.
Note: All policies are either defined or not defined. That is, they are either configured for use or not configured for use. A policy that is not defined in the current container could be inherited from another container.
To configure user rights assignment, double-click a user right or right-click on it and select Security. This opens a Security Policy Setting dialog box.
For a site, domain, or organizational unit, individual user rights can be configured by completing the following steps:
Open the Security Policy Setting dialog box for the user right to be modified.
Select Define these policy settings to define the policy.
To apply the right to a user or group, click Add.
In the Add user or group dialog box, click Browse. This opens the Select Users Or Groups dialog box. The right can now be applied to users and groups.
The following selection options appear on the Select Users Or Groups box:
Name: The Name column shows the available accounts of the currently selected domain or resource.
Add: Add selected names to the selection list.
Check Names: Validate the user and group names entered into the selection list. This is useful if names are typed in manually and it is necessary ensure that they're actually available.
To access account names from other domains, click the Look In list box. A drop-down list will appear that shows the current domain, trusted domains, and other resources that can be accessed. Select Entire Directory to view all the account names in the directory.
Note: Only domains that have been designated as trusted are available in the Look In drop-down list. Because of the transitive trusts in Windows 2000, this usually means that all domains in the domain tree or forest are listed. A transitive trust is one that is not established explicitly. Rather, the trust is established automatically based on the forest structure and permissions set in the forest.
After selecting the account names to add to the group, click OK. The Add user or group dialog box should now show the selected accounts. Click OK again.
The Security Policy Setting dialog box is updated to reflect the selections. If a mistake is made, select a name and remove it by clicking Remove.
When finished granting the right to users and groups, click OK.
Top Of Page
Configuring Local User Rights
For local computers, such as Windows 2000 Professional, apply user rights by completing the following steps:
Log in as Administrator.
Open Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
In the Local Security Settings window, navigate to Local Policies, and then select User Rights Assignment.
To configure user rights assignment, double-click a user right or right-click on it and select Security. This opens a Security Policy Setting dialog box. The effective policy for the computer is displayed, but it cannot be changed. However, the local policy settings can be adjusted. Use the fields provided to configure the local policy. Remember that site, domain, and organizational unit policies have precedence over local policies.
The Assigned To column shows current users and groups that have been given a user right. Select or clear the related check boxes under the Local Policy Setting column to apply or remove the user right.
Apply the user right to additional users and groups by clicking Add. This opens the Select Users Or Groups dialog box. Local users and groups can now be added.
To access account names from the domain, click the Look In list box. There should be a list that shows the current machine, the local domain, trusted domains, and other resources that can be accessed. Select the local domain to view all the account names in the domain.
Top Of Page