Tuesday, February 19, 2008

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.

3 comments:

Anonymous said...

Are you still persisting with this Power User route? How often are you having to resort to the Application Compatibility kit to create shims for applications that want to elevate?

Gordon Martin said...

Power User is a handy non-admin example that everyone can relate to. I thought I was making a good case for not sticking with Power User :-)

I haven't ventured to App compat and shims yet. I'm still staying with more global changes that affect everything overall. Once a generic approach is nailed down, I could see looking into shims to resolve individual challenges.

Have you played with shims yet? It would make for a valuable article. The best talk I've seen on shims is this one: http://channel9.msdn.com/Showpost.aspx?postid=377306 It all sounds quite provocative.

Anonymous said...

Ah I see on the Power Users, I wasn't paying attention before. I've used the AppCompat Toolkit previously but only in limited scenarios. I think it is essential though when migrating to Vista.