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.