LUA, UAC, and the split personality token

With Windows Vista, you now have UAC or "User Account Control", sometimes known as PA or "Protected Admin". What does this mean in a practical sense? Well, for instance let's say you take a domain account (or a new local account) and place it in the Administrators group. With all prior versions of Windows based on Windows NT, that would be it - that user would be an Administrator when they logged on and could install all the spyware and trojan horses they wanted. When they clicked on "<SomeFamousPersons>Boobs.jpg.exe", it could do anything it wanted to the system. The least likely thing it would do is display what it sounds like it would in the title, right? Now, your account won't really BE an admin - at least not all the time.

A different style of logon
The login process now creates two tokens. The normal one that in our sample case would have granted admin rights (this one is held onto by the kernel and used only when you need to elevate), and a new token - based on the standard one - that is used for UAC. This new token has the Administrators group set as a restricted group or "deny only". So if you run "whoami /groups", you'll see

"BUILTIN\Administrators S-1-5-32-544 Group used for deny only"

(I chopped a bit of extra text out of that to simplify it, but it's clear that the token has been restricted. If you were to then run a command prompt "elevated" (by right-clicking the shortcut for the command prompt and choosing "elevate"), you'd get a different token. Run the "whoami /groups" again in that elevated command prompt and you'll see that you now have:

"BUILTIN\Administrators S-1-5-32-544 Mandatory Group, Enabled by default, Enabled Group".

As you can see - a different token.

All of the whining on the newsgroups and other places on the net that reduce to "my account is supposed to be an admin, but it can't do anything" are about either bugs or design elements with UAC and the restricted token. Take for example control panel applets. By the time we see final versions of Vista, the built in control panel applets will either prompt for elevation immediately when they are opened (if they have to; generally if all of their functions are administrative), or they will be re-factored to seperate any admin-required functions from their "per user" functions and will show a shield symbol and button to "enable" the admin functions. You'll need to click the shield and either hit ConsentUI (for users who are in the Administrators group but have the restricted token; this is just a "is it OK to do admin things" dialog), or hit CredUI (this is for folks who are not admins; they can then enter alternate credentials if they have them in order to elevate).

I know today there are a large number of scenarios where this just isn't implemented yet, or doesn't work. Many are due to "we haven't gotten to that yet", while others are just plain bugs. One of the first things I happened to encounter was when I logged on as a standard user, then needed to do some administrative work. I used my trusty method of starting a command prompt as the standard user, and then executing "runas /u:MyDomain\MyAccount cmd.exe". When I got my new command prompt, it should have admin rights since that domain account is my admin one and is in the administrators group. When I tried to run something that was on the standard user's desktop (by CD \users\...) I got access denied!

But I was an Admin! "Not today Zurg", Vista says. My runas had activated my restricted token. Not the most usable thing; the only reason I had done the runas was to get credentials that had admin rights. This, and other scenarios are ones that we need to see fixed before Vista RTM's. Today, with UAC on, the only account that never gets a restricted token is the builtin adminstrator account. That one, in our environment - following best practices, is scrambled. Both the name of the account and the password are 25 random characters and nobody knows them. No escrowing them, nothing. Domain accounts are used for all admin tasks. So all users who logon are either standard users or protected admins.