User Access Control in a nutshell

User Account Control (UAC) is one of Microsoft’s new methods for attempting to protect users who are always logged on as an administrator. I’ve seen it talked about so wrongly so often, I’ve decided to write here about what it is and isn’t. This is my attempt to describe UAC as concisely and accurately as I know how, without falling into the flame trap of comparing it to Su (Substitute User) and other techniques. I’ll leave that to others.

UAC was introduced in Microsoft Windows Vista, and will be probably be improved (or lessened) to various extents in forthcoming products. The problem it is trying to solve is that too many Windows users are logged on with elevated user accounts all the time, when they do not need to be elevated for much of what they were doing. Not being logged on with elevated access all the time would significantly reduce the risk of current client-side attacks (which are the majority of computer attacks today). Although Microsoft has been telling administrators and end-users not to be logged on elevated all the time for many years, previous Windows versions didn’t always simplify that task (to put it mildly).

With UAC, if a user logs on with elevated credentials (elevated group membership or privileges), Windows creates two log-on sessions: one elevated, one not elevated. The user’s current session is un-elevated by default, and they must elevate the program or session they are attempting to run to “re-attach” to the elevated log-on session (and group membership, permissions, and privileges).

Note: By default, UAC does not apply to the built-in Administrator (RID 500), although this behavior can be changed.

A multitude of things happen in de-elevated sessions as compared to elevated sessions, including:

• Any elevated privileges are removed (see below)
• User’s mandatory integrity level is downgraded from high to medium (if they had high)
• File and registry virtualization may apply (it doesn’t in the elevated session)
• Internet Explorer runs in Protected Mode (except for Trusted sites zone)
• Secure Desktop is enabled for UAC prompts
• UAC elevation offered/available when needed

When UAC is enabled, all privileges except the following are stripped from the un-elevated user session:

• Change Notify (seChangeNotify)
• Shutdown (seShutdown)
• Undock (seUndock)
• Reserve Processor
• Time Zone (seTimezone)

Further, if the user belongs to the Administrators group, special “deny-only” SIDS are attached to the user’s session, which can only be used to further restrict what the user can do.

To get the session elevated in privilege, the user (or program) needs to request elevation prior to the full execution of the program being run (in most cases). This is an important point. UAC (again, in most cases) does not detect whether or not a program needs to be elevated. For example, if an unelevated program attempts to do something elevated (such as write to System32), a UAC elevation prompt will not magically appear. The elevation has to be requested before the program runs, or else the attempted elevated task will fail (with an error or silently).

Elevation can be requested various ways, including:

• User manually elevates program using RunasAdministrator menu option
• Program’s internal or external manifest indicates elevation is necessary
• Installer heuristics detected (program contains Setup or Instal in name or contains known “installer bits”
• Application compatibility database/registry locations indicate program needs to be elevated

If UAC is enabled and not in “silent elevation” mode, the user will be prompted to click on a Continue button or to type in a valid elevated user account credential. Now here is where it gets a little interesting. A valid elevated user credential can be any account located in one of 18 groups:

• Administrators
• Domain Administrators
• Enterprise Administrators
• Schema Administrators
• Policy Administrators
• Certificate Administrators
• Backup Operators
• Account Operators
• Cryptographic Operators
• System Operators
• Power Users (deprecated)
• Print Operators
• Network Configuration Operators
• Domain Controllers
• RAS Servers
• Enterprise Read-Only Domain Controllers
• Read-Only Domain Controllers in W2K8
• Pre-Windows 2000 Compatible Access

Most people think only members of the Administrators group can respond to a UAC prompt. What is even more interesting is that in Vista and later, the Power Users group has not a single permission or privilege, meaning that users placed in that group can respond to an elevation prompt, but the resulting elevated session will not be truly elevated in any way (unless configured otherwise). This is a good trick for allowing non-admin people to respond to UAC prompts when real elevation is not needed.

Further, a user can have 9 “elevated privileges” and not belong to single group above, and still be allowed to respond to a UAC prompt. These elevated privileges are:

• Create Token object (SeCreateTokenPrivilege)
• Act as part of the OS (SeTcbPrivilege)
• Take Ownership (SeTakeOwnershipPrivilege)
• Backup files and directories (SeBackupPrivilege)
• Restore files and directories (SeRestorePrivilege)
• Debug programs (SeDebugPrivilege)
• Impersonate client after authentication (SeImpersonate)
• Modify object label (SeRelabelPrivilege)
• Load and unload device drivers (SeLoadDriverPrivilege)

In the un-elevated session, any of these privileges are revoked. When elevated, the user or session gets them back.

If the user does not belong to one of these 18 groups or have one of these 9 elevated privileges, the user will not be able to successfully respond to a UAC prompt or even be prompted to click on the Continue button in consent-only mode. Although if prompted for elevated credentials, the user can supply alternate credentials that will work, if known.

If UAC enumerates local elevated credentials and displays them for potential user (as it does by default in many scenarios), only user accounts in the local Administrators group will be shown, along with the currently logged-on user if they belong to one of the 18 elevated groups or have one of the 9 elevated privileges. This last part is rarely known.

Keep in mind, UAC does not apply to:

• Safe Mode
• True Administrator (by default)
• Services
• Non-Interactive Remote Log-ons

That’s UAC in a nutshell.

The merits of UAC compared to other competitor’s alternatives, such as Su or Sudo, can be debated, but I can tell you that UAC works. For research, I frequently surf to known malicious Web sites. With UAC turned on, I frequently am alerted to “invisible” infections that would have otherwise successfully exploited my system. Or, better put, on my home machines, I’ve never used anti-malware software and I’ve never been infected by malware (in more than 22 years). I consider myself one of the world’s foremost Windows security experts, and I know a dozen others better than me. We all run Windows with UAC enabled (with password required for elevation). If we do, shouldn’t you?