Reconfiguring User Account Control

An Overview of UAC

I want to start out our exploration of UAC with a brief overview of UAC in action, but before I can do that, let's do a quick review of some Windows security basics. (For the security experts out there, apologies; the UAC's nature requires that everyone reading have a good understanding of Windows security fundamentals close to hand, so we'll have to do detours now and then to explain and review those fundamentals. For now, just skip the next two paragraphs and it'll all be over for the moment.)

When you log onto a computer, you normally get a piece of data identifying you that sits in that computer's RAM called a token. Tokens are important security-wise because they contain a list of your group memberships and privileges.

You use that token whenever you start up a program. When you run a command from the command line, double-click an icon on the desktop, start up a program from the Start menu or the like, Windows copies your token to whatever program you told it to start up. If you start up Microsoft Word and then tell it to go open a file named mydiary.doc, then Word asks NTFS, the file system, to let Word open up mydiary.doc for reading and writing. As the file mydiary.doc has NTFS permissions associated with it, NTFS needs to check to see whether or not Word's got the permissions to read and write mydiary.doc, so NTFS says to Word, "let's see your token." As Word's token is nothing more than a copy of your token, then NTFS ends up granting Word whatever access to mydiary.doc that you do. (Or, rather, the copy of Word that you started up has whatever access to mydiary.doc that you do.)

Note 

Note that Windows copies your token and gives the copy to a program when the program starts. Once you've started a program, you can't change the token; there's no way to pump the program's token up after the fact. If the program needs greater power to get something done, then you'll have to either exit the program, log off and log on as a more powerful account, and then restart the program, or, in any version of Windows after NT 4.0, use RunAs to start the program with the token of a higher-power account. As we'll see, Vista adds to those options.

Vista still works as Windows always has in that it's got file and folder permissions, and that when you log on you get a token that contains your group memberships and privileges. But where Vista varies from earlier versions of Windows is that Vista now has something called "Administrator Approval Mode," which allows you to let your administrators log on as administrators and in fact spend all day logged on as administrators, but without exposing their machines to the amount of risk that running all day as an admin did in pre-Vista versions of Windows. Microsoft called these administrative accounts that were essentially protected from themselves "protected administrators" or PAs for a while, but as I write this, the current term is-I'm not kidding-"administrators in Administrator Approval Mode." (Makes me want to just stick to "PAs" in this text.)

When you log on as an administrator in Administrator Approval Mode, you get not one but two tokens (Microsoft calls it a "split token," although some at Microsoft call it a "filtered token") when logging on:

• One token looks as it would before Admin Approval Mode, containing all of your groups, rights, and privileges. Microsoft calls that either the "administrator access token" or, in some places, just the "administrator token." If you've read earlier Microsoft texts about UAC then you might have seen the phrase "privileged administrator token," an older and now-unused term that still appears on a lot of Web pages. I'll just refer to it as the "administrator token" in this chapter.

• The second and new token, called the "standard user access token" or "standard user token," works as the words "standard user" suggest: the standard user token has been stripped of any administrative group memberships and privileges. (We'll get to the details of how a token gets "stripped" later, I promise; for now, I'm just laying out the basics.) Some texts use the phrase "split token" to refer to the whole notion that an administrator's token gets divided into two tokens; others use the phrase "split token" to refer to the lower-power, "standard user token."

Tip 

Recall from the last chapter that "standard user" isn't just a colloquialism, it's Microsoft's relatively new buzzword for users without any admin powers. They were calling it a "restricted user" for a while but the marketing guys thought that had bad connotations-"why are your restricting me on my own machine?"-and they were probably right.

Under Vista, Windows sees that you have two tokens. Which does it use when you try to do something? Well, basically, it ignores your administrator token and gives you whatever powers are conferred by your standard user token, which means that for pretty much all intents and purposes, Windows treats you like a regular old standard user even while you're logged on as an administrator. And, truthfully, that's not as bad a thing as you'd expect, as Microsoft has made a real effort in Vista to identify many things that unnecessarily required administrator-level powers in XP and reclassify them as available to standard users. (Making that call's not as easy as you'd think; what is to one person a solution to inconvenience is a horrific security hole to another.) As I suggested before, being a standard user is also a good thing when you unknowingly try to install some spyware as a result of some social engineering on the part of an evil website, e-mail attachment, or application.

Sometimes, of course, you need to run some program that requires administrator-level powers, and in that case you'll need Windows to recognize your administrator token when it starts the program. (Remember, programs get tokens when started, so Windows has to know which token to use at the time that it fires up the program for you. As I noted before, once a program has started, there's no way to switch tokens, and there's no way to inject more power into an existing token. One of the key things to understanding UAC is how it tells the "start up a program" part of Windows which token to use.)

In fact, however, Windows will never use your administrator token even if you have one unless either (1) you tell Windows to use your administrator token, or (2) Windows is smart enough to say to itself "hey, this sucker ain't gonna work without an administrator token, and this user's got an administrator token; let's see if she'll let me give it to the program." If either of those things happens, then you get the Consent UI that you saw back in Figure 2.1; the Consent UI is Windows' way of saying, "I think you want me to use your administrator token-may I?" Assuming that you click Confirm, then Windows can start your program with an administrator token rather than a standard user token.

That's a subtle point, but an important one that I can use to explain something that I said earlier. Remember my earlier description of what happened when I tried to create a new user account in Vista? In that scenario, I said that I logged onto a Vista system as an administrator, and started up a command prompt and tried to use the net.exe program to create the new user account. Vista rejected the attempt and said that I lacked the access to create a new user account, even though I was an admin.

Why did it fail? Because, in my scenario, I didn't ask Windows to run net.exe with my administrator token (I'll show you how to do that later) and because, for reasons I'll make clear later, Windows didn't know when it started up net.exe that it would require administrative powers, and so didn't think to ask my permission to attach the administrator token. That means that by the time net.exe needed to actually create the user account, net.exe had only the standard user token and lacked the ability to create a user account. Result: the whole thing failed.

In contrast, when starting to create a user account through the GUI, then Windows has been designed to know that anyone clicking the hyperlink "Add or remove user accounts" will require an administrator token to succeed. Thus, Windows knows that continuing with "Add or remove user accounts" would require an administrator token and that I had an administrator token. But that's still not enough to allow Windows to run "Add or remove user accounts," as Windows will never just use your administrator token without permission. So Vista raises the Consent UI. When I clicked Confirm, then the "Add or remove user accounts" process gave me my administrator token, and I could then create user accounts without error. That's UAC in a nutshell.