LUA, UAP, and the restricted token

Is your token chokin'?
With Windows Vista, you now have UAP or "User Access Protection", 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 when you need to elevate), and a new token - based on the standard one - that is used for UAP. 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 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 UAP 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 lock symbol and button to "enable" the admin functions. You'll need to click the lock 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 huge 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, executing "runas /u:\ 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 anymore, 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 UAP 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.

Come on Microsoft; step up to the plate and get these scenarios working.

Those of you who managed to get through my previous posts know that I was working on the ability of my service to be able to use WTSQueryUserToken to get the user's token so that it can execute code on behalf of the user. This works (finally). Anybody care to guess which token is retrieved in this way? The restricted one? The regular one? Well, I've tried it - and it is the restricted one. So if the user is an administrator, they won't really be until they've hit ConsentUI and agreed that your code can perform administrative tasks.