Getting to Know User Account Control

  • Article

By Mark Minasi, BA, MS, MPh, MCSE

See other Security MVP Article of the Month columns.

To know it is to love it ... or, at least, to understand it.

Of all the many features of Windows Vista, the one that nearly everyone loves to hate is User Account Control (UAC). I admit that it irritated me at first, also, but a bit of digging into how it works, and a bit of reflection about the reality of today's networks, brought me around. In this article, I invite you put on your miner's hat, put some new batteries in your brightest flashlight, and let me take you down below to show you a bit of how UAC works.

UAC is a collection of technologies designed to help you run Windows® without administrator privileges, ideally with a standard user account. Most everyone agrees that is a good idea and IT admins will appreciate being able to reduce the permission on their desktops. The controversy comes from a feature called Administrator Approval Mode, which runs your programs with standard user permissions by default, and prompts you if you start a program that requires administrator permissions—even if you are an administrator.

I'm not going to try to convince you that Administrator Approval Mode is a good idea, although I think that it is; I've already written that piece elsewhere. If you'd like to know why I think it’s ultimately good for us all, take a look at the article at https://www.windowsitpro.com/Article/ArticleID/93358/93358.html.

User Account Control uses a layer of programs that change how Windows creates the security token that you get upon logon so as to make you more aware of when you're doing things that might put your system at risk. Put simply, it basically does just two things:

  • When you logged on to a version of Windows earlier than Windows Vista, you got a token that contained all of your groups and privileges. Windows Vista changes that because under some circumstances it creates two tokens for you: an administrative token that holds all of your group membership and privileges, and a standard user token that contains a lower-power subset of your group memberships and privileges.

  • Whenever you start a program, that program may need to perform actions that require the full-power administrative token, or, as is the case for most programs, the application may be able to function without any trouble using just your lower-power standard user token. UAC guesses which token this program requires and, if it guesses that the program will need the administrative token, it raises a dialog box called the "Consent UI" asking if you did indeed intend for this program to assume your administrative powers.

Again, the point of Administrator Approval Mode is to raise people's awareness of when they're doing things that could damage their system. Where it's most useful are those moments when a user who's reading e-mail or surfing the Internet while logged on as an administrator clicks on what seems to be an innocent hyperlink or attachment, only to face the Consent UI. That's the kind of clue that -- UAC's designers hope -- may save someone from unknowingly installing the rootkit du jour.

Let's move now to a bit more detail. What constitutes an "administrator," an account in need of two tokens in UAC's eyes? What sorts of groups and privileges does UAC remove from the standard user token? And how does UAC guess whether some process that you're trying to start needs your administrator token or can settle for the standard user token? That's what we'll examine in the remainder of this article.

What Are Administrators Made Of?

In designing UAC, Microsoft reckoned that of the 34 possible privileges and many group memberships that a Windows Vista user account can have, nine privileges and four groups confer the ability to do some damage to a system. The “Notorious Nine” privileges (as I call them) are:

  • SeCreateTokenPrivilege, create new Windows tokens

  • SeTcbPrivilege, "act as a part of the OS" – essential for a RunAs-like operation

  • SeTakeOwnershipPrivilege

  • SeLoadDriverPrivilege

  • SeBackupPrivilege

  • SeRestorePrivilege

  • SeImpersonatePrivilege

  • SeRelabelPrivilege, the privilege to change a Windows integrity label (new to Windows Vista)

  • SeDebugPrivilege, the privilege to look into other people's processes

The “Fearsome Four” groups are all local built-in groups:

  • Administrators

  • Backup Operators

  • Network Configuration Operators

  • Power Users

The first three groups clearly confer some of the Notorious Nine privileges, hence their inclusion; we’ll see why Power Users is in there in a moment. If UAC sees that your account has either one of the Notorious Nine privileges or the Fearsome Four group memberships, upon logon your account will get two tokens.

Creating the Standard User Token

The administrative token is simple: it contains your Security ID (SID), the SIDs of your group memberships, your privileges, and a Windows Integrity Control label of “high.” (WIC is another interesting part of Windows Vista security, but it’s a different -- and big -- topic, so I can’t cover it in this article.) The standard user token is, in contrast, a mite more complex to build. It contains:

  • Your SID, as before

  • A Windows Integrity Control label of “medium”

  • All of your privileges that are not members of the Notorious Nine

  • All of your group memberships that are not members of the Fearsome Four

  • All of your group memberships from the Fearsome Four, except that they are “deny-only” memberships

That last point requires some explanation. It’s possible, although not common, for Windows to include an access control entry, a "permission," that confers a "deny" rather than an "allow." Standard user tokens contain them. For example, suppose I logged on to a Windows Vista box with an account that was a member of Power Users. I would get a standard user token that would include the Power Users group for “deny only.” If I were then to try to access something that Power Users had full control of, my attempt would fail because that would be using my Power Users group membership in an “allow” mode rather than a “deny” mode, and I don't get a Power Users "allow" in the standard user token. If, in contrast, I attempted with my standard user token to access a file that held an access control entry that specified Power Users/Deny All, I would be denied access to that file. In short, “deny only” group memberships confer all of the disadvantages of being a member of a group, without any of the advantages.

How UAC Chooses Which Token to Use

By now, you’re logged on with the administrator token and the standard user token. You go to start up a program and, as always, Windows must attach your token to that program as part of the process of starting it up. Now, once Windows has attached a token to a program, there’s no way of “injecting more juice” into it later -- program startup is the moment to decide whether the program can live with the standard user token or must have the administrator token. If UAC guesses wrong, you’ll get partway through trying to do something only to encounter some sort of infuriating “access denied” message, so it’s important that UAC guesses right. To make sure that UAC does guess right, Windows Vista provides for six ways to identify an application that requires “elevation” -- the short phrase for “needs the administrator token.” UAC will ask you if it may elevate a program if:

  • You start the application by right-clicking its icon it and choosing “Run as administrator.”

  • You mark the application as needing elevation by right-clicking its icon, choosing Properties, and then clicking the Compatibility tab on the Properties page and checking the box labeled “Run this program as an administrator.”

  • The application is marked as needing administrative credentials with an embedded or external "manifest file."

  • UAC guesses that the program is an installer program.

  • The Program Compatibility Assistant marks the application as needing elevation in order to run.

  • The Application Compatibility Toolkit marks the application as needing elevation in order to run.

The first two are self-explanatory. The third refers to adding a short XML text file either inside an .exe file or inside the same directory as the .exe file that indicates several things to the operating system. Manifests first appeared in Windows XP, where developers could use them to signal the operating system that their applications should not get the Windows XP theme effects like rounded-corner windows. Windows Vista extended this use of a manifest file by allowing developers to mark an executable as requiring elevation or, for that matter, marking that the application does not need elevation, but is Windows Vista-aware.

The fourth refers to a set of heuristics, rules of thumb that UAC uses to identify .exe files that are actually installer programs for other programs. If an .exe file is not marked with a Windows Vista-aware manifest and has the phrases “setu,” “instal,” or “update” in its name, UAC assumes that it’s a setup program and so requests elevation. You can try this out by copying a file like calc.exe from a copy of Windows XP to a Windows Vista machine and then renaming the file “setup.exe” and running it. UAC can also recognize .exe files that are installer packages created by InstallShield or the Wyse Installer.

The Program Compatibility Assistant (PCA) is a helper application that watches pre-Windows Vista installer programs run and, if it appears that they failed, pops up and prompts you to see if they did indeed fail. If they did, it will ask if it can run them again with different settings. You can see the PCA in action by doing the example that I suggested above and, when UAC asks you if it can run the bogus "setup.exe" program, tell it to allow the program. Once the Windows XP Calc is running, close it and the PCA will appear. Under some circumstances, PCA will essentially check the “Run this program as an administrator” box on an .exe file's Compatibility tab, causing elevation in subsequent runs.

Finally, Microsoft has been doing a lot of work since Windows XP came out to create a set of runtime "shims," on-the-fly fixes that can allow an application that would be unable to run under Windows XP, Windows Server 2003, or Windows Vista to run with the assistance of those shims. One, for example, is a UAC feature that we lack the space to cover here, "file and Registry virtualization." (This clever tool lets applications that insist on writing to places like System32 and HKEY_LOCAL_MACHINE\SOFTWARE work fine without administrative privileges, because virtualization invisibly redirects the write and read operations so that the application thinks it has succeeded in writing to a protected area, even though it hasn’t.) Microsoft has analyzed literally thousands of applications, collected notes on which shims each of these older applications need, and packaged that up into a file called sysmain.sdb, which ships with every copy of Windows Vista. One of those shims is a simple observation that "this application ain't gonna work unless it's elevated" and, if UAC finds that setting for a given application, it will try to elevate that application.

Clearly, this article doesn't cover the entirety of UAC. I hope it has provided a look under the hood that simplifies understanding how UAC works and thereby makes it a bit easier to learn to like. Turning off UAC is not the way to go!

Mark Minasi publishes the free Mark Minasi’s Windows Networking Tech Page and runs a technical support forum at www.minasi.com. He is the author of 25 books on computing, networking, and security, including the upcoming Administering Vista Security: The Big Surprises and Mastering Windows Vista. He is also a long-time columnist for Windows IT Pro magazine. You can reach him at help@minasi.com.