Summary

Reconfiguring User Account Control

We've been looking at how UAC examines and reacts to applications, and we've looked at how you can reconfigure applications to control how UAC reacts to them. Now let's look at reconfiguring UAC itself.

Unlike far too many Windows technologies, UAC does a nice job of giving you control over it in group policies. There's a nice panoply of options for UAC control there, but little in the GUI and command line, which isn't optimal but, if I had to choose between GUI control, command-line commands or group policy settings, I'd take the group policy settings, mostly because I have a sneaking suspicion that User Account Control's the kind of thing that enterprises are going to want to control centrally.

All User Account Control-specific group policy settings are in group policies under Computer Configuration / Windows Settings / Local Policies / Security Options. They're all prefixed with "User Account Control:," and there are nine settings that let you loosen or tighten UAC in various degrees.

Turning UAC On, Off, or in Overdrive

The first question everyone always asks about UAC is "how do I turn it off?" Well, I hope I've convinced you to give UAC a serious try, but if you can't live with it, then the place to turn it off or, as you'll see, crank it up is "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode." It takes three possible options:

• No prompt

• Prompt for credentials, and

• Prompt for consent, which is the default value.

"No prompt" means "when you need to check with the administrator to see if a requested elevation should happen, then don't bother the administrator-just elevate the process." Not "bothering" the administrator, of course, is the almost the same thing as not running User Account Control (I'll explain the minor differences in a minute), and in fact if you enable "No prompt" for this setting then a balloon will appear suggesting that you "Check your User Account Control settings; User Account Control is disabled."

"Prompt for consent" leaves UAC in its out-of-the-box configuration. When an administrator running under Administrator Approval Mode runs an application that requests elevation to use the administrator's administrator token, then that administrator gets one of four possible Consent UI dialog boxes, as we've seen, and in most cases he'll get the chance to give UAC the yea-or-nay about allowing the elevation. But if you want even more interaction by the admin when asked whether or not UAC can elevate a process, then you can choose… "Prompt for credentials," which takes consent a step further by asking an administrator not just whether he consents or not but goes beyond that, as you see in Figure 2.15.

Figure 2.15: A somewhat more demanding Consent UI

That's the orange Consent UI screen, except that, as you've probably noticed, it isn't asking the same questions that it did before; now, it just wants me to punch in my password and click OK to consent to elevating the application. Do you need to crank up the Consent UI so that it requires entering a password rather than just clicking "Confirm" or the equivalent? Probably not, but I could imagine a scenario where your administrators were a little sloppy about locking their workstations before walking away from those workstations. Speaking sternly to the admins about this behavior and, if the behavior didn't change, then assisting them in finding new lines of work might be the best answer, but if that's not possible then making any elevation impossible without a human sitting at the system typing in an administrator's password would ameliorate the problem. Or you might just plain work in a place with an obsession for security. (Personally, I'm guessing that Microsoft added this option to make some large aerospace company happy. Probably one that's physically situated near them in the Seattle area. One that does a lot of defense contracting. It's just a guess, of course.)

You just never know how quickly a group policy setting will take effect, so I tested them all to see what you've got to do to make them happen. When I modified the local Group Policy Object on my Vista machines, the new setting took effect as soon as I clicked OK; no reboots or gpupdate /force necessary.

Note 

Now, I know I've said that this is the on/off switch for UAC, but that's not 100 percent correct. This has the effect of nearly eliminating UAC, but not entirely. There is a different setting, "User Account Control: Run all administrators in Admin Approval Mode," and will discuss it later, but not immediately, because I can't explain the subtle differences between that setting and this "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" setting until we've seen some of the other settings.

Configuring UAC Junior: UAC for the User

With all of this talk about how User Account Control affects the administrator, I've inadvertently overlooked what may be UAC's most convenient aspect. Thus far, you've seen UAC in it's sort of "cranky" mode, the "are you sure?" mode. But now meet its friendlier part.

Suppose you're doing what I suggested in the beginning of the chapter by following that old security practice of spending most of your day logged on as a user account with only standard user powers. But now you want to do something that requires administrative powers. You can usually just right-click whatever icon you're going to run and choose Run as administrator, but with UAC, you needn't. If you do many things-not all, but many-that require powers beyond your account's and you try an administrative action, then in most cases you'll get a dialog box allowing you to type in the name and password of an administrative account, saving you the step of doing Run As. It looks pretty much the same as Figure 2.15 did.

As I said, not everything's smart enough to raise the Consent UI to give you the chance to punch in some admin credentials, but a lot of things do. Most EXE files that need privilege will cause UAC to prompt for credentials, and of course "Run as administrator" works in a pinch. Browse around the Control Panel and you'll see hyperlinks with the shields, as before, and double-clicking one of them gets the prompt. The only things that are troublesome are the MMC snap-ins.

In any case, if you don't want UAC to behave this way, then there's a group policy to make it stop. The setting "User Account Control: Behavior of the elevation prompt for standard users." Like the previous setting, it offers "No prompt" and "Prompt for credentials," but not "Prompt for consent." By default UAC sets this to "Prompt for credentials." But "No prompt," which meant "skip most of UAC" when applied to administrators, has a completely different meaning here: "No prompt" means "don't ask the user for admin credentials; just refuse the request."

I'm not sure why you'd do that, although I'm certain that someone will find it useful. The default setting is actually of value to administrators as well, if you think about it. Suppose you're standing over a user's shoulder trying to troubleshoot a problem that she's having and you need to do something that requires elevation. It's quite convenient to think that you needn't have her log off so that you can log with an administrative account-just do click whatever icon you need and chances are good that you'll just get a prompt for username and password. And you can even fix those pesky MMCs, if you need to: just find MMC.EXE in System32, right-click it and choose "Run as administrator" and you'll then have a privileged MMC. Just add whatever components you need and, as the snap-ins will run within the MMC, they'll inherit its administrative token.

Like its sibling setting, this setting takes effect immediately. No reboots or logoffs necessary although, of course, you've got to do a bit of jiggery-pokery to change the setting while logged in as a standard user!

Side Point: How "Administrator-ish" Must You Be to Get UACed?

That previous section reminds me that I've been oversimplifying just a bit, so let me back up and fill in a little. I've sort of been painting a picture of a world with users who have only two sets of credentials: those with a full-power administrator token, and those with restricted "standard user" tokens, and I've said that UAC splits the token for any user with administrative powers.

But let's ask: how many "administrator powers" are enough to get UAC's attention? A standard user doesn't get a split token, and a member of the Administrators group definitely gets one. But what if I were a standard user who had been granted just one extra privilege, something like the power to change a workstation's time. Would that constitute enough power to cause me to get a split token whenever I logged in? Here are the details needed to answer the question.

Building on some things that I explained earlier, UAC wakes up and decides to split a user's token if it finds that any of these things are true:

• You are a member of any of the Fearsome Four local groups (Administrators, Backup Users, Power Users, or Network Configuration Operators), or

• You have any of the Notorious Nine privileges that UAC forbids.

So, for example, let's suppose that I create a user called LPA ("low-power administrator") who is not a member of any of the Fearsome Four groups but has just one privilege above that of a standard user-she might, for example, have the privilege to restore files and directories, and that would be the only above-standard user privilege that she enjoyed. In that case, whenever she logged on, UAC would create two tokens for her: her "standard user token" that includes the five user privileges, all of her group memberships, and a "medium integrity level" token. She would have an "administrator" token that she could access by right-clicking any program and choosing "Run as administrator," at which point she would get an administrator token that differed from her standard user token in just two ways: it would have the Restore permission and a "high integrity level" token.

But what if she needed to do something that required a real honest-to-God full-power administrator? UAC knows of that possibility and so does something interesting whenever she right-clicks a program and chooses "Run as administrator." Instead of just offering her the "Confirm" button on the Consent UI, UAC offers her the choice of running as her elevated self, or some other account that can do everything that a local administrator can do.

Excluding the Built-in Administrator

To be honest, I sometimes find UAC's prompts a bit intrusive and I wish I could just say to Windows, "hey, make all of the other admins do that UAC stuff; honestly, I don't need it, so don't bother with the elevation prompts." In other words, I want the first group policy setting that we looked at here, but I want it to be user specific. (After all, I'm in good company. Wasn't it Augustine who, in his raucous youth, prayed to the heavens above and asked something along the lines of "please, take away my bad habits and show me the right way…but not just yet, okay?" And yes, I know, that's not an exact quote.)

Well, UAC answered my prayers but, as is so often the case, sometimes they don't get answered quite the way we expect. There's a group policy setting "User Account Control: Admin Approval Mode for the Built-in Administrator account" which can be either enabled or disabled, and it's enabled by default. Basically this setting is a "Get out of UAC free" card for the Administrator account, and just the Administrator account-this card is not transferable.

By default the Administrator account never sees User Account Control prompts, which makes that account a bit troublesome-as it's always been-but that's tempered by the fact that, as we covered in the first chapter, the built-in Administrator account is disabled in Vista by default.

Telling UAC to Skip the Heuristics

We saw earlier that UAC's got an interesting feature whereby whenever you run a program and do not request elevation, UAC tries to sense whether or not the program is actually a program that installs another program. As installing programs often requires actions that will fail without elevation and that'd be annoying, UAC tries to avoid that by guessing whether or not any of the EXEs that you run are actually setup programs. Recall that it can recognize installers created with the Wyse and Installshield products, and guesses that any programs with "instal," "setu," or "update" in their names are setup programs.

If for some reason you don't want Vista to do that EXE examining, then you can tell it to skip the setup heuristics with the setting "User Account Control: Detect application installations and prompt for elevations." It's enabled by default, but can be disabled if you like. Unlike most of the other UAC-related settings, this one requires a reboot to take effect.

Controlling Secure Desktop

If you've actually seen the Consent UI in action, then you may have noticed that in addition to putting a dialog box on the screen, UAC grays out the rest of the screen. Furthermore, you can't interact with anything else on your now-grayed-out desktop. Things still go on underneath the gray, but you can't see anything change on the desktop. For example, if you were running a video on the desktop and decided to look at your local group policy settings by clicking Start All Programs Run and then filling in gpedit.msc and clicking OK, then you'd see the desktop gray out, the Consent UI appear, and the video freeze. But if you wait a few seconds before clicking Confirm, then you'll see the gray disappear from the screen and the video will begin moving again-but you'll have missed some of it. Clearly it was playing; you just couldn't see it while the desktop was gray.

Understanding the Secure Desktop

So what's with the desktop going gray? It's called the "Secure Desktop." It's a feature of Vista that User Account Control and at least one other Vista app, CardSafe (an online identification system), use to, as the name suggests, secure some sort of interaction on the Desktop.

The key to understanding Secure Desktop's whole purpose is in analyzing an important question about UAC: how could a bad guy compromise it? How could an imaginary future piece of malware get around UAC and either fool you into clicking "Confirm" when you intended "Cancel," or just click the button itself?

Well, a piece of malware built with Vista and UAC in mind knows full well that when it'll need to be elevated before it can do any damage. So it would have to kick off an EXE and request elevation, and the user will have to click "Continue" or a similar button. So suppose our malware waits for the Consent UI to appear, and then creates an image of your desktop and the Consent UI that's been modified just enough to cause you to click what you think is the "Cancel" button but is actually the "Continue" button.

Or recall that it's possible to replace the mouse pointer with a different, custom pointer, like the ones that ship with Windows itself. Thus, it is quite possible (if generally useless) to create a custom mouse pointer that shows the pointer 40 pixels to the left of the actual place that the mouse is pointing to. If you actually wanted a mouse pointer like this, then you'd have to get used to pointing not exactly at the button that you wanted to click, but instead to position the mouse about 40 pixels-not an easy distance to estimate-to the right of where you wanted to click! As I said, not very useful for you. A piece of malware, however, might anticipate that it was going to do something that would cause the Consent UI to raise, and that you'd wisely click the "Cancel" button when that happened, because you hadn't done anything that made you expect to see the Consent UI. So the malware silently installs a custom mouse pointer like the one that I've just described, and, let's just say that the Cancel button is 40 pixels to the right of the Continue button. You think you're clicking the Cancel button…but you're really clicking the Continue button.

The weak link in both cases was the human-to-computer interface; it's too easy under the standard Windows desktop for a bad guy to fool you and me into doing things that we don't want to do. So what's the answer? Well, Microsoft could remove the possibilities for custom mouse cursors, greatly restrict what sort of graphics an application could show on the screen, and a bunch of other new changes that would (1) render an awful lot of applications-like nearly every game I can think of-unusable on Vista, and (2) make the range of "look and feel" possible in the Windows world a lot smaller, making Windows a much less-attractive platform for development. Clearly that's a bad idea, so they came up with the Secure Desktop. When it's running, it'll only show just one program window at a time, and the things that program can do are very, very restricted. (Sorry, game designers: no Secure Desktop implementations of Tetris. Bummer.) For the few moments that Secure Desktop is up, you actually have that limited Windows that I just described. In fact, the only applications that can run atop the Secure Desktop are ones digitally signed to be part of Vista itself, like consent.exe, the program that pops up the various Consent UI. No malware's going to be signed with the "intrinsic part of Vista" cert and, if a piece of malware is signed with that cert, then at least we'll know who wrote it…Microsoft.

Disabling Secure Desktop

Thus, when UAC asks for elevation, two things happen. First, Vista raises the Secure Desktop, and then it raises the Consent UI dialog boxes. Those are two different operations and, if you want, you can turn off the first operation. Skipping the Secure Desktop means that in theory you could be fooled by some piece of malware into agreeing to install it, which seems like a bad idea.

But who knows, you might have some application that breaks whenever the Secure Desktop runs, and that app needs to run continuously on your system. (I'll talk about a class of those apps in the next section.) In that case, you might either fix or upgrade the app, or tell UAC not to raise the Secure Desktop. You do that with the group policy setting "User Account Control: Switch to the secure desktop when prompting for elevation," which can be set to either "enabled" or "disabled" and is enabled by default. I found it useful for one reason: to get screen captures of the Consent UI, because otherwise the Secure Desktop kept me from using a screen capture program to grab the screen. (That was to be expected; otherwise, Secure Desktop would have failed in its mission.) This setting takes effect immediately when changed in gpedit.msc. If you choose this option, then it doesn't affect other things that use Secure Desktop, like CardSafe.

Enabling Applications with Secure Desktop

You just read that Secure Desktop, when working with the Consent UI, ensures that Vista knows that it got an answer to its question "elevate or not?" by temporarily converting Vista's rich range of programming possibilities into a very narrow focus: click with the mouse or choose a hotkey on the keyboard. Like a browbeating lawyer cross-examining a witness in a movie, Vista says, "all I wanna hear out of you is a mouse click or a keystroke, and it had better be fast, because you've got two minutes!"

But there are situations where that's just not going to work: accessibility technologies. Vista comes with some of them, like its On-Screen Keyboard and its Narrator screen reading software…so clearly Secure Desktop's got to be able to accommodate alternative input methods. They are generically known as "UI automation tools."

Some, like On-Screen Keyboard and Narrator, are part of Windows and so are signed, and signed by a vendor that Microsoft trusts-Microsoft, that is. So Secure Desktop's notion of "what's an acceptable form of input and output?" will extend to Narrator and On-Screen Keyboard. But what about if some third party comes up an extremely reliable voice input system, or a mouth stick for people unable to move their bodies below the neck, or one of my dearest wishes, something that would let me just think at the computer-how would something from a third party connect in a secure way with Secure Desktop?

UI automation tools must do three things in order to work with Secure Desktop. First, they've got to warn UAC that they need access to the Secure Desktop user interface. They do that with a parameter in their manifests. You may recall that we can embed a manifest into any EXE file to alert UAC to the fact that the EXE needs to be elevated, and that the portion of the manifest that lets you mark an EXE's UAC needs looked like this:

 <requestedExecutionLevel level="asInvoker" uiAccess="false" /> 

At the time, I explained what the level "asInvoker" referred to, but skipped uiAccess "falseM" so I can amend that now. This is where the creator of an application that is a UI access application-that is, one that does some sort of input/output and that needs to do it atop the Secure Desktop-alerts Vista to that fact. Marking a manifest with uiAccess "true" is the syntax that accomplishes that.

The second thing a UI automation developer must do is to sign their code and get it approved by Microsoft. As I mentioned in Chapter 1, other vendors can have their signed drivers crosssigned by Microsoft as part of Microsoft's Windows Hardware Quality Testing Labs program after meeting some criteria and paying Microsoft some money.

Finally, once a vendor marks its code uiAccess"true", then signs its code signed and gets it cross-signed by Microsoft, it's got a third criterion to fulfill in order for its UI automation tool to avoid rejection by Secure Desktop. All of the UI automation code must be stored in a small set of folders that Microsoft calls "secure locations." There are three of them:

• \Windows\System32 and its subfolders,

• \Program Files and its subfolders and, on 64-bit Windows,

• \Program Files (x86) and its subfolders.

Note 

In case you've never had a chance to run one of the 64-bit versions of Windows, the Program Files (x86) folder acts just like the usual Program Files folder, except Windows puts the 32-bit applications in the x86 folder. It stores the native 64-bit applications in the "Program Files" folder.

Can any of those requirements be relaxed? Well, there's no wiggle room about the manifest marking or the signing and cross-signing, but there's a group policy setting "User Account Control: Only elevate UIAccess applications that are installed in secure locations" that tells Vista that it's okay to accept a signed, marked bit of UI automation code that isn't in one of the two or three secure locations. It's enabled by default, but can be disabled. Unfortunately I was unable to test it to find out whether it required a reboot or not, as I didn't have access to any third-party UI automation applications.

Sign or Go Home: Requiring Signed Applications

I really like the idea of signed code for reasons that I've already stated. So long as the people who sell digital certificates for code signing do a decent job checking that the certificate that they sold in the name of Joe Blow did, indeed, go to a guy named Joe Blow, then, as I've said, we haven't removed the chance that Joe's creating and distributing malware, but we are in a position to be able to say that Mr. Blow did indeed produce that piece of code. No, it's not the whole ball of wax when it comes to security, but it's an important step. In some ways, the worst part of the Internet and the best part about the Internet is its anonymity: as the old New Yorker cartoon said years ago, "on the Internet, no one knows you're a dog." That's good in some circumstances, but it's quite bad in others, and that bad is in large measure one of the important factors in creating a world of as much malware as we deal with today. Knowing who wrote a piece of good or bad code helps establish what I have strongly felt for years was something that the Internet desperately needs: a method of maintaining "reputation," a way to be able to say, "oh, this is an app from Joe Blow; he's a good guy." I mean, reputations are a fundamental part of how we interact with people and it's fairly useful. Why not do the same thing for code?

That's why it amazes me how few vendors actually sign their code. Open up Program Files and poke around to find some of the EXE and DLL files on your computer; right-click them, choose Properties, and look for a "Digital Signatures" tab. You won't find many, even among the files that Microsoft puts in Windows, much less third parties.

That's a shame, because digital signatures do more than just establish who wrote a piece of code. The hash encrypted in the signature lets the operating system quickly verify that the code hasn't been modified since the time that the developer signed it. Thus, when looking for malware, properly signed files can be overlooked, as they're going to be clean assuming, again, that we trust the particular individual who signed it. On the other hand, I can see one reason why a lot of things aren't signed: the process of getting a code signing certificate costs money and time, and people don't demand it. I can see that for free or low-cost programs, but it's still hard to believe that all of the larger software vendors don't sign their code.

The 64-bit version of Vista incorporates a bit of this reasoning in that it is hard-wired to check digital signatures on every single driver and program involved with Windows startup, as I've mentioned before. But Vista x64 stops insisting on signatures as soon as it's up and running. Want to take that a step further? You can with another group policy setting, "User Account Control: Only execute executables that are signed and validated."

If enabled, this group policy setting changes how UAC works just a bit. Recall that to this point, once UAC's gotten the okay from you to elevate an application, it elevates it: the rule has been "if the administrator with the split token wants to give her administrator token to ABC.EXE, then let's do it." But this setting adds to the rule that not only must the administrator approve of the elevation, but the EXE must be signed.

This setting does not require that all executables be signed, just ones for programs that you want to run with your administrator token. Microsoft probably did that because malware running under a standard user token would not be able to do nearly as much damage as malware running with an administrator token.

If you do try to run an unsigned application that requires elevation, then Vista will tell you that it won't run the app, but, as you see in Figure 2.16, the dialog's not very clear.

Figure 2.16: Vista dialog explaining that it can't run a program because it's not signed

Before I move on to the next group policies setting, let me clarify what I think that you should do with this group policy setting.

On the one hand, I've given the impression that I'd like to see this happen sometime, but let me again leaven that with some reality. The fact is that most developers do not sign their executables currently, and so requiring signing all of a sudden might seriously affect your admins' abilities do to their jobs.

For example, I recently looked over the applications that I use in my small network to see how much I'd miss if I required signed executables. Virtually all of the programs that I run that do not require elevation are not signed with the exception of the Office apps: my digital photography applications aren't, Adobe Reader isn't, nor is Quicken. Those probably aren't problems except for Quicken, because Intuit has been on everyone's Top Ten Most Wanted-and here I don't mean "wanted" in a good way-for their inability to write simple accounting software that standard users can run. Yes, that's right: if you number among the millions of us poor fools who entrust our personal accounting to Quicken, then you may as well just go mark that Quicken executable as "Run as administrator." But if you turn on "User Account Control: Only execute executables that are signed and validated," then you'll be in some trouble, as Quicken's not digitally signed, either. That's an important point: if you're thinking about being the first on your block to require digital signatures, then don't just look at your administrative tools to see if they're signed-remember that there are still plenty of simple productivity tools that have no good reason at all to require your administrator token but do anyway.

On the administrative tool side, I use the stuff that's built into Windows, as well as many of the utilities that you can download from their site. Unfortunately, however, while many files in Windows are signed (although incomprehensibly not all of them), most are not, and a substantial number of utilities that I've downloaded from the Microsoft site do not have signatures. The other site that I get useful utilities from, Sysinternals-which I guess has become a Microsoft site recently when Microsoft purchased Winternals-seems to sign most but not all of their utilities.

There's one more reality that we can't ignore here, and that's the cost of signing. If I were to start creating terrific little command-line tools and give them away, what's the chance that I'd invest hundreds of dollars in getting a code signing certificate just so that I could give utilities away? Not very good.

So the bottom line is this: unless you rely on a set of administrative utilities that are signed and use productivity applications that do not require elevation to run, then it's probably a bit early to click on "User Account Control: Only execute executables that are signed and validated."

Working around Apps That Store Data in the Wrong Places

For many years, applications thought it was just fine to store user data in places where users aren't supposed to be writing. With Vista, that's not going to work anymore, as folder locations \Program Files, \Program Files (x86), and \Windows are locked down, as is the Registry hive HKEY_LOCAL_MACHINE\SOFTWARE. But older applications that still try to write to those locations may not fail after all, thanks to a Vista tool called "file and Registry virtualization." This topic is covered in a later chapter, but while we're here looking at the group policy settings for UAC, let me mention in passing that you can disable file and Registry virtualization with the group policy setting "User Account Control: Virtualize file and registry write failures to per-user locations." This appears to require a reboot to take effect and, again, we'll take up this interesting subject in more detail in a future chapter.

The Big Switch: Turning Off UAC Altogether

Okay, despite reading all of this chapter, you've decided that you really hate UAC, can't live with it, and want it gone. You want things as they were in the old days: when standard users try to do something administrator-ish, things just fail, and when administrators do something, it happens, and let the chips fall where they may. (Just think; perhaps in 2026, some old timer will be waxing poetic to a youngster, telling him of "the good old days, when administrators were administrators …and almost nobody was a user." Maybe the kid will reply with a smirk, "yeah, I bet those were the days…drive-by downloads, root kits, malware using your mailbox as a broadcasting site; sure sorry I missed it.")

Seriously, you may decide that UAC doesn't work for you, or perhaps you're trying to figure out why some pre-Vista application doesn't work on your Vista system, and you want to immediately test whether UAC's getting in the way, or perhaps you just forgot something when you installed and configured the system. Setting "User Account Control: Behavior of the elevation prompt for administrators" to "no prompt" is not the same as shutting UAC off altogether. To do that, you need the group policy setting "User Account Control: Run all administrators in Admin Approval Mode." Set it to Disabled, reboot, and UAC's gone in all of its forms, even including file and Registry virtualization.