Let's Talk UAC for the Enterprise

In my initial UAC article UAC: An introduction to User Account Control I provided you with links to lots of UAC literature. My hope was that you could use that literature to get yourself up to speed on UAC and start to mull over its implications. I plan to write future articles that build on that basic UAC knowledge by examining aspects specifically relevant to enterprise administrators. But I realized that those links provide an overly simplified model of UAC (believe it or not). The literature is very focused on the workstation OS itself and does not consider administrators that have rights outside the OS - my article UAC: Local Admin vs. Domain Admin discusses this.

I present here a glossary of terms for UAC that will accommodate future discussion of UAC in the enterprise environment:

Accounts / User Accounts: generally refers to any users or userids in your environment.

Local Account: is a user account that has been created on a local Vista workstation and has no standing in the Active Directory Domain. Vista's default Administrator account is a good example.

Domain Account: is a user account that has been created in Active Directory and has standing in your enterprise's domain.

User / Standard User / Basic User: is a user that has standard user privileges on the local workstations. The user will be a member of the predefined local group Users and will have only basic rights. It is assumed that the user also has no extraordinary rights out in the domain, unless otherwise stated. The words 'standard' or 'basic' are used to emphasize this user's lowly status :-) Standard Users receive only a Full Token at logon time.

Power User: is a user that belongs to the predefined local group Power Users. Users are made a member of this group for legacy backward compatibility purposes and are not expected to receive any additional rights. However, Power Users do receive both a Full and Filtered Token at logon time. This is different from a standard user and will affect the behavior of UAC. I use the Power User for examples where I need a user with a Split Token without having a Full Administrative Token.

Administrator / Local Administrator: is a user who belongs to the predefined local group Administrators. This user has full administrative rights over the local Vista OS, but doesn't necessarily have any administrative rights on the domain. Local Administrators receive both a Full Administrator Token and a Filtered Token at logon time. A lot of UAC discussion is focused on this type of account because it is the one that has the most potential to be used to do damage to a system.

Domain Administrator: I don't use this term to refer specifically to an actual Domain Administrator, rather I use this term to refer to any user that has some administrative privileges on an enterprise's AD domain. A Domain Administrator is not necessarily a Local Administrator. In many environments Domain and Local Administrator rights are granted separately.

Token / Access Token: Tokens are assigned to user accounts at logon time. They contain data on a user's group membership, authorization and access. They are used to control what Vista resources and tasks can be accessed by a user account. Windows XP assigns only one token per user - Vista assigns up to two tokens per user when necessary. It is UAC that controls which available token is used or whether additional tokens must be assigned.

Standard User (Access) Token: Every account that logs into Vista is assigned a Standard User Token. Standard Users are assigned only one token, and this is it. This token represents all of the privileges of a standard user. Even administrators receive this token - it is the token they use when performing routine activities in Vista.

Full Administrator (Access) Token: Accounts that belong to the local Administrators group are assigned a Full Administrator Token in addition to a Standard User Token. This token represents privileges over and above those of a standard user - it is the token used when performing administrative tasks.

Full / Unrestricted (Access) Token: The highest access token available to an account is referred to as a Full Token. For Standard Users, the Full Token is the same as the Standard User Token. For Administrators, the Full Token is the same as the Full Administrator Token. But if an account has more rights than a Standard User and Fewer Rights than an Administrator, the account receives a unique Full Token that represents those extra rights. Accounts that are members of the following groups receive a Full Token in addition to a Standard User Token: Power Users, Account Operators, Server Operators, Printer Operators, Backup Operators.

Filtered / Restricted (Access) Token: You've already met the 3 possible tokens an account can receive. The term Filtered Token is used to refer to the Standard User Token for accounts that receive more than one token. Standard Users do not receive a Filtered Token because they did not have any extra rights that needed to be "filtered away".

Split (Access) Token(s): Accounts that have been assigned two tokens are referred to as having Split Tokens because their rights have been "split" between two tokens. Their Standard User Token represents their standard rights and their Full Token represents any additional rights they may have. Sometimes the term "Split Token" is used to refer to a user's Filtered Token.

Default (Access) Token: The Default Token is the first token that an account is using after it has initially logged into Windows Vista. Explorer.exe will have been run using this token in order to present the Desktop to the user with the least privileges possible. Now let's see if you've been paying attention :-) Which of the above tokens is being used at this point? Actually it's easier to ask which token can't be used at this point -- The only token which could not be used by default is a Full Administrator Token - Administrators would have a Standard User Token which would be getting used instead. For Basic Users, their Standard User Token would be used - which is the same as their Full Token. For other types of users, their Standard User Token would also be used - but it could be either their Filtered or Split Token. Confused yet?

Elevation / Elevated Process: It is difficult to have a technical discussion about Vista without someone using the word "Elevation". Vista protects itself by only allowing users with a limited security level to launch processes at a similar security level. The more secure operation a user wishes to perform, the higher level they must operate at. The user must have a sufficient Access Token to be able to Elevate a process to a sufficiently high security/integrity level. An Elevated Process is usually one that has been launched by someone with a Full Administrator Token and runs with a High Integrity Level.

User Interface Privilege Isolation (UIPI): Is the new Windows Integrity Mechanism that provides a barrier around elevated processes in Vista. All processes and objects have integrity levels that restrict the accesses that are granted to a process by the Windows Discretionary Access Control (DAC) security model.

Integrity levels (IL): Processes can have one of four Integrity Levels: Low, Medium, High, System. Internet Explorer runs at a Low IL so that it is prevented from doing any harm to the system. The Desktop and most user applications have a Medium IL and can be accessed by any user (Standard User Token). Most administrative processes, such as Computer Manager, have a High IL and can only be accessed by users with a Full Administrator Token. Other tools like Regedit can be run with a user's Full Token (whatever that might be) and will only allow access to appropriate areas of the registry. System is the highest Integrity Level - normally only some services and some system processes run with System IL. The UIPI prevents processes operating at a lower IL from accesses processes with a higher IL, but there is a Medium IL process called uiAccess that can actually access High IL processes. uiAccess is needed to give user interface devices such as mice and keyboards access to all processes.

Elevation Prompt: When UAC detects that a process is to be run with a higher Integrity Level than the current process or user token allows, an elevation prompt is presented to the user. An elevation prompt serves two functions. First, it ensures that the user is aware when processes are trying to access more sensitive areas of the system. Second, it gives the user control over the granting of that access.

Consent Prompt: Is a type of UAC Elevation Prompt. If UAC determines that the current user has an available token of a sufficiently high Integrity Level (such as Full or Administrator Token), the Consent Prompt will be used to elevate a process. The Consent Prompt simply asks the user to Consent to the elevation by choosing to "Continue" or "Cancel".

Credentials Prompt: Is a type of UAC Elevation Prompt. If UAC determines that the current user does not have a token of sufficiently high Integrity Level (maybe just a Full or User Token), the Credentials Prompt will be used to elevate a process. The Credentials Prompt asks the user to provide a username and password of a user who would have sufficient rights. Vista will then create the necessary token for that user and use it to elevate the process -- In fact, Vista will revert to an entire profile for the user with the high token and run the elevated process within that environment, using different shell folders, etc.

Manifest: Applications developed for Vista should have an accompanying Manifest that specifies what token is needed for successful execution of the program. When a manifest is found, UAC will kick into gear and ensure that the requisite tokens are used to properly elevate the application. In addition to manifests, Vista has predefined other processes and application types that need elevation. Users also have the option to manually force elevation when launching applications.

highestAvailable: can be specified by a manifest. It tells UAC to elevate the user to the highest token available. No elevation is necessary if the calling process is already using the highest token, or if it's a Standard User who only has one token anyway.

requireAdministrator: can be specified by a manifest. It tells UAC to elevate to a Full Administrator Token. Any Full token is not sufficient - the user must be a member of the local Administrators group in order for elevation to succeed.

Microsoft Windows Releases

This post is a week late - but some of you may not have heard. Microsoft has released a new Release Candidate for Vista Service Pack 1 called "SP1 RC Refresh". ZDNet brought us news of the release: Near-final Vista SP1 goes public

In other news... Rumors have already started to fly about Microsoft's next Windows platform - Windows 7. It sounds like Microsoft is moving the release date forward to next year: Vista successor, Windows 7 to be released next year?

Need to Virtualize Vista Home Versions?

This just in - Microsoft is finally easing their license restrictions that prevented you from installing Vista Home Basic and Vista Home Premium in a virtual environment: http://arstechnica.com/news.ars/post/20080121-microsoft-relents-vista-virtualization-ban-lifted.html

This will be great news for some of my past clients. I have no idea why Microsoft erected this false barrier to Vista Home adoption in the first place. Developers test in virtualized environments like VMWare - preventing them from testing their products on Home editions of Windows Vista does the end user a great disservice.

Disabling UAC

Tonight I'd just like to make some quick comments about people disabling Vista's User Account Control (UAC) feature. If you have been doing any research on Vista you've read people's complaints about UAC and the constant UAC elevation messages.

In an effort to minimize the messages and smooth the computing experience, many people have opted to disable the UAC feature:

• http://www.petri.co.il/disable_uac_in_windows_vista.htm
• http://www.howtogeek.com/.../disable-user-account-control...

Indeed, this may be a valid alternative for home users since home editions of Vista don't support configuration of UAC behaviors such as Admin Approval Mode, Elevation Prompt behavior or application installation behavior (see Microsoft's Windows User Account Control Step-by-Step Guide). But the decision to disable UAC should not be taken lightly - particularly in an enterprise environment.

Everyone must understand that Vista's UAC is much more than a set of prompts that irritatingly pop up at the most inopportune times. UAC is a vital part of Vista's architecture that touches many aspects of the system. When UAC is disabled, other Vista security features such as Registry Virtualization and Protected Mode for IE7 also stop functioning.

Another thing to consider is that Vista really was developed around the UAC functionality. It may not be so easy to anticipate how all of Vista's technologies will behave when UAC is not active. A case in point is the configuration of network printing. Philip Wiffen's Mind Circus blog points out that it's not possible to install a shared network printer when UAC is disabled -- Thankfully he also points us to a Microsoft hotfix to correct this.

My point is, think long and hard before disabling UAC. If it's the prompts that are giving you and your users grief, look into some of the UAC configuration options that can mitigate things a little. I'll provide more information about these in the future (but I've got a few other articles to write first).

Service Pack 1 (SP1) for Vista is coming

Release Candidate 1 (SP1 RC1) has been available for a few weeks now. People have started kicking its tires in hopes that it will fix a lot of what's broken in Vista.

I know in my case SP1 RC1 has amalgamated a lot of past hotfixes but many of the fundamental architecture and feature problems remain. Can you believe that SP1 RC1 contains almost 500 hotfixes!?! That's roughly two hotfixes a day since Vista was first released.

For a complete list of the hotfixes included in SP1 RC1, check out the documentation Microsoft just released: http://technet2.microsoft.com/WindowsVista/en/library/b984ce70-701b-4565-868e-51d1ba47555d1033.mspx?mfr=true

I'm also here to tell you that SP1 RC1 has exhibited some unexpected behavior that has broken some functionality I rely on:

1) I happen to use the registry setting described in KB937624 to make my drive mappings visible between a user's filtered and elevated UAC tokens. It had been working beautifully for me until I installed SP1. SP1 continues to allow the registry setting to do its job for administrative users but has stopped functioning for Power Users. I am working with Microsoft to find out why.

2) Remember my clever registry hack that fixes Folder Redirection data moves and improves application compatibility and the user experience? (If you don't, take a look at the articles: Folder Redirection: Misbehaves after target move , Folder Redirection: A case study) Well, SP1 makes that hack fail in a spectacular way! When Folder Redirection encounters a mapped drive letter in the registry at boot-up time, it decides the best course of action is to completely delete the corresponding redirected folder on the network! It completely kills the folders! Not only that, but the Users Files Folders appear as blank icons with no labels or properties. The Folder Redirection Functionality is permanently broken. I haven't found a smooth way to recover - other than to delete the user's profile and start fresh. This is just nasty. I am working with Microsoft to find out why this is happening and hopefully find a solution (this didn't happen in the SP1 Beta version by the way).

The hack does still work if a UNC path is used instead of a drive letter. I will modify my two articles (linked to above) to reflect the new reality and remove all mention of drive letters. Sadly, although the move data problems will continue to be avoided with the hack, the application compatibility and better user experience features have been lost.

Here's hoping that the final version of SP1 will make all of our problems go away.

Local Administrator Trumps GPO

Okay, I admit, I'm a big fan of Mark Russinovich. I may be biased because this guy modifed PSExec for me, but I believe he has some great stuff to teach us. His latest Technet blog article is a case in point: http://blogs.technet.com/markrussinovich/archive/2008/01/02/2696753.aspx

I've always assumed that GPO settings I create to manage my organization's desktops and users give me ultimate control. It didn't matter what setting someone changed locally, if I had a contradictory setting in my GPO then it would get changed back in short order. How wrong I have been.

Mark's blog shows local administrators how to use regedit to set permissions that will prevent GPOs from being able to configure their settings. Don't forget that although you may edit GPOs using pretty GPMC templates, the policies only manifest themselves on a local machine by making changes to registry settings. If the system loses its right to change a registry setting then the GPO is essentially neutered. This is not new to Vista - this was also possible in XP.

I don't like DRM

This is a little off topic, but I've never been a fan of Digital Rights Management (DRM). I understand that intellectual property owners must protect their property, but too often DRM is used to maximize profit at the cost of a consumer's fair use. But I find that DRM has backfired. Consumers aren't dumb. They know when they are being punished for being honest citizens and they see the pirates enjoying a better quality experience for free. DRM is driving people away from legal sources of intellectual property. Publishers finally seem to be realizing their mistake and are slowly abandoning DRM.

But in the mean time, DRM content is still being sold and there have been a few buyers. Here's an interesting DRM experience documented by a Vista user:

http://davisfreeberg.com/2008/01/03/bad-copp-no-netflix/

Not only has DRM driven people away from media products but there are people who have sited it as a reason for not moving to Vista. This is the first concrete example I have seen that validates those people's fears. It's one of the reasons I have chosen to only use Vista on my laptops at home.

UAC: Local Admin vs. Domain Admin

My article UAC: An introduction to User Account Control links to a number of UAC articles - many written by Microsoft. Have you noticed that virtually every article talks about administrator accounts in a generic sense and never distinguishes between a Local Administrator or a Domain Administrator?

These two types of administrators are very different beasts. A Local Administrator is a user that has been made a member of the Administrators group on a local Vista computer. This user basically has complete access to do anything they want on the local Vista computer. What I call a Domain Administrator (for purposes of UAC discussion) is a user who has administrative rights of some kind on the enterprise domain. They don't necessarily have to have full domain admin privileges - they might just have rights to administer a specific OU in Active Directory for instance. The thing to notice is that these two types of administrators are very different and you can very easily be one type without being the other. It bothers me that this distinction is not made when talking about UAC.

When talking about UAC, Microsoft seems to think that if you are a Local Administrator you will also be a Domain Administrator. I say this because Microsoft never makes the distinction between one type of administrator or another, and indeed, UAC works very well for this scenario. But the wheels kind of fall off if you are only a Domain Admin or only a Local Admin. Let me explain...

Being a both a Local and Domain Admin

Microsoft's Getting Started with User Account Control on Windows Vista is a fine example of a document that talks about UAC without ever making the distinction between a Local and Domain administrator. Here is an excerpt where it shows the experience for an administrator performing an "administrative task":

User Account Control consent prompt

The following example shows how an administrator in Admin Approval Mode is prompted for consent when attempting to perform an administrative task.

To view the consent prompt

1. Log on to a Windows Vista computer with an administrator account in Admin Approval Mode.
2. Click the Start button, right-click My Computer, and select Manage from the menu.
3. At the User Account Control dialog box, click Continue.

After reading this you will be forgiven for thinking that Microsoft's Active Directory Users and Computers (ADUC) tool would also be included in this behavior since it is typically used for "administrative tasks" (and I think if you are reading this blog you will be well aware of how dangerous this tool can be). If you happen to be a Domain admin in addition to a Local admin, you will indeed see that you experience a similar behavior for ADUC. If you attempt to run ADUC, you will be presented with the Consent Prompt.

If you are a fan of UAC, you will like what you are seeing at this point.

Now lets watch the wheels fall off this UAC wagon...

Being a Domain Admin Only

I have worked in many large enterprises. I have found that financial and military organization like to exercise a great deal of control over their computing environments. Typically these organizations will give you the rights you need to do your job but no more. This typically means that you may well be a Domain Administrator with rights to manage users, but will only be a standard user on your computer with no rights to even change the screen saver. With this scenario in mind, let's see what happens...

It turns out that Vista will NOT notice the awesome power that this user holds on the domain. Vista will only see that the user belongs to the lowly local User group and will treat the user as such. If this user attempts to run Manage for instance, he will not receive the Consent Prompt, but rather will be presented with the Credentials Prompt so that he can enter the credentials of someone with the appropriate rights. -- So far so good.

Now let's try running ADUC. One would expect that Vista would consider this to be an "administrative task" and offer up the Consent Prompt to our all powerful Domain admin. But this isn't what happens at all. Vista simply runs ADUC for you with no UAC elevation prompt at all. It turns out that Vista has only seen the user's lowly Local User status and apparently decided that the user can do no harm on the domain. Try GPMC - the same thing happens.

It turns out that if these organizations try to create a more secure environment, they lose the benefit of UAC protection on their domain. If a trojan gets onto the computer of a Domain Administrator who is just a member of the local User group, the trojan can go about its business of touring the domain unchallenged.

Being a Local Admin Only

Now let's consider the experience of a more liberal enterprise. Perhaps this organization specializes in application development or has a large number of traveling users who must be able to modify their laptop configurations. This organization will have made the decision to make their users a member of the local Administrators group whether or not they are also Domain Administrators. Let's see what happens to one of these Local Admins who has no rights to administer the domain...

If this user runs Manage, he will be presented with UAC's Consent Prompt and be able to manage his computer as he sees fit. This is expected behavior. Now what happens if this user runs ADUC?

Remember what happened previously? You might expect that since the user has no rights on the domain that ADUC would simply let the user in to browse the domain. This shouldn't be considered an "administrative task" because the user doesn't actually have the rights to make any changes in our domain.

But again, Vista has no idea what is happening out in the domain, it is only making decisions based on what it can see locally. Since the user is a member of the local Administrators group, it decides that an "administrative task" might be occurring and prompts for consent. At this point you might be thinking "You're splitting hairs Gord, I can live with an extra Consent Prompt." -- you can't.

Here's where the wheels fall off. If the user just wanted to browse the Active Directory then an extra Consent Prompt is no big deal. But what if a change in the domain is needed? Obviously this user doesn't have the rights, but he likely has a Domain Administrator doing some "over the shoulder" work for him. This Domain Administrator has probably walked up and seen what the user's problem is and now wants to quickly tweak something in the user's AD profile or something.

Remember that when ADUC is run, Vista thinks that it is the user (Local Admin) running it. It presents the Consent Prompt. The Consent Prompt does not offer a way to enter any credentials for another user. You either Continue or Cancel. UAC actually entirely prevents the "over the shoulder" Domain Administrator from being able to do his work. If the user had been a lowly local User, then a Credentials Prompt would have been presented and the Domain Administrator could have continued on with his work.

Now at this point some of you experienced enterprise admins are smirking to yourselves thinking I have forgotten about the secret Run As... option on a shortcut's context menu. I've got news for you - in Vista it is now called "Run As Administrator" and it won't work. The only way you can use RUN AS in the traditional way is through a DOS CMD prompt. (More about this in a future article.)

Another work around to this problem is to do a "Fast User Switch" where the domain admin quickly creates a second session for himself where he can do his work. But there are problems with Fast User Switching which cause some organizations to turn this feature off. (More about this in a future article.)

All Said and Done

So when it's all said and done, how do you think UAC will impact your organization? Like many Vista features, there are many ways to use UAC but there are also many unexpected behaviors that manifest themselves. UAC does have 8 GPO settings that can change UAC's behavior in ways that may help your organization. I will be covering these in future articles.

The important lesson to take away from this article is that you cannot assume anything in Vista. When architecting your environment, test every possible scenario you may have and understand how Vista is going to respond - it often won't respond in the way you'd expect.

By the way, Microsoft assures me that they are working on a solution to the problem described above. It will be interesting to see what they come up with. Of course, this is also a warning to keep your eyes peeled for more unexpected behavior as these behaviors get changed in a future hotfix or service pack :-)

Watch for future articles where I get down into the details and explain how Vista makes some of the decisions it does.