Why User Account Control in Windows is necessary

The UAC feature in Vista addresses the lack of separation between regular and administrative users in previous versions of Windows. Our expert explains the benefits.

I've been thinking about turning off UAC in Windows. Does it really help protect things?

The short answer is "Yes, it does." The longer answer will take some explaining.

UAC, or User Account Control, was introduced in Windows Vista as a way to keep what regular users do separate from what administrative users do. The two had a nasty way of getting mixed up.

For a long time, the consumer-grade version of Windows -- the "3.x" line -- didn't even have a multiuser environment. There was only one user who was all admin, all the time. Since networking was almost nonexistent and most computers had only a single user at a time anyway, most people didn't see this as a flaw. (Windows NT was multiuser, but let's face it: Most people then didn't use NT.)

When mainstream Windows added multiuser behavior with Windows 95, it only meant that different users had different logon profiles -- it wasn't a true multiuser system. And again, every user was an admin by default. Add malware to the mix, and the end result was the havoc most Windows users know all too well, since nothing stopped that malware from running as admin, too.

With the introduction of XP, Microsoft leveraged the work it had done on the Windows NT/Windows 2000 line, including multiuser security. Since XP was a direct descendant of those operating systems, it had true multiuser behavior -- including proper multiuser security. Users could run as administrators or as nonprivileged regular users who could run apps and modify their own documents but make no changes to system settings.

The problem that remained wasn't the technology. It was user behavior.

What still remained were all the bad old habits -- both of users and programmers -- that developed during the 9x years. Not only were most users expected to have no restrictions on what they did, most programs were also written that way. A great many Windows apps had to be rewritten in the years following XP's release so they could run properly under limited-user accounts. On top of that, Microsoft added backward-compatibility features to Windows XP to ensure that the bad old programs could still run properly. Most people are probably familiar with the "Compatibility" tab in a program's properties window. The "Run this program as an administrator" option was also developed as a pre-emptive response to these problems. Running a regular user program as admin may have helped with compatibility, but it created entirely new problems with security.

By the time Vista was introduced, Microsoft had garnered a good deal of feedback about application and user permissions. Most people still hadn't gotten into the habit of not running as admin for day-to-day activities, and it didn't look like they were about to -- even if most apps were now tailored to run properly as non-admin. Worse, many of the security problems with Windows could be traced directly to running as admins. Any malware that ran in such a scenario also ran as admin, and therefore had the run of the system by default.

To that end, Vista came with User Account Control, which was designed to secure Windows but also allow people to continue working as they had before.

UAC explained
UAC uses a feature of Windows's security infrastructure called tokens. A security token is a way to grant an object -- a user, a process, a thread, a file, etc. -- a set of permissions for certain actions.

More advice from our Windows expert:

How to troubleshoot a Windows system that won't shut down

What to look for when switching from 32-bit to 64-bit Windows

Assigning the right drive letter for a USB drive

Under UAC, regular users are granted a permissions token that allows them to do things allowed only to regular users. If the user tries to do something that requires admin privileges, UAC kicks in and asks for credentials. If the credentials are valid, the user is given a security token for that one action and nothing else. (The UAC window runs in its own protected process and on a desktop that's separate from the regular user's desktop. Any programs already running in that user's space can't, for instance, spoof keystrokes or mouse gestures to it.)

An admin account running under UAC has two tokens: one for daily regular-user work and one for admin-level privileges. Most programs (e.g., Explorer) are launched under the first token. If you want something run as admin, you'll have UAC poll you for permission first, then launch the app using the second token. In Windows 7, UAC was rewritten slightly so that certain signed system binaries -- like Control Panel apps -- didn't need explicit UAC approval to run. Also, some other system programs, such as Explorer itself, were rewritten to automatically poll the user for elevated privileges when doing things that needed it, like copying files into the Programs directory.

Most of the oversimplified explanations I've read about how UAC works skip the description of tokens entirely and just talks about allowing programs to run under regular and admin accounts. I suspect this is why some people went on to assume that UAC was simply a point-for-point clone of the sudo function in Unix/Linux, but it's a bit more granular and sophisticated than that.

The benefits explained
The benefits of UAC are threefold:

  1. It ensures that programs are not casually launched as administrator, and therefore any malware that might run because of one of those programs isn't able to make changes to the system.
  2. It ensures that programs cannot run as admin without the user knowing about it beforehand.
  3. It allows regular users to run administrative functions without needing access to the whole of the admin account to do so.

Turning off UAC and running as admin all the time removes all of this protection. It would then be far easier for an unwanted program to get a toehold and run wild.

One way you can make UAC less annoying for certain constantly run programs such as an admin-level command line is to create a scheduled task to run the program as admin. This will cache the admin credentials with the scheduled task. You can then run the scheduled task with a shortcut to the SCHTASKS.EXE command-line utility, and it'll run as admin with no UAC prompt. However, note that anything you do to make UAC less prevalent also makes the system that much less secure, so I recommend a trick like this only for running a very small selection of apps on a system that has UAC running normally the rest of the time.

Serdar Yegulalp has been writing about personal computing and IT for over 15 years for a variety of publications, including (among others) Windows Magazine, InformationWeek and the TechTarget family of sites.

Dig Deeper on Microsoft Windows Vista operating system