Windows DevCenter    
 Published on Windows DevCenter (
 See this if you're having trouble printing code examples

An Overview of UAC in Windows Vista

by Mitch Tulloch

One of the most welcome features in Vista is User Account Control (UAC), formerly called User Account Protection (UAP), and before that, Least-privileged User Account (LUA). The idea behind UAC is to enable users to run their machines as standard users rather than as administrators. Running your machine as a high-privileged administrator is a bad idea since it means any download-and-install from the internet (whether deliberate or otherwise) gets installed and runs using admin credentials. If the software is "mal-intentioned" then you could be in a heap of trouble. Running your machine as a standard (low-privileged) user, on the other hand, means that any software you install and run can do only a limited amount of damage.

Unfortunately, the common experience today with platforms like Windows XP is that it's extremely cumbersome, difficult, and sometimes even impossible for users to run the software they need without admin credentials. (I've written a couple of articles on this that you may want to check out: one is on and describes the problem and offers a few tips and suggestions, and the other is on and has responses from readers describing their own difficulties and workarounds.) The big hope is that with Vista, users will be able to run the applications they need as standard users rather than as admins, making their machines more secure and easier to support in enterprise environments, and that greater parental control will be provided for home computers to ensure their security as well. Let's take a look at how this will work for both home and enterprise users.

Types of Users

First you need to understand how user accounts and their privileges have changed under Vista. In previous Windows platforms, you had three basic kinds of users local to the machine: Administrators can do just about anything; Power Users can do a few of the things that admins can do but are otherwise like ordinary users; and ordinary Users have only limited privileges to configure the system or install programs. In Vista, however, you now have only two kinds of users: Standard Users who have limited privileges on the machine, and Administrators who also have limited privileges on the machine but who can temporarily elevate their privileges to perform admin-level tasks such as changing system settings or installing apps. There's also the built-in Administrator account, which is special and always has elevated privileges, but the idea is that you'll never have to allow your desktop users to use this account.

So when a Vista user is running as an administrator, for example, and tries to open Local Security Policy (an administrative tool used to view and modify security settings on the local machine) by right-clicking and selecting Run As Administrator, a prompt like this appears:

Figure 1
Figure 1: Elevated privileges are required to run administrative tools.

Clicking Allow opens Event Viewer, because the user is running as an administrator. But if you are logged on as a standard user and you try to open Local Security Policy by right-clicking and selecting Run As Administrator, you get this instead:

Figure 2
Figure 2: An administrator password is required to run administrative tools.

Note that an administrator account has the ability to elevate its privileges, while a standard user requires an administrator to come and enter his password (close your eyes please!) to achieve the same effect. And here lies the first difficulty with how UAC is implemented. Having an administrator provide "over the shoulder" (OTS) credentials like this when needed certainly increases security but it reduces usability. One of the first things many beta testers have said concerning this is, "How do I turn this off?" And some parents are likely to feel frustrated after providing credentials for their children for the umpteenth time and end up turning UAC off entirely (in current builds you can do this using the Tools tab of the msconfig.exe window). But really, isn't there always a tradeoff between security and usability? If the goal of UAC is to make Windows machines more secure, then it's inevitable that this also means that it will make such machines less usable and harder to manage ("Oh no, not again. I'm coming Suzie…") than present Windows platforms. It's half of one and 50 percent of the other.

Windows Server Hacks

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

UAC for Home Users

What's the optimal (i.e. secure) configuration of UAC for home users? UAC is controlled by Group Policy, or on stand-alone machines by Local Security Policy (secpol.msc), and there are currently six UAC policy settings found under Computer Configuration\Security Settings\Local Policies\Security Options:

Thumbnail, click for full-size image.
Figure 3: User Account Control policy settings on a stand-alone machine--click for full-size image.

The behavior of UAC on a stand-alone (workgroup) machine is as follows. If the logged-on user is using an administrator account, the default is that a prompt appears whenever they need to elevate their privileges to perform some system-level task. If mom is an administrator on the computer, she'll probably get frustrated with this setting and change the policy to No Prompt, but that's a bad idea because one of the basic ideas of UAC is to alert the user when an application is trying to perform something system-level. On the other hand, if the logged-on user has only a standard account, then the default is that mom will have to walk over and say "Turn your head Bobby" and type her password so Bobby can perform the task he wants to do. Sure it's a pain, but the alternative (letting Bobby install anything he wants to) is out of the question for most parents.

UAC for Enterprise Users

Now let's look at Joe's Vista machine, which is joined to a domain at work. The UAC settings on his machine should probably look more like this:

Thumbnail, click for full-size image.
Figure 4: UAC policy settings appropriate for a machine belonging to a domain--click for full-size image.

In other words, a domain machine should probably have UAC configured differently from a home machine so that standard users are never even prompted for admin credentials (OTS is inappropriate in a work environment) and elevation is not required for app installs since tools like Group Policy and SMS are used to deploy apps instead. Of course, if you simply join a Vista box to a W2K3 domain you presently don't get these settings since Group Policy in downlevel platforms doesn't support Vista's new security settings yet, but presumably with Longhorn Server on the back end this is essentially what you get (though I haven't tested this yet).


Regardless of the frustration users (and kids and parents especially) may feel with UAC, it's definitely a step in the right direction for security of Windows machines. But how legacy apps will work with this feature is another issue, and something I'll look at in a future article soon.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.

Return to the Windows DevCenter.

Copyright © 2009 O'Reilly Media, Inc.