User Account Control (UAC) is a mandatory access control enforcement feature introduced with Microsoft's Windows Vista and Windows Server 2008 operating systems, with a more relaxed version also present in Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows 11. It aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorises an increase or elevation. In this way, only applications trusted by the user may receive administrative privileges and malware are 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 authorises 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-98 and Windows Me) did not have a concept of different user-accounts on the same machine. 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.
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:
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.
In earlier versions of Windows, Applications written with the assumption that the user will be running with administrator privileges experienced problems 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:
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:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="highestAvailable" /> </requestedPrivileges> </security> </trustInfo> </assembly>
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 "
requireAdministrator" in its manifest cannot be started from a non-elevated process using
ERROR_ELEVATION_REQUIRED will be returned.
ShellExecuteEx() must be used instead. If an
HWND 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
CreateProcess() and setting the
dwCreationFlags parameter to
CREATE_SUSPENDED. If elevation is required, then
ERROR_ELEVATION_REQUIRED will be returned. If elevation is not required, a success return code will be returned at which point one can use
TerminateProcess() 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 "
runas" verb. An example using C#:
System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.StartInfo.FileName = "C:\\Windows\\system32\\notepad.exe"; proc.StartInfo.Verb = "runas"; // Elevate the application proc.StartInfo.UseShellExecute = true; proc.Start();
In a native Win32 application the same "
runas" verb can be added to a
ShellExecute(hwnd, "runas", "C:\\Windows\\Notepad.exe", 0, 0, SW_SHOWNORMAL);
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."
UAC started life as the Limited User Account (LUA), then was renamed to User Account Protection (UAP), and finally we got UAC.