Will UAC Succeed?

Digging Deeper into UAC

Let's recap what we've seen so far. By default Vista makes administrative accounts into protected administrators by splitting or filtering their logon tokens into a full-power administrator token and a low-power standard user token. When you kick off a program, Vista will, by default, attach the standard user token to that program. Alternatively, Vista may attach the administrator token to the program if you ask it to, or Vista may be smart enough to foresee that the program will need an administrative token, and attach that-but whether you ask or Vista foresees the need for an administrative token, you've got to confirm that it's okay for Vista to use that administrative token.

While that's a good start, it raises just about as many questions as it answers, at least in my mind. Let's add some more details to make User Account Control a bit clearer.

How Windows Creates the Standard User Token

As you've already read, logging onto an account that is an "administrator in Administrator Approval Mode" causes you to get a token with fewer powers than you'd normally get when logging on as an administrator. How many fewer powers? Here's the scoop.

How Windows Vista Tokens Are Structured

The token is, recall, a data structure in the RAM of a computer that you're logged onto. Vista tokens, which are very similar to pre-Vista Windows tokens, contain several items: your name, your group memberships, your privileges, and your Windows integrity level. Let's look at all of that in more detail. (And again, yes, some of this will be review for the security experts out there, but it's very important that everyone understand these fundamentals so as to understand what's happening under the hood in UAC and in Chapter 4's discussion of Windows integrity levels.)

Your "Name": Your Security ID (SID)

Your token doesn't really contain your name, as different people can have the same name, no matter how unique their names. (Amazingly, I learned a few years ago that there's another person named Mark Minasi, and he runs a telemarketing operation. So I started using my middle initial more often!) Instead, Windows needs some kind of guaranteed-to-be-unique way of identifying you, and so ever since NT 3.1, every user account has had a user account identifier called a Security ID or SID. User account SIDs and some group SIDs look like

 S-1-5-21-domainID-relativeID 

Where domainID is a 96-bit number that identifies the user account's location-either a particular domain or a particular machine where a local account might reside-and relativeID identifies the particular account in that location. More specifically, every time you set up Windows on a system, that system gets a (supposedly) unique 96-bit number that no other machine has ever had, or ever will. That also happens when you create a domain; that domain gets a 96-bit ID that no other domain or, for that matter, machine will ever get. So, for example, suppose I created a domain named http://www.bigfirm.com. The process of creating the domain causes a random 96-bit number to be generated; let's imagine that value turns out to be 12345. (It's unlikely but let's start with smaller numbers.) Every user account created on that domain would look like S-1-5-21-12345-relativeID, where the domain starts assigning relative IDs from 1000. The first user account created would have a SID of S-1-5-21-12345-1000, the second would have a SID of S-1-5-21-12345-1001, and so on. Meanwhile, http://www.bigfirm.com might have a member workstation that, of course, can have local user accounts, and that member workstation might have gotten a randomly generated identifier when built of 999999999999999999999999 (also unlikely), meaning that any local user account on that member would have a SID of S-1-5-21-999999999999999999999999-relativeID. Thus, if that were my workstation, then I might have a local user account on my workstation with a SID of S-1-5-21-999999999999999999999999-1000 ("1000" because, again, it's the first number used when creating user accounts, and I'm probably the only user account on the system), and a separate domain account with a SID of S-1-5-21-12345-1062.

Oh, and one more bit of terminology: the relative ID is often abbreviated "RID," and pronounced "rid." Thus, the RID on my local account would be 1000, and the one on the domain would be 1062. Some accounts have fixed RIDs and are called "well-known RIDs." The most well-known example of well-known RIDs is "500," the RID for the built-in Administrator account.

Again, as far as Windows is concerned, you are your SID. Yeah, you've got a name, but Windows cares about knowing that about as much as it would knowing your shoe size; it's just an attribute of your user account. Similarly, if you have an explicit permission on something like a file or folder, then that permission isn't stored as "Jane Smith has Full Control of C:\JANESTUFF;" nope, it looks more like "S-1-5-21-999999999999999999999999-1005 has Full Control of C:\JANESTUFF." Ever opened up the Security tab on an object's Properties page and expected to see the little icons of white-faced heads with blue eyes and black hair, only to face a bunch of empty head outlines with question marks in them? It's because of the fact that permissions store SIDs, not names. So when you open up a permission on a member server-which does not contain a copy of the domain's usernames and SIDs, as it's just a member-then the member server has to find and communicate with a domain controller, asking it "hey, can you tell me the names associated with these SIDs?," proffering the SIDs on the permissions that you're looking at. As this sometimes takes a few minutes, you'll sometimes see those empty heads with the question marks in them for a few moments; you're just seeing the results of a slow network or a slow domain controller. Sometimes you'll see empty heads that never go away; that's because someone gave a permission to a user or group account, and then subsequently deleted the user or group. The file and folder permission data is sitting on and is maintained by NTFS, which has no idea what the user account–maintaining part of Windows is doing at any moment, and so has no way to clean up permissions pointing to nonexistent accounts.

Tip 

A Resource Kit tool named subinacl can find and fix those problems, however.

Your Groups: A SID List

After your SID, your token contains a list of the groups that you're a member of, including

• Domain-based global groups

• Domain-based universal groups

• Domain-based domain local groups

• Built-in local groups like the Administrators and Users groups

• Normal local groups such as you or some application might create on your system

But the list in the token doesn't include the names of the groups; instead, it contains their SIDs. Some start with S-1-5-21-as did user SIDs, and in fact the Domain Admins and Domain Users SIDs look just like user SIDs-you can pick those two out with their well-known RIDs of 512 and 513, respectively. Built-in groups on a local system, in contrast, do not include the domainID part that I explained earlier; the local Users group on every Windows system around always has a SID of S-1-5-32-545, and the Administrators group is always S-1-5-32-544. There are also what Microsoft calls "well-known groups," groups whose membership is built on the fly like the Everyone (S-1-1-0) group or the Interactive (S-1-5-4) group, which you get to be a member of when you're physically sitting at a computer.

Your Privileges: What You Can Do

Windows gives you the power to do things besides having read or write access to a file, user account, service, or the like. It also lets you perform certain tasks that don't fit into the "permissions" way of thinking, like being able to shut down a computer or change its time. Windows defines the ability to do certain functions either as rights or permissions. "Rights" refers to the way that Windows controls whether you can or can't log onto something, so the ability to "log onto this machine locally" or "deny access to this machine across the network" are rights. All other abilities are called "privileges."

Note 

Now, you could argue that Microsoft could make the clock an object with permissions on it, and those permissions might be whether you could change the time or change the time zone; then you could control who can and can't change the time with a standard Security tab on a Properties page rather than by adjusting a privilege, and so perhaps the whole idea of privileges and rights versus permissions is an unnecessary distinction. But there are some abilities that probably wouldn't fit into the permissions model. For example, consider the "right to take ownership." This lets administrators take ownership of any object no matter how much they've been locked out of that object. There'd be no way to implement that as a permission without bending the whole permission model out of shape pretty badly. Essentially it could never be a permission, but instead an ability to seize a state (ownership) that would then grant the permission to set a permission! In any case, rights and privileges have been around for a long time in Windows and I don't think that'll change any time soon. Although there's always Vienna….

SeWhat?

Vista defines 34 different types of user privileges and 10 different types of rights for user accounts. When you see descriptions of privileges, then you may see them described in two ways. The first way is a short English description of the privilege, like "change the system time." As its name suggests, having this privilege gives you the power to reset a computer's clock. But when doing low-level security programming in Windows, developers needn't type out "change the system time"; instead, every privilege has a short name that looks like Se something Privilege. For example the short name for "change the system time" is "SeSystemtimePrivilege." Having a shorter, if more cryptic name is mostly for the convenience of coders, and, as Microsoft's CEO Steve Ballmer once famously explained, Microsoft's central focus is developers.

Note 

Actually, Ballmer-who's known for a flamboyant presenting style-did it by yelling "developers, developers, developers…" a few dozen times. He likes to do that kind of thing, although he did have to get his vocal cords operated on to repair them after a similar performance in 1991. He was chanting "Windows, Windows, Windows" a zillion times at a conference in Japan. My guess is that he probably did it in the hopes of making his audience forget that he had told the world fewer than two years before that the operating system that Microsoft was 110 percent behind, the one that would take us into the 21st century, was… OS/2. But he's a heck of an amusing guy to listen to. My personal favorite Ballmerism was when he explained to a crowd I was in that the new version of Office (I forget which it was) would let you create more "impactful" presentations. Imagine; there are 411,000 words in English, and Steve's still got to create some more.

I'll try to remember to use both the Se term and the English phrase in this text because while the English description is more descriptive, Microsoft has a tendency to use the short name for privileges in their documentation far more than the English description.

Your token includes your privileges, but for some reason does not include your rights-I guess declaring your ability to log onto a system after you've already logged onto it is sort of pointless. As I explained in Chapter 1, standard users under UAC get five privileges:

• The ability to shut down a system, SeShutdownPrivilege.

• The ability to manipulate a file or folder that they have access to, even if the file or folder are inside folders that the user lacks access to. This is known as "bypass traverse checking" and SeChangeNotifyPrivilege.

• The ability to undock a laptop from a docking station, SeUndockPrivilege.

• The ability increase a "process working set," the geeky phrase for "the amount of memory that a program uses." This is a new privilege that did not exist before Vista and I presume that Microsoft intends to deny this to some service accounts so as to make it harder for a service hijacked by some buffer overflow worm to start sucking up the computer's RAM. Its short name is SeIncreaseWorkingSetPrivilege.

• The ability to change a workstation's time zone. This is also a new-to-Vista privilege, and it's intended to solve an old problem. We don't want just anyone being able to change a system's clock because the clock needs to be in sync with the network in order for Active Directory to work, and in particular we wouldn't want bad guys being able to mess with a clock so that the Event Log items that document their evil deeds would show misleading times. But traveling folks want to make their system clocks match the clocks around them as they shift from time zone to time zone, so Microsoft split off this function into a new privilege. Its short name is SeTimeZonePrivilege.

But let's look at why Vista gives standard users those five privileges by default. It's not that Vista says, "standard users get these five privileges;" in fact, in this case, you were originally logged on as a member of the local Administrators group, and that group has all of those privileges. When Vista yanked your Administrators group membership, therefore, you lost all of those privileges.

But now consider the case of a standard user account to which some administrator has added some extra privileges. For example, what if an administrator were to grant your account the "change the workstation's clock" privilege-would you keep the privilege when logged on under the watchful eye of UAC? It's true that UAC doesn't want standard users to have some privileges, but "change the workstation's clock" isn't one. (That seems odd to me, given what I explained earlier about the new "change the time zone" privilege, but that's the way it is.)

There are 34 user privileges that any user or group account can possess. UAC only objects to nine of them:

• Create a token object, or SeCreateTokenPrivilege, lets you actually create tokens of the kind that we discussed just a few pages ago. You can see that this could be a pretty powerful ability, as it would let you "write your own ticket," so to speak!

• Act as a part of the operating system (SeTcbPrivilege) has been called "the Holy Grail of hackers." It was the basis of the forerunner to RunAs, a Resource Kit tool called "su.exe" and is an essential part of doing things but looking like someone else. It's useful if you're doing hardware debugging, but standard users don't need it.

• Take ownership of files and other objects (SeTakeOwnershipPrivilege) is probably familiar, but for those who've not heard of it, this privilege lets its possessor take not just ownership but control of files, folders, services, Active Directory components, and more. "More" in this case includes Windows integrity labels, which we'll cover in Chapter 4, and isn't really something that you want users messing with.

• Load and unload device drivers (SeLoadDriverPrivilege) is sinister because there's more to a device driver than simply making a piece of hardware work. Many applications depend on device drivers not because they're dependent on some special hardware but because a device driver can look anywhere in the system and often modify any data structure in the system. Want to peek at passwords? Write a device driver. But then you've got to install it, and that's what UAC's trying to keep you from doing.

• Back up and restore files and directories (SeBackupPrivilege and SeRestorePrivileg e) are two privileges that have always kept security people up nights, believe it or not. Try this some time: create a file and deny yourself all access to the file, then run most of the backup programs out there. Your backup will succeed, even though the backup program is running as you. Why? Because SeBackupPrivilege and SeRestorePrivilege are "back doors" that let you read files (SeBackupPrivilege) and write files (SeRestorePrivilege) even if you lack the NTFS permissions to do so.

• Impersonate a client after authentication (SeImpersonatePrivilege) is similar to "act as a part of the operating system" in that offers bad guys the opportunity to hide their identities while working on your system, so UAC blocks this privilege.

• Modify an object label (SeRelabelPrivilege) gives you the power to modify an object's mandatory integrity control level. We haven't discussed Windows integrity control yet, but it's an important new feature of Windows that we'll cover in Chapter 4. In short, it's a way to describe how "trusted" a file or user is, sort of like the government notion of things that are "classified," "secret," "top secret," and the like. People with this power can reclassify objects nearly at will, which is not a good idea.

• Debug programs (SeDebugPrivilege) does not, as the name suggests, let you debug programs; a debugging program lets you do that. But debuggers need to look into a program's processes and data structures, and those processes and data structures are essentially owned by whomever's running the program. Therefore you can run a debugger to examine your own programs without any trouble. But what if you wanted to examine programs running in the operating system that you don't own, like most of the operating system? Then you'd need somewhat higher privilege…and "debug programs" is the key. Remember, you needn't give this permission to the coders in your office unless they're rewriting the operating system for you!

You have probably run into SeDebugPrivilege, whether you realize it or not. If you've ever run Task Manager from a Windows 2000 or later system, you may have noticed a check box in the lower left-hand corner of Task Manager labeled "Show processes from all users." That check box is there because a standard user has complete rights to see and manage her own processes, but none to examine what other users or the system is doing. But if she happens to possess the SeDebugPrivilege, then she can check that box and monitor the entire operating system.

As UAC only blocks the Notorious Nine, there are potentially 25 user privileges that users can employ without requiring elevation.

Your Windows Integrity Level

The final thing that you'll see in a token on a Vista system is your current Windows integrity level. It's a completely new idea first appearing in Vista, and we'll cover it in Chapter 4. But here are a couple of basic notions that we'll need in this chapter. Windows integrity levels are a means of describing how much the operating system "trusts" you. There are six levels of Windows integrity, but we'll just look at two here: the "medium" Windows integrity level and the "high" Windows integrity level. Standard users get a medium Windows integrity level; administrators get a high Windows integrity level.

Windows integrity levels show up in your token as a SID. They look like S-1-16-value, where value is 8192 for medium Windows integrity level and 12,288 for high Windows integrity level.

Seeing Your Token Information

By now, you're probably itching to find out about your token. Fortunately, Vista gives us a nice command-line tool with which to explore tokens: the whoami.exe program. Open up a command prompt and type whoami /user. When I did that while logged on as a user named "mark" from a domain called "http://www.bigfirm.com," whoami returned this:

 C:\mystuff>whoami /user USER INFORMATION ---------------- User Name SID ============ ============================================== bigfirm\mark S-1-5-21-1592023571-1864867759-2423328773-1010 

The first part of any token is, again, the user SID, and whoami /user shows that. Next, let's see what groups your user account is a member of. whoami /groups displays that information. If I run that command on my system, I get this result:

 C:\mystuff>whoami /groups GROUP INFORMATION ----------------- Group Name                   Type             SID Everyone                     Well-known group S-1-1-0 BUILTIN\Users                Alias            S-1-5-32-545 BUILTIN\Administrators       Alias            S-1-5-32-544 NT AUTHORITY\INTERACTIVE     Well-known group S-1-5-4 BIGFIRM\Domain Admins        Group            S-1-5-21... Mandatory Label\Medium Mandatory Level        S-1-16-8192 

Actually, yours will look a bit different; I had to edit the output a bit to allow it to fit on the page. In the process I deleted some interesting information, but in a bit I'll bring that back and explain it. What I want you to notice right now is that whoami displays group membership, so you can see that this account is both a local administrator (it's a member of BUILTIN\Administrators) and a domain admin (it's a member of BIGFIRM\Domain Admins); that looks like this account hasn't been reduced in power at all-but there's a catch that we'll see in a minute. Notice also that, as I said, my Windows integrity level shows up as a SID "S-1-16-8192." The OS doesn't exactly call it a "medium Windows integrity level," it refers to it as "Mandatory Label\Medium Mandatory Level," but perhaps by the time you read this they will have brought the various names for mandatory integrity levels into line with each other.

Now let's return to the fact that I've got an entry for BUILTIN\Administrators on my token, but if I try to do something admin-like then what I'm trying to do will either fail, or I'll get the Consent UI that will, recall, kick in a whole different token. whoami /groups produces some pretty wide output, and if I scroll over to the right a bit I see that I've skipped an entire column labeled "Attributes."

Tip 

If you get tired of scrolling left and right, as I eventually did, you can tell whoami to just format the information as a list by adding "/fo list" to the command, as in whoami /groups /fo list or, if you'd like to pump it into an Excel spreadsheet, add "/fo csv."

The attributes for most groups are "Mandatory group, Enabled by default, Enabled group," which basically means "UAC didn't mess with this group." But a look at the attributes of the BUILTIN\Administrators group shows them to be "Group used for deny only." Huh? Whuzzat?

Well, usually when we put a permission on something like a file or a folder, those permissions tend to be what are called "allow" permissions. When we say that we gave someone "read access" to a folder, what we really mean is that we created an "access control entry"-a permission-allowing "read" permissions. But it's also possible to create an access control entry denying "read" permissions. We usually don't bother creating "deny" permissions because by default if you don't have any "allow" permissions on something, then you're denied access to it. But sometimes "deny" permissions make sense, so here's what UAC did: it kept my membership in the BUILTIN\ Administrators group, but only insofar as it lets someone deny me access to something. In other words, if I want to do something administrator-like then I won't be able to, because any "allow" permission naming the Administrators group has been removed from my standard user token, but if I was previously unable to do something even as a member of the Administrators group because of an explicit "go away, Administrators!" permission, then I'm still subject to that. All of the bad things about being an admin, and none of the good!

We've seen that UAC removes membership in BUILTIN\Administrators from the standard user token, but that's not the only one that it'll block. To find out which groups get eighty-sixed from the standard user token, I tried creating a local user and joined it to every one of Vista's built-in groups, then ran whoami /groups /fo list to see which got the deny-only access control entry. The list of the Fearsome Four groups, then, is:

• BUILTIN\Administrators

• BUILTIN\Backup Operators

• BUILTIN\Power Users

• BUILTIN\Network Configuration Operators

All of the other built-in Vista group memberships are passed right on through to the standard user token. Additionally, I was surprised to see that my membership in the domain's Domain Admins group remained in my standard user token.

Summary: From Administrator to Standard User

Now that we've picked at a UAC standard user token, let's summarize exactly what happens when UAC creates a standard user token from an administrator account.

• You get the same user SID in your standard user token as you have in your administrator token.

• You lose all of the Notorious Nine "scary privileges": create a token, act as a part of the OS, take ownership of objects, load and unload device drivers, back up and restore, impersonate a client, modify an object label, and debug programs.

• Your Windows integrity level goes from High (S-1-16-12288) to Medium (S-1-16-8192).

• You retain all group memberships except for the Fearsome Four-BUILTIN\Adminis-trators, BUILTIN\Backup Users, BUILTIN\Power Users, and BUILTIN\Network Configuration Operators. On those groups, you still have the group membership, but only if that group membership lets someone deny you access to some object. Even if a group confers on you one of the Notorious Nine privileges, you retain the group membership…you just lose any of the forbidden privileges unless you elevate. Thus, if you're a member of Domain Administrators, then you remain a member of Domain Administrators; you just lose the membership in the local Administrators group that you previously had as a side effect of being in Domain Admins.

How to Tell UAC to Use the Administrator Token

Now that we've exercised the standard user token a bit, let's take the full-power administrator token out for a spin. But how?

Using RunAs to Get an Administrator Token Command Prompt Window

With a variation on a tool that you may already know: the RunAs command.

Windows 2000, XP, and 2003 let you tell Windows when starting any command, "run this command, but don't attach my token to it-attach another account's token." You then specify the username and password of the account whose token you want the program to have. There's a command-line RunAs, but most folks will probably find it easier to right-click the Start menu item or program icon and choose "Run as administrator," as you see in Figure 2.2.

Figure 2.2: Running a command prompt as administrator

If you've used Windows 2000, XP, or 2003, notice the difference in this context menu. In those earlier Windows, you'd choose "Run as…" and then punch in the username and password of the account to run the program under; now, instead, there's the simpler "Run as administrator." This has disappointed some folks, because it can be quite convenient to test security in a newly configured or reconfigured system by being able to just fire up a client program under any account desired and then use that client-with-a-different-user-token to check whether something that you think you've just secured from some group of users is, in fact, secured. I wish they had offered both "Run as administrator" and "Run as…," but they didn't, so there's not much to be done about it. You can, however, still use the command-line RunAs tool to run any arbitrary program under any given user account, and its (ugly) syntax has not changed since XP and 2003.

Anyway, right-clicking something and choosing "Run as administrator" causes Windows to raise the Consent UI and, after you click Confirm, Windows runs the desired application and gives it the administrator token rather than the standard user token. We can see that in action if I log onto a Vista machine as a local administrator, start a command prompt with "Run as administrator," and try a whoami /groups /fo list. I'll spare you most of the output, but a couple of entries are interesting:

 Group Name: BUILTIN\Administrators Type:       Alias SID:         S-1-5-32-544 Attributes: Mandatory group, Enabled by default, Enabled group, Group owner Group Name: Mandatory Label\High Mandatory Level Type:       Unknown SID type SID:         S-1-16-12288 Attributes: Mandatory group, Enabled by default, Enabled group 

The first item is interesting because note that the BUILTIN\Administrators group membership is, indeed, activated-none of that "Group used for deny only" stuff anymore. The second shows that the Windows integrity control SID is now S-1-16-12288, the "High" level for Windows integrity control.

If I were to try that net user mark swordfish /add command now, I wouldn't get an "access denied" message. (I would get an error message because now there's already an account named "mark," but that's another story.)

In case you're still a doubter, do a whoami /priv to see the privileges enjoyed by this command prompt. Still got that measly five privileges? Heck no. I count 23 on mine. I sure hope all of that power doesn't go to my head….

By the way, before I leave this section, there's a bit of terminology that I've mentioned before but wanted to underscore: "elevated." Instead of saying "run the command prompt with Run as administrator," you can instead say "run the command prompt elevated," or "run an elevated command prompt." "Elevated" here just means "run with an administrator token."

Making Elevated Windows Easier to Get To

But perhaps you'd rather not waste a lot of time right-clicking. Time to turn off UAC? Definitely not. Here are a few ideas to let you keep that standard user token around for your own protection, while getting to apps to run as with a full-power administrator token.

Keep a High-Power Command Prompt Handy

I find it extremely useful to start up a command prompt window with "Run as administrator" and leave it open so that I've always got an admin-level command prompt close at hand. Once you get it open, do yourself a favor and click on the control menu on the command prompt window, and then click Properties. Go to the "Colors" tab and give it a different-colored background; I always change the black background to dark blue. That way, I don't do regular standard user tasks from that command prompt window accidentally, exposing myself to some destructive error that a command prompt running as standard user would protect me from. That blue background always says "hey, don't use me unless you need to!" to me.

Note 

Microsoft did add a feature to the Command Prompt window around RC1 whereby they prefix the Command Prompt window's name with "Administrator" to also clue you into that window's elevated status. They're not doing it for all apps unfortunately, though.

Make Any Icon Automatically Raise the Consent UI

Having an elevated command prompt around is okay, but it's still a pain to have to remember to right-click the Start menu item for "Command Prompt" and choose "Run as administrator." Isn't there a way to create icons and Start menu items that automatically know to ask to run with the administrator token? Sure.

First, create a new item on the Start menu as you would in Windows 2000, XP, or 2003, by adding a new shortcut to some part of the Programs folder in your profile. I'll create a new shortcut to Command Prompt that I'll call "Floating Command Prompt" (it is elevated) like so:

1. Right-click the Start menu, and choose Explore.

2. That opens an Explorer folder. In that folder is a folder called Programs. Open that up.

3. Inside Programs, you'll see a folder structure that mirrors the hierarchy of your Start menu. Find where you'd like to put Floating Command Prompt. (I put mine in Accessories.) Right-click wherever you want the icon and choose New Shortcut.

4. A wizard appears that asks you what you want this shortcut to point to. Command prompt points to cmd.exe in c:\windows\system32, so either type that into the field labeled "Type the location of the item:," or click the "Browse…" button to find cmd.exe. Once you've got that filled in, click Next.

5. The second wizard page asks, "What would you like to name this shortcut?" I'm filling in "Floating Command Prompt," but you're welcome to use whatever you like-it's just a label for our convenience.

6. Once you've got the prompt name entered, click Finish. You'll see the Accessories folder with icons in it, as before, but now you'll see an icon labeled "Floating Command Prompt." Right-click that and choose Properties.

Congratulations, you now have a new Start menu item. But it's not smart enough yet to automatically raise the Consent UI and get itself the administrator token. To do that, right-click the item and choose Properties, and then the Shortcut tab. You'll see a property page like the one in Figure 2.3.

Figure 2.3: Shortcut properties page, Shortcut tab

So far, Vista's not doing anything that different from 2000, XP, or 2003. But now let's click the "Advanced…" button to see something like Figure 2.4.

Figure 2.4: Advanced Shortcut properties

Notice the check box labeled "Run as administrator." Check out the Advanced Properties page for a shortcut under XP or 2003 and "Run with different credentials." Again, Microsoft has collapsed the "RunAs" infrastructure a bit. Check the "Run as administrator" box, click OK twice to dismiss the Advanced Properties dialog for the shortcut and then to dismiss the Properties page for the shortcut, and close the Windows Start Menu Programs Accessories Explorer. Now click Start All Programs Accessories and you'll see "Floating Command Prompt." Click it and the Consent UI will appear; click Confirm and you've got a full-power command prompt at your fingertips. (Don't believe me? Run whoami /all for the full story. Expect to have to scroll to see it all, though.)

You can do this for any program that you like; the command prompt's just the start. If you find that you're trying to run an older program that needs the full administrator token but Vista isn't smart enough to ask for the administrator token, then this is the way to easily bypass the need for right-clicking every time that you want to run the program.

Tip 

Before leaving this, though, you might want to finish up that "Floating Command Prompt." Click Start All Programs Accessories, then right-click the "Floating Command Prompt" item and choose Properties. Click the Shortcut tab and, at the end of the Target: field, which is currently populated with C:\Windows\System32\cmd.exe, add /T:1F without the double quotes. That'll tell the command prompt to start up with a dark blue background and bright white lettering. That way you needn't set the colors every time that you start the command prompt-the shortcut will do it for you if configure it in this tab. Honestly, I highly recommend putting together a special elevated command prompt menu item with a different color scheme; once I put this together I didn't find UAC nearly as annoying.

Now, what I just showed you works fine for Start menu items and shortcuts because they're basically the same thing, but if you tried to mark a particular EXE file as requiring elevation, then you'd see something just a mite different.

Note 

When I say "EXE file," I'm referring to most of the files that contain programs. When you run Notepad, you're really telling the operating system to load and run a file called "notepad.exe." If you've never seen anything like that, just open up the Computer folder on your Vista box and navigate to the Windows\ System32 folder. And be sure that you've told Vista not to hide file extensions, or you'll just see "notepad" rather than "notepad.exe."

For example, I have a program simple.exe written a long time ago in the pre-Vista days. To mark it as requiring elevation, I right-click it and choose Properties, and then the Compatibility tab to see a page like Figure 2.5.

Figure 2.5: The Compatibility tab for a pre-Vista application

Notice the check box "Run this program as an administrator." That's where you check in order to get this elevated every time that you run it, as there's no Shortcut tab here.

Note 

The reason that I mentioned that this application was not Vista-aware was that if you do try to look at the Compatibility tab on a Vista application, then you'll see the tab and the entire page will be grayed out.

Note that if I did check that box so that UAC tries to elevate simple.exe, then that setting would only apply when I was running simple.exe. Someone else with an account on my machine would not get the UAC elevation prompt, and perhaps their attempt at running simple.exe would fail because it wasn't elevated. To fix that, click the box labeled "Show settings for all users." That brings up a similar-looking page that lets you check the "Run this program as an administrator" box for all users.

Sometimes Elevation Doesn't Work

Once I got comfy with creating shortcuts that had the "Run as administrator" embedded in them, I soon realized which program I really wanted an elevate-me-without-the-right-click icon for: Windows Explorer. I figured that I'd save all kinds of time navigating the muchtighter default permissions on my Vista hard disk with such a thing.

Unfortunately, it's not possible.

Yes, you can fiddle around with the Windows Explorer icon and check the "Run as administrator" box, but nothing will happen. You see, you start up a copy of Explorer when you log on; it's an essential part of the logon process. Now, when you try to run a second copy of Explorer, you don't really get a second copy of Explorer. When Explorer is asked to start up, it looks around to see if there's already a copy of Explorer running. If there is, then Explorer doesn't run a second time; it just opens up a new window into the same copy of Explorer. The copy of Explorer that starts up when you log on gets, as you'd guess, your standard user token and, because starting a second copy of Explorer doesn't really start a new program, there's no way to get an Explorer running with an administrative token.

Now, it was once possible to run multiple independent copies of Explorer on a system, but apparently Microsoft's removed the capability due to some low-level philosophical security reason. So sadly there's no way to create a "floating Explorer." Bummer.

You Can't Get Past the Consent UI

One tip you're probably looking for is "how can I create an icon that I can just click so that it'll start up with an administrator token?" You can't, not without turning off UAC altogether. The whole point of UAC is, again, to make you stop and be aware that you're doing something administrative before you do it.

What Tells Windows to Use the Administrator Token

As you've read, one way to convince Vista to give your application the administrator token rather than the standard user token is the right-click and "Run as administrator." But a little work with Vista will show that Vista raises the Consent UI quite a bit without any right-clicking involved. How does Windows Vista know before even running a program that it'll need the administrator token? In four ways:

• If Vista guesses that the program is installing an application, as installers pretty much always need to write to protected places in the Registry and on the disk, then it'll ask to be elevated.

• Developers can warn Vista that an application requires elevation by embedding something called a "manifest" into the EXE file itself, or putting a "manifest file" into the same directory as the EXE file.

• Vista's Explorer and Internet Explorer includes something called the "Program Compatibility Assistant" that looks for pre-Vista programs and then examines them for "compatibility issues," according to Microsoft. (That's all they've said.) If it detects them, then it'll pop up a box asking the user if it's okay to mark the application as requiring elevation. If the user agrees, then PCA stores that pre-Vista program's elevation needs in the Registry and from that point on, whenever the user runs the program, the Consent UI will appear.

• Vista contains a large database of information about older applications in something called the Application Compatibility Database. In that database, it's got a list of applications that will fail unless elevated. If you run one of those apps, then UAC will pop up the Consent UI.

That's not as complicated as it all looks, and understanding it may allow you to solve a passel of problems getting pre-Vista apps to work more smoothly. Let's take each point in turn, with a couple of side trips to see how Vista uses the GUI to offer feedback about what does and doesn't need elevation.

Vista Looks for Installers

You very rarely run across an application installer that doesn't need administrator-level privileges. Badly designed installers write things to Windows\System32, and standard users only have the permissions to read, execute, and list the contents of things in the System32 file, so you'd need to be an admin to install an app that did that. Better-designed installers still need to write to Program Files, which gives standard users the same permissions that System32 does, and to write to some subkey of HKEY_LOCAL_MACHINE\SOFTWARE or HKEY_LOCAL_ MACHINE\SERVICES, neither of which let standard users write to them. So, instead of letting an installer blithely try to do one of those things and fail, UAC tries to guess when you're running an application whose job is basically to install another application.

Now, in the computer business we don't actually say "guess"; that sounds sort of flaky. Instead, we say that an application evaluates probabilities based on "heuristics." Now, I'll save you the trip to the dictionary: heuristics are just what most of us would call "rules of thumb." UAC's rules of thumb for smoking out an installer? Two main approaches: look at the name of the EXE and recognize popular installer types.

Rule number one: if the phrases "setu," "instal," or "update" appear in the name, then raise the Consent UI. Yup, it's just as simple as that, and it's a good set of guesses. Wait, you may be thinking, doesn't that mean that bad guys can just rename their setup programs and slip past UAC? No, not at all-this isn't a feature to deter bad guys, it's a feature to save good guys some trouble. Again, if I were to rename "setup.exe" to "bananas.exe" then sure, I wouldn't get the Consent UI, and Vista would happily run bananas.exe…and then watch it crash when it tried to poke around Program Files, System32, or the Registry.

Rule number two: most installation packages were created with either the Wyse installer or the Installshield installer. In case you don't recognize those names, they're very popular thirdparty applications that simplify the process of creating a program that installs an application. Both Wyse and Installshield's setup programs have very distinctive "looks" to them and are easy for UAC to detect.

Rule number three: if a suspect application is marked with a UAC-aware "manifest" (which we'll cover soon), then don't bother applying either the first two rules, and just let it run as a standard user.

You can see the first rule in action. Just take any innocuous and pre-Vista EXE file that runs without needing an administrator token; rename it to setup.exe and all of a sudden it'll start popping up the Consent UI every time you run it.

For example, try this.

1. Copy the calc.exe program from a copy of Windows XP to a Vista box.

2. Run calc.exe; you will see no Consent UI and XP's Notepad will start right up.

3. Now, rename the XP calc.exe to “setup.exe. Now run it. You'll see, the Consent UI pops up every time you run the XP Calculator. In contrast-and in keeping with rule 3-try copying the Vista calc.exe somewhere and rename it as setup.exe, then run it; no Consent UI, and it runs just fine.

Tip 

You can, if you want, tell Vista not to try to automatically detect and elevate installation programs with a group policy setting, "User Account Control: Detect application installation and prompt for elevation," as you'll read later in the section "Reconfiguring User Account Control."

UAC and the Vista GUI

By the way, if you tried that, then you might have noticed something like Figure 2.6.

Figure 2.6: The Consent UI in another guise

It's just one example of how UAC uses the Vista graphical user interface either to signal you how closely to examine a Consent UI prompt, or to warn you that a particular app will require elevation.

Vista's "Alertness Warnings"

First, let's look at what I call the "alertness warnings." There are actually four different dialog boxes used by the Consent UI in response to different levels of how cautious Vista thinks you should be about elevating a program, using different colors to provide more visual cues to the amount of "alertness" that Vista recommends. Inasmuch as our publisher prints this book in black and white, you can see a change in the Consent UI's dialog box, but you can't see a change in color. The Consent UI that I showed you in Figure 2.1 has a bar across the top that is teal (a blue-green). The one in Figure 2.6, in contrast, has a bar across its top that is orange. The colors work like this:

• If the program is signed and from a publisher that you've blocked via group policy, then the bar across the top of the dialog box is red, and the bar contains a red copy of the little shield icon that Microsoft's been using since XP SP2 to designate security matters. It does not offer you a "confirm" button, just an "OK."

• If the program that needs elevation is digitally signed by Microsoft as an integral part of Vista, then you'll see the Consent UI that you saw back in Figure 2.1, with a teal bar across the top and a red, green, blue, and yellow shield icon.

• If the program that needs elevation is digitally signed and the signature checks out, but the application has not been signed by Microsoft as being integral to Vista, then you'll see a dialog like the teal one, but instead of teal on the top bar you'll see gray. It has a gray shield icon and both the Confirm and Cancel buttons. This is the Consent UI dialog that you'll most commonly see from third parties and even from many things at http://www.microsoft.com/downloads.

• Otherwise, you'll see the dialog in Figure 2.6, with an orange bar across its top and a red shield icon. There aren't buttons per se, just the new-to-Vista tile-like "big buttons" that pretty much offer Confirm or Cancel, but with more verbiage.

It's probably a good idea to add "introduce users to the different Consent UI dialog boxes" to your "things to tell users when introducing Vista." And I guess it was a good idea for Microsoft to include it in Vista…I just wonder how color-blind folks will feel about it?

By the way, if you ever walk away from a Vista box when the Consent UI is raised without responding to it, then after two minutes, the Consent UI will close with a dialog box like the one in Figure 2.7.

Figure 2.7: UAC timed out!

The theory behind this is a simple one. If the Consent UI is up, then whoever's logged on is an administrator. If no one's responded to the Consent UI after two minutes, then the operation is either unimportant or, more disturbing, this machine that an admin's logged into is unattended…yikes! So Microsoft basically "times out" the UAC prompt.

UAC's Clues: Will This Need Elevation?

A big part of the whole idea behind UAC, it seems, is to clarify when we do and do not have to act as administrators. As I observed earlier in the chapter, a big part of moving away from the point of view that we need to be logged in as admins all of the time stems from the fact that, well, I don't know about you, but I'm often not quite sure what does and doesn't require administrative permissions and privileges. For example, do I need to be an administrator in order to shut down a system? Well, the answer is "it depends." If we're talking about a workstation, then anyone can shut it down. But if we're talking about a domain controller, then you've got to be a member of any one of a few groups to be able to shut it down. Or how about being able to adjust power management settings? I'd have assumed that anyone could do that sort of thing, but the fact that Microsoft specifically reprogrammed Vista in Beta 2 to allow standard users to change power management means that my guess would have been wrong.

To help us become more "admin-aware" and, I guess, to warn standard users about what they can't do so as not to deliver unpleasant surprises, Microsoft has begun suggesting that developers add the four-color shield icon to any button or other graphic that will, if clicked, do something that will require elevation. For example, take a look at Figure 2.8.

Figure 2.8: The Administrative Tools folder, with and without shields

Here, I've taken the Administrative Tools folder from Control Panel and cranked up the icon size to "Large" and, in case you're wondering, there is an "Extra Large" in Vista. Notice that on the Disk Defragmenter, Memory Diagnostics Tool, and System Configuration icons there are smaller icons of the four-color shield superimposed on the larger icons. These are intended to be the visual cue-or warning, depending on how you see it-that Beyond This Place Standard Users May Not Go.

Now, while it's a good idea, there's no guarantee that you'll actually see a shield where there ought to be one. For example, looking at the Disk Defragmenter icon on the Start menu at All Programs Accessories System Tools shows-well, looking very closely shows, anyway-that the little shield icon is, indeed, still there, although I don't imagine that many will notice or even be able to see it on the small Start menu icon. Similarly, look again at Figure 2.8. Don't you need to be an administrator to mess with Windows Firewall, or Print Management, or other items in this group in order to do anything? Sure; clearly that's why it's called the "Administrative Tools" group, and in fact a quick double-click of everything there will show that each of those items causes the Consent UI to ask for elevation. But there are only shields on three of the 14 icons in this group…why? Probably because the three icons with shields point to EXE files, and the other 11 point to MMC snap-in files. You see, Vista is smart enough to sniff around a program and, if Vista guesses that it'll need elevation, then Vista adds a shield icon automatically.

You can see this by just doing the exercise that I referred to in the earlier section where I suggested copying calc.exe from a copy of any version of Windows prior to Vista to a Vista machine and then renaming calc.exe to "setup.exe." That causes a Vista heuristic to kick in, and Vista's Explorer will add a shield icon to the setup.exe file icon.

Vista can't, however, detect a need for elevation in an MMC snap-in. That's because Explorer doesn't directly run MMC snap-ins-MMC.EXE does. It's got a shield icon, but that doesn't really help much, as the curious user usually wouldn't open MMC.EXE to explore MMC snap-ins; instead, the curious user would just see icons in Control Panel and the Start menu. Perhaps that'll change in later Vista builds or later versions of Windows.

A third place where you'll see shields is in Control Panel applets. Open up Control Panel and you'll see something like Figure 2.9.

Figure 2.9: Opening Control Panel window

Look in the upper right-hand corner of the Control Panel window, under User Accounts and Family. You'll see two hyperlinks, "Set up parental controls," and "Add or remove user accounts." Notice that they've both got shields next to them. As far as I can see, those aren't automatic.

Summarizing, then, Vista tries to alert users to which programs require an administrator token to run by superimposing a shield icon on the icon associated with that program. That works sometimes either because Vista sensed that the icon needed it and added it, or because the developer remembered to put the shield on the program's icon. But you can't count on it being there. Nevertheless, it's a good start at making people more aware of what they do that's administrative in nature.

Vista Requests Elevation if a Manifest Requests It

Let's return to our examination of what causes Vista to request elevation and learn about the most surefire way to tell Vista that an application needs elevation. You will sometimes really want Vista to know that an application needs elevation because while those UAC prompts can be annoying, it's even more annoying when you try to run something, only to get "access denied" halfway through the process. So if we're going to use UAC, we may as well ensure that it does the right thing, and the simplest way to ensure that UAC does the right thing is to tell it what to do. Developers (and we admin types, once you know a few tricks) can do that with something called manifests.

What Manifests Are and What They Do

Manifests are small text files associated with an application that tell the operating system how to load and run that application. They can be embedded inside an executable, or they can exist as separate, external text files of the kind that you can edit with Notepad. I wouldn't claim to be a coding expert-I'm not-and so I may be explaining this incompletely, but three things that I know that various versions of Windows have done with manifests have been to

• Tell the operating system which version of a dynamic link library (DLL) the application needs,

• Tell the operating system whether or not it's okay to build the application's windows using the rounded-edged XP windows theme, and

• Tell the operating system which token an application needs: the standard user token or, if one's available, the administrator token.

The original manifests appeared in XP, which also introduced a thing called "Windows Side by Side," which was the first big user of manifests. Side By Side was supposed to alleviate the problem known as "DLL hell." But first, a little background….

When developers create programs, they tend not to put all of the program in one big file. The reason that they don't create one big file is that anyone who writes more than a couple of programs soon finds that very different programs often share the same code challenges: both word processors and games may need to print things, or sort a list, or encrypt data, to name a few possibilities. Programmers make their jobs easier by taking those often-reused program parts and putting them in what is essentially a library of programs. As these library routines might be shared by a number of programs, it'd be silly to copy and paste the library routines into every program that uses them. Instead, these libraries of useful programs live in separate files of their own called "dynamic link libraries" or DLLs. Their file extensions are usually ".DLL" as well. To make programmer's lives easier, Microsoft packages a bunch of DLLs right in Windows. For instance, have you ever noticed that the File Open dialog box looks pretty much identical on every program that you run? That's because it'd be a pain for every single programmer to have to cook up her own File Open dialog box, and so Microsoft ships a file called "comdlg32.dll" that contains the pre-built code for a number of commonly used dialog boxes, including File Open. Lots of apps not ever written by Microsoft rely on comdlg32.dll to get anything done.

But in order to keep improving, fix bugs, and keep up with new operating systems, DLLs change. That can be a good thing, as it was for most developers when XP came around. Recall that XP introduced the notion of "themes" whereby you could have window frames with rounded edges. Microsoft built rounded-edge dialog boxes into the XP version of comdlg32.dll, with the interesting side effect that running most NT 4.0 or Windows 2000 applications under XP would give those older apps an immediate "facelift."

Not every application, however, liked the new look, and the new comdlg32.dll blew up some older apps. By default programs find their DLLs by their names, and so comdlg32.dll has been called "comdlg32.dll" since NT 3.1, if I recall right. Now, most folks thought that the rounded window edges were pretty neat, but, again, some didn't, as those rounded window edges broke some important apps, and so those folks wanted Windows to leave their window edges square-to run with the old comdlg32.dll, in other words.

How, the question arose, could you have two copies of comdlg32.dll on the same computer without one clobbering the other? The answer was "Side by Side." Suppose you've the unlucky developer of an application that didn't like XP's comdlg32.dll dialog box. With Side by Side, you could ship your application with the old version of comdlg32.dll, and either rename the DLL so it didn't try to overwrite the one shipped with XP, or you could put it in another folder; either approached worked. But now how does your app that needs the older Windows 2000 version of comdlg32.dll know where to find it? Answer: a manifest. When the OS sees your application needs comdlg32.dll, then it looks for a manifest to see which comdlg32.dll to pick up. If there's no manifest, or if the manifest is silent about comdlg32.dll, then the app goes to the default; if not, then it gets hooked up with the comdlg32.dll that it needs, the older version.

You can either embed a manifest right into an EXE (or, for that matter, a DLL) file using code development tools, or you can just write up the manifest in Notepad and save it as a simple text file. If you do that, then you tell the operating system to associate a given manifest file with a particular application by doing two things.

• First, the manifest file goes in the same directory as the EXE file.

• Second, the manifest file must be named something.exe.manifest, where something is the name of the EXE that it applies to.

So, for example, if I'd written a program called greatgame.exe and that file lived in C:\Program Files\MarkSoft\Coolgame, then the manifest would have to be called greatgame.exe.manifest, and it, too, would have to be located in the C:\Program Files\MarkSoft\Coolgame folder in order to take effect. If your app has both an embedded and an external manifest (that is, one stored in a separate text file), then Windows ignores the external manifest.

You can see also how manifests might solve problems arising from Microsoft's monthly hotfixes. Consider what would happen if you'd written an application dependent on some Windows DLL, but then Microsoft detects a security problem with the DLL and fixes it, but the fixed DLL breaks your code. You could tell clients to store the older version of the DLL in some directory and give them a manifest to use the old DLL, assuming that there weren't an embedded manifest in the file already. That way, they can install the patch instantly, be protected from the vulnerability when running 99 percent of their apps but still be able to run your app until you get it revised to work around the new problem. (Microsoft's Knowledge Base article 835322 discusses this.)

Over time more and more things got stuffed into manifests, but it is still Windows Side by Side that manages manifests, so any error messages relevant to manifests show up in the Application folder of Vista Event Viewer as errors whose source is "SideBySide."

Examining Manifests

Let's take a look at a working manifest. We'll examine an embedded one, the one in net.exe. But before we do that, we'll need something that lets us look at manifests; for that, we'll need something called a "resource editor." (When you embed a file inside a program, as we do when embedding manifests, they are said to be "resources.") There's a nice free one called the XN Resource Editor that you can find at http://www.wilsonc.demon.co.uk/d10resourceeditor.htm. If it's not there anymore as you read this, then just Google "XN Resource Editor." (To paraphrase Heraclitus, "you cannot search the same Web twice, for links go dead and new junk is added to it all the time.")

Install the XN Resource Editor on your system and start it up. It'll look like Figure 2.10.

Figure 2.10: Opening screen on XN Resource Editor

To work this, you just point it at an EXE file. It opens the EXE file and looks for any resources and, if it finds any, then it shows them as numbers "1" through however many resources are in the file. To look at net.exe, click File Open, and then in the field "File name:" fill in c:\windows\system32\net.exe. XN Resource Editor will then look like Figure 2.11.

Figure 2.11: XN Resource Editor with net.exe loaded

Click the plus sign to the left of "XP Theme Manifest" to reveal a folder labeled "1"-there is only one resource in net.exe-and click the plus sign next to it to expand the folder to reveal the manifest, as you see in Figure 2.12.

Figure 2.12: net.exe's manifest

The manifest is written in XML, which looks a lot like HTML. Most of it we can ignore; I want to focus on the part on the bottom, which I've reformatted and edited a bit here:

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

You don't have to understand XML to follow this because we're just interested in that line:

 level= "asInvoker" 

Now, there is one thing about XML that you've got to understand: it cares about case. Changing "requestedExecutionLevel" to "requestedexecutionlevel" would make this manifest erroneous and you'd get one of those SideBySide errors that I referred to before.

That level= is the place where a developer (or an admin who's willing to do a bit of resource hacking, and you'll see how soon) can signal UAC that a particular application needs to be elevated. level=-remember, that lowercase l at the beginning is essential-can take three possible values:

• asInvoker means "just give me the same token as the person who started me." That works for net.exe because if all you want to do with net.exe is just browse your workgroup-which anyone can do-then you can type net view and it'll work fine with a standard user token. If, on the other hand, you want to do something that requires the administrator token, like creating a user account, then you need to first have an elevated command prompt running, and then you can issue the net user command, as net will inherit the token that the command prompt's already got, the administrator token.

• highestAvailable means "please give this process the highest token the user possesses, and if necessary please raise the Consent UI to get me that token."

• requireAdministrator means the same thing as "highest available," except that it adds "but if the user isn't a member of the Administrators group, then don't bother, I need an administrative token and if this guy isn't an admin, then he can't help me; just fail this application."

What's the difference between the last two? It's possible that an account may have a split token, but that neither token possesses administrator-level power. (It's possible; offhand I can't think of why that'd happen.) So to mark an EXE file as requiring an administrator-level token, then ensure that its manifest includes level"requireAdministrator."

Note 

I know, there's that other parameter uiAccess"false" that I've not explained here. I'll get to it later, but here's the short version. There is a special class of applications that need to work with the Consent UI called "UI automation" applications. They use the uiAccess parameter to alert UAC to their UI automation-ness.

Adding a Manifest with a Resource Editor

Armed with this information, we could equip an older application without a resource with a UAC-aware one. In fact, there are three ways to do it.

First, we can use our resource editor to put a manifest with a level"Administrator" instruction right into an EXE file. Before we start, we'll need an EXE file without a manifest. If you can't find one handy, then do this:

1. Open a command prompt. (Do not elevate it.)

2. Create a folder c:\mystuff by typing md c:\mystuff and press Enter.

3. Navigate to c:\mystuff by typing cd c:\mystuff and, as always, press Enter.

4. Open up Internet Explorer and visit my website at http://www.minasi.com/vista/vistafiles.zip. It'll let you download a ZIP file containing files and programs that you can use to experiment with UAC, file virtualization, and Windows integrity control. Download the files to C:\mystuff.

5. In Explorer, navigate to c:\mystuff. Right-click vistafiles.zip and choose "Extract all…" and tell Vista to extract files to c:\mystuff.

6. One of the files will be a program called "simple.exe," which is the world's simplest C++ program. It's a command-line program that you run by just by typing simple. It prints on the screen This is a program that just puts this text on the screen (and yes, I'm fully aware that I do not have a future in high-tech commercial programming). When prompted where to put it, tell IE to put it in C:\mystuff.

7. Give it a try just to verify that it does not cause the Consent UI to pop up in its initial form.

8. Type copy simple.exe mansimple.exe so that we've got a copy of simple.exe around without a manifest-we'll embed a manifest into mansimple.exe.

Then follow these steps to add a manifest to simple.exe:

1. Start up XN Resource Editor.

2. Click File Open, navigate to c:\mystuff and open mansimple.exe.

   You'll notice that the pane on the left, which showed you net.exe's resources before, is completely empty now. That's because simple.exe has no resources.

3. Click Resource Add Resource.

4. In the "Add Resource" dialog that appears, choose "XP Theme Manifest" and click OK.

   On the left-hand pane, you'll see "XP Theme Manifest," "1," and "Language Neutral." On the right-hand side, you'll see some XML.

5. Mark the text in the right-hand side pane and then press Del to clean it all out.

6. Notice that in c:\mystuff\manifests is a file named "example.exe.manifest." It's the world's simplest manifest file.

7. Open it in Notepad.

8. Copy the text from Notepad to the right-hand pane of XN Resource Editor.

9. Click "XP Theme Manifest" in the left-hand pane.

10. Click File Save.

11. Exit XN Resource Editor.

    When you next run mansimple.exe, it'll cause the Consent UI to pop up.

Adding an External Manifest

The second approach is even easier. Take the simple.exe.manifest file that you got from my website and copy it into the same directory as simple.exe. If simple.exe does not have an embedded manifest, then Vista will read and use that external manifest. In other words, you add an external manifest for a given program, call it example.exe like so:

• Create the manifest for example.exe. If the manifest's only purpose is to cause UAC to elevate the app, then open Notepad and just type this in:

        <?xml version="1.0" encoding="UTF-8" standalone="yes"?>      <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">      <assemblyIdentity version="1.0.0.0" processorArchitecture="X86"      name="Anyapp" type="win32"/>      <description>Basic manifest</description>      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">      <security><requestedPrivileges>      <requestedExecutionLevel level="requireAdministrator"/>      </requestedPrivileges></security></trustInfo></assembly> 

  Be absolutely sure to follow the case of the commands when typing this manifest. Alternatively, simple.exe.manifest will work fine as something to copy when you need to create a manifest.

• Name the manifest file example.exe.manifest.

• Place the manifest file in the same folder as example.exe.

This manifest will now affect how Vista runs example.exe, provided that there is not a manifest already embedded in example.exe. You can find out if an executable file contains a manifest by examining the file with a Windows resource editor, as described earlier.

Warning 

As late as RC2, Vista did not always notice external manifests; putting a valid example.exe.manifest file in the same folder as example.exe didn't always work. Embedded manifests always worked, but including an external didn't always work. So here's a workaround that seems pretty reliable, using another program from vistafiles.zip as an example.

It can be infuriating trying to get Vista to notice that there's an external manifest for a file, at least in RC2. I seem to have found a workaround, though: create a folder and then copy both the EXE file and the manifest into that folder, then run the EXE from there. Here's a step-by-step example. Notice that one of the files extracted from vistafiles.zip is named "show.exe." It displays a file's contents on the screen, like the type command. We'll create an external manifest for that. As before, work from the unelevated command prompt in the C:\mystuff folder.

1. Create a folder called "test" in c:\mystuff by typing md c:\mystuff\test and press Enter.

2. Copy show.exe to that folder by typing copy show.exe test and press Enter.

3. Copy the example manifest to test, but rename it to show.exe.manifest by typing copy example.exe.manifest test\show.exe.manifest and press Enter.

4. Change to the C:\mystuff\test directory by typing cd test and press Enter.

5. Type show and press Enter.

6. You should see an "Open File-Security Warning" dialog asking if you really want to run show.exe. Click Run.

UAC should then raise the Consent UI, so we've proven that the Vista noticed the external manifest. Click Cancel and let's look at one more thing that Vista does when it detects a manifest that requests elevation. Open up Explorer and navigate to c:\mystuff\test. Click the Views button until you can see the icon for show.exe. Notice that Vista's given it a shield!

Embedding a Manifest with Manifest Tool

The third approach uses a command-line tool to stuff an external manifest into an EXE. (It'll even overwrite an existing one if there's one there.) It's "Manifest Tool," a command-line tool mt.exe. You can get it from Microsoft, although you'll have to download a lot of stuff to get it. (There are other ways to download it, but they're all fairly complicated; what I'm going to show you seems the easiest way.) Manifest Tool ships with the Windows Platform SDK. I find that it's easiest to get with Visual Studio 2005's free version, Visual Studio Express 2005. Here's how to get the free version.

1. Open your Web browser and surf to http://www.msdn.microsoft.com/vstudio/express/, which is the home page for Visual Studio Express. If that URL doesn't work-there is someone at Microsoft whose job is apparently to rearrange their website every week or so-then Google "download visual studio express" and you'll find a link to wherever Microsoft's got Visual Studio Express 2005 that week.

2. You have several choices of versions of Visual Studio 2005: a Web developer edition, one for Visual C++, one for Visual Basic, and one for Visual C#.

   Note 

   If you're not a coder, "C#" may not have an obvious pronunciation; as a would-be successor to C++, Microsoft opted to use the octothorpe (#) symbol, which kind of looks like two plus signs engaged in unnatural acts. If you're musically inclined then you may know that the music world uses the octothorpe to designate a sharped note, which explains why that particular variety of C is said "C sharp." This falls in the category of "programmer humor."

3. I found that "Visual C# 2005 Express Edition" did not deliver mt.exe, but "Visual C++ 2005 Express Edition," did, so let's go with that one in our quest for the Manifest Tool.

4. Under the hyperlink for "Visual C++ 2005 Express Edition," which is under the heading "For Windows Development" in the middle of the page, click the Download hyperlink.

5. That'll bring you to another page, which will instruct you first to remove any previous versions of various things, and then offers a Download link. Click that.

6. At the "File Download-Security Warning," click the Run button.

7. If you're doing this on a Vista system, then you'll get a UAC confirmation box; confirm that you do indeed wish to run the setup program by clicking Continue. (Notice that the banner is gray because while it's signed and even from Microsoft, it's not an essential part of Vista.)

8. You'll finally come to a Setup wizard. Click Next to go to the next page.

9. Accept the "License Agreement." (I guess they capitalize it so that you know that they mean business, buster, so you'd better not go around redistributing their program which is, ummm…free.) Click Next.

10. The next Installations Option page will offer to download even more stuff to your computer. Leave the SDK and SQL boxes unchecked and click Next.

11. Check that you're fine with the destination folder and click Install. That'll kick off the actual download of Visual Studio C++ 2005 Express Edition, which is about 35 MB.

12. Once the download's done, click Exit and close the Web page that you downloaded Visual C++ from.

If you let the installation wizard put the files where it wanted to by default, then you will now find mt.exe in C:\Program Files\Microsoft Visual Studio 8\VC\Bin on a 32-bit version of Vista, or, on a 64-bit version, you'll find it at C:\Program Files (x86)\Microsoft Visual Studio 8\VC\Bin. Copy that somewhere and you've got your Manifest Tool. If you want to recover that disk space that Visual Studio burned up, just uninstall all of the Visual Studio components. (Why you can't just download mt.exe is a puzzle to me.)

You can now tell mt.exe to insert a manifest file into an existing EXE file with this command:

 mt /manifest NAMEOFMANIFEST/outputresource:EXEFILENAME;#1 

For example, you could embed simple.exe.manifest into simple.exe like so:

1. Ensure that mt.exe, example.exe.manifest and simple.exe are all in c :\mystuff.

2. If you don't have a command prompt open, open one and navigate to c:\mystuff.

3. The files in vistafile.zip all get a "read only" attribute, so let's get rid of that by typing attrib -r * and pressing Enter.

4. Copy simple.exe before we manifest it, so we've got a manifest-less simple program to play with later by typing copy simple.exe nomanifest.exe.

5. Type mt /manifest example.exe.manifest /outputresource:simple.exe;#1.

That mt command should be typed as all one line. Notice that mt 's syntax is a bit irregular, inasmuch as there's just a space between /manifest and simple.exe.manifest, but there's a colon and no space between /outputresource: and simple.exe;#1-that wasn't a mistake on my part, that is the syntax.

Once you've embedded the manifest into simple.exe, then you'll always get the Consent UI whenever you run it, regardless of whether or not simple.exe.manifest is in the same directory as simple.exe; as a matter of fact, now that simple.exe has an embedded manifest, then Vista will ignore any external manifests.

Embedding Manifests Can Break Digital Signing

Now that you've seen two ways to embed a manifest in an existing EXE file, should you? Not always. Embedding a manifest changes the content of the EXE, and that renders any existing digital signatures invalid. Not everyone understands exactly what's happening with signed program files, so here's a quick review.

When Windows starts up a driver, program, or whatever, it identifies that executable by its file name. But what if a piece of malware infested your operating system by erasing some important piece of Windows code like, say, RPCSS.DLL and replacing it with itself? As Windows starts up RPCSS.DLL (the thing that provides Remote Procedure Call, the thing that lets, among other things, Outlook talk to Exchange) automatically, that'd be a great way for a piece of malware to ensure that it got started up every time you started the computer.

To combat that, many operating systems use digital signing to allow developers to prove cryptographically which developer created a piece of code. Here's how it works.

A developer finishes work on a particular program, whether it be an EXE, DLL, driver file, or whatever. (Let's say for this example that it's an EXE file.) He then uses a cryptographic function that takes megabytes and megabytes of data and boils it down to a single unique 128-bit key. (Most code signing approaches that I've seen either employ MD5 or SHA-1, two popular hashing algorithms.)

The basic idea at this point is that you can verify that it is indeed the program that he wrote whenever you'd like. You just take the EXE file and use it to create an MD5 or SHA-1 hash from that file. Then compare it to the hash that the developer says he computed. If they're the same, then you can feel pretty sure that the copy of the EXE that you've got is identical to the one that the developer created-so it wasn't damaged in transmission and, more important, you don't have a copy that someone infected with some kind of malware. And I said "pretty sure" rather than "completely sure" because there is a tiny, tiny, minuscule chance that someone modified that EXE file but the modified file generated the same hash as the unchanged one, but that's a pretty long shot.

Well, that's the idea behind signing, but you can probably see the flaw here. Who wants to have to go download a hash value from a developer, then compute a hash for the downloaded EXE, and compare them? Sounds like too much work and, even then, someone might have successfully spoofed the developer's website, and you'd be getting some kind of bad data-either a bum EXE or a bum hash, or both-anyway. So we add a few steps to the process.

First, the developer goes to a digital certificate vendor like VeriSign and buys a kind of certificate called a "code signing certificate." He asks his computer to generate a public/private key pair and sends that along to VeriSign. VeriSign checks him out and verifies that he is who he claims to be, collects a few hundred bucks (repayable annually to VeriSign) and generates a certificate for him with his public key embedded in that certificate. Now, when he computes the hash on an EXE, he can take that hash value and encrypt it, using his private key. He then embeds the encrypted hash and the certificate the VeriSign created for him into his EXE…and now things can get automatic.

When you get a gray or teal banner on a Consent UI, it means that Vista looked at the EXE that seems to need elevating and saw the certificate and encrypted hash. (If there wasn't one, then you get the orange-banner Consent UI.) Vista computes a hash based on all of the EXE file except for the certificate/encrypted hash combination. Then it uses the public key embedded in the certificate to decrypt the hash that Vista found in the EXE. If the computed hash and the newly decrypted hash match, the EXE has been properly signed. If so, then the Consent UI offers a gray or teal banner. If not, it's orange-banner time.

Digital signing is not a panacea. Signed code could still offer a couple of problems. First, digital signing is not a guarantee of high-quality code. Lots of code signed by Microsoft and other large vendors has horrendous bugs. But at least you know for sure who wrote the code, and so you can be reasonably sure if it's a firm like Microsoft, IBM, Adobe, or whomever that they didn't deliver you malware on purpose! Further, digital signing is not a guarantee that there is no malware in the code. If the coder built his application on a system that was infected with some kind of malware, then the malware might have infected his newly built application as well. But, again, you can feel pretty certain that it wasn't his intent to send you infected stuff. But that's not necessarily so, as VeriSign doesn't check out a person to see if he or she has created malware in the past or has a criminal record before issuing him or her a code signing certificate.

There are two great strengths to digital code signing. First, you know with a very, very high degree of certainty who released the code. (Not a certainty because a vendor could have its code signing certificate keys stolen.) That's important because while it's entirely possible that a bad person might take the time to write some bad software, get a certificate, sign the software, and give it away, he'll only get away with it once. (And perhaps not even then, as the authorities may be able to locate and apprehend him based on information he had to provide to get the certificate.) From that point on, he'd have a reputation as a criminal and the prospect of convincing someone to install software signed by him would be nil. Second, and more important, the operating system can use code signatures to verify that the files containing vital operating system components haven't been modified since they were created. This is a big advance in security in the Vista world, as Vista checks the code signatures on every low-level piece of software every time it boots. (You'll read more about that in a later chapter.)

Well, that was a fairly long (but, I hope for some, valuable) side trip, but here was the point of it. As an embedded manifest is part of an EXE, modifying it with a resource editor would have the same effect as infecting that EXE with a piece of malware: it would cause the digital signature to fail. Once that happens, the "Digital Signatures" tab goes away, and the program would not pass a signature verification.

What would that mean in practice? Well, remember that the reason we'd consider adding a manifest to an EXE would be so that operating system would know to request elevation whenever someone ran that EXE. Such an EXE is likely not to have either a digital signature or a manifest in the first place, and so has nothing to lose by getting a manifest. (Certainly none of my small example programs are signed.) Still, keep that in mind before manifesting your desire for automatic elevation requests!

Tip 

Creating signed programs is a bit more work, but in the long run we'll probably see all new applications signed. At that point, you may consider enabling the group policy setting "User Account Control: Only elevate executables that are signed and validated." I'll discuss that in more detail in the later section "Reconfiguring User Account Control."

The Program Compatibility Assistant Tells UAC to Elevate

You read earlier that UAC uses heuristics like words in a program's name, or telltales that a program was generated by popular installer makers, and when it sees those heuristics then it assumes that it's dealing not just with any old application-it's working with a Setup program. But Vista takes things a bit further to ensure compatibility. It reasons that if that was a Setup program of some kind, then there must be a record of the program's having installed something, the kinds of traces left behind that allow you to use the Control Panel's Add/Remove Programs to see what programs have been installed, and, further, how to remove them. If Vista doesn't think that it ran correctly, then it raises a dialog box called the "Program Compatibility Assistant" that basically says "hey, did everything come out all right here, or should we try it another way next time?," as you see in Figure 2.13.

Figure 2.13: The Program Compatibility Assistant

What exactly will happen if you click "Reinstall using recommended settings?" To see, look back at Figure 2.5. That's the "Compatibility" tab that you'll find on pretty much any EXE that hasn't been specially marked as an essential Vista program-that is, any program that wouldn't get a teal bar across the top of its Consent UI. It lets you quickly and easily solve a number of the most common solutions to "hey, this program ran fine on Windows 95/Windows ME/XP/whatever and it won't run under Vista." For example, since the dawn of computing, there's always been applications hard-coded to only run on, say, Windows 95, even though they'll run just fine on Vista. The "Compatibility" tab includes a drop-down list box labeled "Run this program in compatibility mode for," and offers Windows 95, 98, Me, NT 4.0, Windows 2000, XP SP2, or Windows Server 2003 SP1; checking the box and choosing "Windows 95" would make that hypothetical I-require-95 application to run fine on Vista. The Compatibility tab will also let you tell your Vista Desktop to simplify both the screen and the way that it refreshes the screen, as you can check boxes to hold Vista to 256 colors, 640 × 480 screens, rescaling and desktop composition (that thing that lets Vista allow you to drag windows all over your Desktop without leaving those "skid marks" behind), or disable visual themes altogether. If some of that sounds familiar, it should: XP also had a "Compatibility" tab, although it offered fewer options.

Note 

You actually have many more options in terms of compatibility fixes, hundreds in fact that you can explore with the Application Compatibility Toolkit (ACT). ACT's a much bigger story than can fit here, though, so the Compatibility tab is basically "ACT lite."

When the Program Compatibility Assistant thinks that an attempt at installing a program fails, it will make some educated guesses about what setting it might make on the Compatibility tab. Then it'll rerun the setup program with its guesses; that's what happens if you click "Reinstall using recommended settings."

The Program Compatibility Assistant could become sort of annoying if it popped up every time that you ran a given program, so it's designed to remember what applications it has already examined and to ignore them from that point on. It keeps its list of applications that it has examined in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\ AppCompatFlags\Compatibility Assistant\Persisted. In that key, it creates an REG_DWORD entry for every application that it has examined in the past, setting the entry name equal to the full path of the application's EXE file, and sets that entry to 1. If the Program Compatibility Assistant ends up also checking some of the options on the Compatibility tab for that application, then they're stored nearby in HKEY_CURRENT_USER\Software\Microsoft\ Windows NT\CurrentVersion\AppCompatFlags\Layers. Once again, it creates a separate entry for every application (although this time it's a REG_SZ rather than a REG_DWORD), with that entry's name equal to the full path name of the application's EXE file. In the value, it fills in the names of the compatibility modes applied. For example, if it decided to select the XP SP2 compatibility mode, then the phrase "WINXPSP2" appears in that Registry entry. In addition to those Registry settings, I've found that there's a key corresponding to the Layers key, but in HKEY_LOCAL_MACHINE rather than HKEY_CURRENT_USER.

I know, that was a lot of yackety-yack and, God willing, you won't have to deal with the Program Compatibility Assistant. But if you'd like to see it just once in action to see the dialog box and verify what goes in the Registry, try this.

1. Open a command prompt and navigate to c:\mystuff.

2. We'll need a copy of simple.exe without the manifest to play with, so type copy nomanifest.exe installer.exe. As you see, we're creating a simple program that will raise UAC's hackles and cause it to raise the Consent UI.

3. Type installer.

4. UAC, true to form, will raise the orange Consent UI dialog box. Click "Allow/ I trust this program…" and the c:\mystuff prompt will appear after another command prompt window-one with elevated privilege-will briefly appear and disappear.

5. In a few seconds, the Program Compatibility Assistant dialog will appear. Click either option, it doesn't matter as we're not really installing anything.

6. Next, verify that the Assistant does indeed remember which programs it has tried to help in the past. Type installer and you'll still get the Consent UI, that's expected, but afterward you will not get the Assistant. Now take a peek in the Registry at HKEY_CURRENT_ USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\ Compatibility Assistant\Persisted and you'll see something like Figure 2.14.

   
   Figure 2.14: Half of the places where the Assistant remembers applications

7. Delete that entry, then go to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers, where you'll find an entry for installer.exe and a REG_SZ value of "WINXPSP2," which seems to be the catch-all value when the Assistant knows that something happened, but it's not sure what. Delete this entry too.

8. Close Regedit.

9. Once more, run installer.exe, let UAC elevate it, and you'll see the Assistant return.

That's how the Program Compatibility Assistant works, except for one thing: I said that it could cause UAC to request elevation on a program, but we didn't see that; when might it happen? Well, as you've seen, it isn't the Program Compatibility Assistant's job to tell UAC to request elevation, but it is the Assistant's job to analyze what it thinks are troubled programs and adjust the settings in the Compatibility tab as necessary. In some cases, I am told-I've honestly not seen it, but then I've only had time to run a few dozen pre-Vista programs on Vista-that the Assistant may check the "Run this program as an administrator" box. In that case, you'd see an elevation prompt every time that you ran that program from that time on. Notice, however, that the Assistant is very specific in its help. If you had a separate but identical copy of installer.exe in another folder, then the first time that you ran that copy, the Program Compatibility Assistant would have no memory of the fact that it's already seen and analyzed this program, but in a different directory. In contrast, adding a manifest to a file that requests elevation will work no matter what folders you copy or move that file to.

Note 

Don't confuse the Program Compatibility Assistant with the Program Compatibility Wizard. The Wizard is the icon that appears on the left-hand side of your desktop the first time that you start up Vista. The Program Compatibility Wizard is basically a wizard that you point at any program. Once you do that, the Program Compatibility Wizard basically asks you a few questions and then automatically checks boxes in the Compatibility tab for that program. Not very impressive, you say? I agree, and wish that it didn't clutter the desktop when just about anybody can right-click a program and bring up the Compatibility tab.

Application Compatibility Toolkit "Shims" Tell UAC to Elevate

The final thing that might lead to Vista's requesting to elevate a process is something called a "shim" created by something called the Application Compatibility Toolkit. You just read about the Program Compatibility Assistant, which is basically a process that pops up under certain circumstances and follows a set of rules to modify the Compatibility tab on EXE files for programs that are having Vista compatibility problems.

Now, it's nice that choosing, say, "XP SP2 compatibility mode" and "Run as administrator" on a given program's Compatibility tab can take a pre-Vista program and make it useful under Vista-great, in fact, given that I sometimes use programs that I don't trust but that I'd prefer not to have to upgrade because while the current version is a pain, at least it's a pain that I'm sure runs well enough for my needs. (Like, say, Quicken.) But suppose I need to deploy those settings to 1,200 computers or, further, what if I need fixes for more than the handful of compatibility solutions offered by the Compatibility tab?

Then you're in the market for the Application Compatibility Toolkit. The Application Compatibility Toolkit is a set of programs that apply what are sort of "online fixes" to programs with compatibility problems, fixes that make Vista happy and the old program happy. What I've called an "online fix" is officially called a "shim." The Application Compatibility Toolkit's shims are different from the Compatibility tab's shims in that you can create a package of necessary shims for any application and deliver that package of shims from a central location with group policies. Additionally, where the Compatibility tab has about a dozen possible fixes, the Application Compatibility Toolkit had over 210 the last time that I looked at it, although in truth many of them are now irrelevant because some of those features now live in Vista and kick in automatically.

The Application Compatibility Toolkit creates databases of fixes, and you can recognize them by their .SDB ("System DataBase") file extensions. For example, you'll find a big one called sysmain.sdb that ships with every copy of Vista. By default, Windows stores SDB files in \Windows\AppPatch. There are no tools built into Vista that will let you look at that database, and I wonder if they're very serious about supporting ACT on a 64-bit platform, given that the Vista-specific ACT 5.0 will not run on 64-bit Vista. But, if you're running a 32-bit version of Vista, then you can download the current version of the Application Compatibility Toolkit from Microsoft and take a peek at sysmain.sdb. I am not exaggerating when I say that there are literally thousands of applications in that database, and I would bet every cent that I have that you've never even heard of a tenth of them…so I can't, in any practical sense, tell you which applications sysmain.sdb will cause UAC to request elevation for. The Application Compatibility Toolkit is a separate download from Microsoft, and it's a big, big topic-too much to take on in this chapter.