UAC: How many tokens did I get?

My recent article UAC: Avoid elevation like the plague! gives you a good idea of how radically different a Vista user experience can be if a user gets assigned either one or two tokens. I explained that it's important to set things up so users receive only one token. But how do you tell how many tokens a user is receiving? It would be kind of nice to know as you design your Vista implementation.

Vista clearly knows how many tokens a user has because it is smart enough to add and remove shields from icons as a result. But this is hardly a good barometer since it doesn't always change those shield icons in a timely manner. Unfortunately, Vista doesn't seem to be interested in sharing this small tidbit of information with us. It does appear that there are .Net APIs that can query for all user tokens which would lead to resolving the number. But we're enterprise admins here and we have no interest in compiling a small .Net program and adding it to various computers to get this answer.

If you know about some dialog box or command that reports the number of tokens, please share it with me.

The only way I've been able to figure it out is to try it. The easiest way to try out the tokens is to run Regedit. Regedit is rather unique. You would consider it an administrative application because it can be used to change registry settings that affect or corrupt the whole computer. Indeed, you do need to elevate to an Administrative Token if you wish to make changes to HKey Local Machine (HKLM). But Regedit can also be used by anyone (it uses that HighestAvailable manifest we discussed in the other article). If a Standard User with only one token attempts to run Regedit, they will be successful and will not be prompted for elevation at all. (A Standard User is only able to modify keys in their personal user profile (HKCU).) Power Users have similar limitations to Standard Users, but will be prompted for elevation since they have two tokens.

That's about it, short and sweet. Let's recap - to find out what tokens a user has, run regedit:

• If the user goes right in with no prompt, they are a Standard user with only one token - a Full Token.
• If the user gets prompted for elevation, they are using their Filtered Token and are attempting to elevate to their second token.
• If the elevated user is able to modify or add keys in the HKLM area, that user has a Full Administrator Token in addition to their Filtered Token.
• If the elevated user is unable to modify HKLM, they are something less than an administrator (perhaps just a Power User) and have a Full Token in addition to their Filtered Token.
  

Now keep in mind that tokens are created during the logon process. You can't test for tokens immediately after changing group memberships or User Rights Assignments. You must log the user out and back in again before running Regedit and checking the tokens.

"Vista Capable" lawsuit is now a class action

Slashdot's post links to the relevant articles.

The lawsuit against Microsoft rises from the 2006 pre-holiday season when they used "Windows Vista Capable" stickers to boost sales of machines loaded with Windows XP. It turns out that many of the machines could only function with the stripped down Home Basic edition of Vista. If your organization got stung by the "Windows Vista Capable" campaign, watch for an opportunity to make a claim if the class action ever succeeds.

SP1 Hiccup: don't install KB937287!

On February 12th, Microsoft released KB937287 as an automatic update. This was in preparation for the upcoming SP1 release. It is intended to improve reliability and performance when installing future Vista updates.

Unfortunately the hotfix has had rather undesireable results for a number of users. Many computers have entered an endless reboot scenario. Here's a forum that has been discussing the problem and has found some solutions in an attempt to avoid a complete OS rebuild.

Microsoft has now decided to pull the hotfix to avoid any further disruption while they try to find a solution. Their announcement is rather vague. They don't describe which customers would be affected and don't offer much help in backing out of the problem. But the attached comments are worth a read - the outrage is palpable.

Although Microsoft has pulled the update, I worry that the threat might still exist for us enterprise admins (hence this article). Those of us who don't allow automatic update into our organizations but use systems such as SMS to apply updates could still have this hotfix pending - you should check and make sure to pull it. Also, the KB article on this hotfix shows that it has been integrated into the SP1 package and will be applied if necessary. I suspect that installing SP1 could expose you to some additional risk - hopefully Microsoft can provide some additional clarification here.

What does this do to the release timeline for SP1? If the current package has a problematic hotfix in it, we will have to wait for a new one. If this prerequisite hotfix for SP1 has been pulled and needs to be reengineered, how long will it be before SP1 can be delivered via automatic update for the population at large?

BTW, I have installed my RTM edition of SP1 with no problems. I'll be checking all of the behaviors described in past articles to ensure that they remain accurate - 500 hotfixes must have changed some of them...

UAC: Avoid elevation like the plague!

When talking about UAC, we always focus on elevation - how to trigger it, how to preserve it, how to understand it... It is a complex subject that deserves our attention. But before embarking on my next series of articles on this very subject, I think it's important to remind everyone to simply avoid elevation.

There are countless articles complaining about the elevation experience and we KNOW users hate it. So let's be sure to create an environment where elevation just doesn't happen. I'm not talking about turning UAC off or softening any UAC settings - I just want you to be aware of avoidable conditions that are ripe for elevation.

Before reading this article, I need you to know a little something about UAC. At the minimum you should read my article Let's Talk UAC for the Enterprise. To get a little deeper into the subject, consider reading some detailed articles found here: UAC: An introduction to User Account Control.

With that little bit of business taken care of, let's get started...

At first blush it might seem rather easy to avoid elevation - just don't run any administration tools - users shouldn't be using them anyway. Listening to Microsoft you'd think this is all that would be necessary. But a little manifest feature called "HighestAvailable" causes us a lot of problems. Applications written for Vista can specify which access token is needed to successfully run the program. Unfortunately, many Vista versions of applications were written before developers fully understood Vista - or indeed, sometimes before Vista was even available for testing. Developers were sprinkling the "HighestAvailable" requirement like pepper on food they hadn't even tasted yet.

I'm sure developers were thinking it was important that their application have as much access to the system as possible. Asking for the HighestAvailable token just made sense. Unfortunately this requirement means an elevation prompt is needed in order to move from the default filtered token to the user's full token - irritating users. You'd be amazed at how common this approach has been - even when the application clearly had no need of those extra rights. Quark Xpress is a fine example - it's a graphics/publishing program that needs no special access to Vista's system resources and yet asks for the user's highest available token.

I actually find the HighestAvailable manifest to be an odd beast. Developers are basically admitting that they have no idea whether users will be Standard Users or a Power Users or Administrators, but that they'll be happy if their program gets whatever rights the user has (this isn't a request for an Administrator Token afterall). I also find it frustrating that we can manually set properties of an executable to demand an Administrator Token, but we aren't allowed to force an executable to be happy with a filtered token.

But I digress... the problem here is that we have too many requests for the Highest Available Token presenting our users with the elevation prompt... The solution is a simple one for those who think of it. Make sure the user only has one token! Make sure users aren't unnecessarily Administrators or Power Users. Don't give users unnecessary User Rights Assignments. If users are only standard users, no filtered token will need to be created to filter away extra rights. This will result in one single token for the user - the user will always be using their highest available token because that is the only one they have.

It's simple, but when a user launches an application such as Quark Express, it will notice that the user is already using their highest available token and just go ahead and execute with no extra prompting.

Actually, it's neat to see what else happens... It turns out Vista is pretty clever when it comes to applying those shield icons to shortcuts that lead to programs needing elevation. If a program's manifest indicates that it needs elevation, Vista adds the shield icon - but it's smart enough to know when the user won't be asked and removes the shield as well. Here's my Quark icon as it appears on a Power User's desktop and then on a Standard User's Desktop:


Neat eh?

I should have mentioned that we are also talking about a lot more than just avoiding elevation prompts. If you can keep your user always using the same single token, the user will not be forced to leave any resources behind when switching tokens. This means that users will always have their drive mappings when using applications of this type!

Hopefully application developers will eventually learn that the HighestAvailable manifest is not the preferable, default manifest, but rather the manifest of last resort when trying to get applications to work in Vista.

Become a Token Geek

I think I've made it clear through my past articles that tokens are an important element of UAC and Vista. The existence of various user tokens and the demand for them by applications has a huge impact on system behavior. My articles will continue to explore this relationship between token and UAC on a fairly practical level.

But if tokens intrigue you and you wish to learn more about how they work, you should check out this series of articles by Randy Turner of Microsoft's Directory Services Team. He will take you to a whole new level of token understanding - perhaps transforming you into a Token Geek:

• What's in a Token
• What’s in a Token (Part 2): Impersonation
  

In addition to providing great low-level detail about how the Windows systems rely on tokens, Randy links to numerous software tools that can be used to troubleshoot your environment.

SP1 and a new kernel!

The Microsoft Vista Product Management Group has just released Service Pack 1 to manufacturing! It's now locked in stone. But we need to wait 6 - 8 weeks before getting it into our hot little hands.

I'm curious to see if this is the long overdue solution we have all been needing - or if it was released way too soon under pressure - causing us to wait for SP2 before having a desirable product.

I found a very interesting article that discusses the new kernel for Vista SP1. Vista SP1 will now be version number 6001. It is being synchronized with the version number for Windows Server 2008 since the two OSs will now share the same kernel. I'm sure that this is useful internally for Microsoft, but it makes things interesting for us enterprise administrators.

Many of us are used to building WMI filters and scripts that check Windows version numbers in order to target specific versions of the product. It looks like this is now a little more complicated. Receiving the number 6001 won't be enough to distinguish between a server or workstation product. You will need to expand your queries to include a product name or some other unique identifier.

Logon Scripts: A Token Effort

How many of you have been struggling to make your logon scripts work when Vista's UAC is enabled? (I'm holding my hand up here.) Let me share my effort with you so you can avoid the same problems.

Basically all of the difficulty stems from the way UAC isolates processes. Logon scripts are processed by a process :-) - it's important to know what integrity level the process operates with and what token the end user is using. (If this last sentence made no sense to you, you better read my article Let's Talk UAC for the Enterprise before continuing.)

I'm sure many of you have read or been told that launching scripts by Group Policy Objects (GPO) is the way of the future. Indeed, I too was launching my scripts via GPO, but it is this very thinking that got me into trouble.

Logon scripts launched via GPO are processed using the user's "highestAvailable" token. This causes resources such as drive mappings to be associated with that Full Token. The other thing to remember is that the user's session and desktop are then presented using the Standard Token. There's no problem for basic users because they only get one token - their Full Token and Standard Token are one and the same.

But UAC starts causing troubles for all the other users who have split tokens (Administrators, Power Users, etc.) - anyone with two tokens. The GPO maps drives as a resource of the higher token and the user is left to operate in Windows with their lower token. UAC prevents the lower token from seeing the resources of the higher token. Therefore the users don't get the mappings you've assigned them.

It's unfortunate that Vista isn't smart enough to process scripts and assign resources against all the user tokens it creates during the logon process. But Microsoft is aware of the problem and has tried to offer a few solutions (none of which work 100%). The first and most common solution offered comes from their guide, Deploying Group Policy Using Windows Vista
- the Group Policy Scripts can fail due to User Account Control section describes the problem (but not entirely accurately). It goes on to offer a solution that I will call the LaunchApp solution.


The LaunchApp Solution

The LaunchApp solution suggested by Microsoft is a horribly kludgy affair that doesn't work 100%. Basically, Microsoft is providing a LaunchApp script that is capable of creating a scheduled task that launches another script. Microsoft just expects your logon script GPO to call the LaunchApp script instead - that will then schedule an immediate task to run the script you originally wanted to use to map drives. (confused yet) The idea is that the scheduled task will trigger your script to run once the desktop is created, which will cause it to run using the user's Standard Token rather than the user's Full Token. The users will then be able to see the mappings because they are operating with the same token that has been assigned the mappings.

Some small problems...
1) The scheduled task fires off when the Desktop session is created. The other thing that fires off at that moment is anything in the user's Startup folder. One nice example is Microsoft's own Outlook product. Users typically put that in the Startup folder so that they always see their e-mails. It will often be configured to store things like a Personal Address Book on a mapped network drive - guess what hasn't been mapped yet when Outlook goes looking for a PAB file? The results aren't so good.

2) The LaunchApp acrobatics gets the mappings to associate with the Standard Token but still does nothing for the user's elevated token. When a user elevates a program, all mappings are unavailable to the elevated program. Quite an inconvenience to say the least.


The Merged Mapping Solution

Microsoft's latest suggestion for solving the mapping problem is described in KB937624. I call this the Merged Mapping solution - it is by far a better solution, but it also has its problems. Basically, Vista has a wonderful little registry key that tells it to merge the drive mappings between all of a user's tokens: HKLM \Software \Microsoft \Windows \CurrentVersion \Policies \System \EnableLinkedConnections = 1. What could be simpler right? Create this key on every workstation and it will tell the OS that the mappings associated with one token are to be mirrored into the other token as well.

I'm not sure if Vista understood that key right out of the box or whether it was added later as part of a hotfix. All I know is that I was made aware of it rather late in the game. I did use this solution for a while before discovering the problem it has...

When I first implemented it, it worked great. Mappings created against one token were made available against the other token - no matter whether the user was an Administrator or a Power User (remember Full Administrator Token vs. Full Token). Well, the installation of Service Pack 1 (SP1 RC1) changed all that - Vista stopped merging mappings between the Standard Token and a Full (non-admin) Token. It now only merges mappings between the Standard Token and a Full Administrator Token. -- Not so good when all of my users are Power Users -- completely useless in fact.

I've opened a Premier Support call on this problem. It's been over a month and they are still trying to decide if it is really a problem or if there is an easy solution. You see, if you read the KB article mentioned above, you may notice that it only mentions it as being a fix for Administrators and doesn't mention other cases at all (but I know it used to work!) -- I of course thought that the discussion of only Administrator wasn't a specific limitation but rather Microsoft's usual over-simplification of the discussion. I'll update this post when I know more.


The AD Profile Solution

Ultimately, I found the best results for mapping drives were achieved by avoiding the logon script GPO entirely. Instead, I fell back on a tried and true method that has been around for a decade or so - I now launch my logon scripts via user profile in Active Directory.



Not only is this method extremely simple, but it is extremely effective. Logon scripts launched in this way are processed with the user's Standard Token - the same one the user is using when they are first presented with their desktop. It doesn't matter if the user is a Basic User, Power User or Administrator - the user will be able to see the mappings assigned to them because they are associated with the correct token. Stop wasting your time with a GPO script - it's not worth the effort.

Despite the script being processed by a Standard Token, it is still processed before the desktop is made available to the user. This ensures that all drive mappings are created before any application in the user's Startup Folder are processed - all applications in the Startup Folder should launch successfully as a result.

If you choose to adopt this new old approach, I still recommend you implement the merged mapping solution described in KB937624. In your environment it might merge the mapping with all types of user tokens, or it might just merge them for administrators - either way it will still be an improvement. Keep in mind though that this solution cannot do anything to merge mappings between two different user accounts. So it cannot help enterprises that make an administrator use a standard user account for routine tasks and then a separate administrative account for admin tasks. (I will be looking for solutions to this in future articles.)

GPAnswers: Group Policy Preference Extensions

If you are an enterprise administrator responsible for GPOs, I'm sure you've heard of Jeremy Moskowitz and his GPanswers.com site. If you haven't, it's high time you did.

GPanswers has an active forum of knowledgeable people trying to deal with GPO issues. Being the author of the book Group Policy: Management, Troubleshooting, and Security, Jeremy has a lot of knowledge to share. He also offers courses to those who really want to get into it.

Anyway, he just wrote a great introduction to Group Policy Preference Extensions (GPPEs) that you really should check out:

The original Group Policy feature set includes items like Administrative Templates, Software Installation, Security Settings, and Folder Redirection Settings. In all, there are 18 things you can do with the original Group Policy. The Group Policy Preference Extensions feature set adds 21 new features to the existing set, bringing the total number of categories to 39. The goal of the GPPEs is to help you do more with Group Policy and reduce the reliance upon logon scripts. The kinds of things administrators have always wanted to do using Group Policy are now available...