Windows Server Reference Guide

User Account Control: The Trend Toward Lockdown

Created Sep 26, 2003.

There’s a huge debate going on at the time of this writing—whose relative state of calm I admittedly haven’t helped much—regarding whether, as a result of new architectures being introduced in Windows Vista and Windows Server 2003 R2 (later in Longhorn Server), the usefulness of anti-virus utilities is diminishing, or has perhaps been completely outmoded.

For some, this very notion is blasphemy, as one of Microsoft’s own executives found out after hearing responses to his suggestion that Vista may be quite safe without any kind of anti-virus whatsoever. Rather than take sides in this debate in this context, let’s take a good, hard look at the Vista features that could, when used properly and in conjunction with one another, effectively reduce the need for third-party, resource-intensive anti-virus utilities as we have come to know them.

Please Pardon the Interruption

Dividing the pool of users into two groups, and no more, enables you to make much simpler decisions about how restrictions should be applied. Essentially, from the perspective of the desktop or mobile machine (i.e., not the server), there should be two groups of accounts. This is not because there are two types of people; there’s nothing psychological or cultural about this decision. "Administrator," in short, is not a rank. The reason for this simpler, bipartite division is all about keeping control of those accounts in a system that have control.

When Windows first emerged as an upgraded version of essentially a home computer operating system, accounts didn’t exist—the machine didn’t keep track of who did what. (Why would it?) With Windows 95, when accountability became an option, naturally, it was widely rejected among consumers. And in Windows 98, Microsoft’s attempt to make accountability mandatory became something of a joke, with accounts not having passwords by default, and with non-protected accounts having administrative access by default. Windows XP addressed this problem, but never actually fixed it.

By default, when you create a new account in Vista, a standard user can perform most administrative tasks, except for the fact that each time a user with that account does so, she’s prompted for permission. Normally, this permission only comes in the form of a button click; with changes to local policy, permission can be upgraded to entering a password.

Now, you might think that’s silly because, after all, everyone will inevitably know the password. But this kind of control isn’t about who has the password or the key or who doesn’t; it’s about the act of entering the password. The password effectively says the administrator has given the active standard user permission to proceed. So in waiting for that permission — or, in the absence of a password, in waiting for the mouse click — Vista locks itself down tight. The majority of the screen goes grey, and all user processes are suspended, pending the outcome of what goes on in the logon dialog box.

A human being has to provide that permission, because for the time being, only the keyboard and mouse will work. Network access is shut off, and the firewall is on lockdown mode. Meanwhile, inside the local system itself, no other processes are given the authority to function. So what may seem on the surface to be almost pointless actually serves a very vital purpose: it provides a way for Windows to lock down any automated process that may try to acquire administrator-level control.

This lockdown mode is what Vista calls the secure desktop. In typical Microsoft fashion, the "locked-down" nature of the secure desktop can be turned off with a local policy setting. In that case, the user still sees the permission dialog, though it doesn’t take over the system. Without the lockdown, the elevation dialog is somewhat silly.

Nevertheless, Microsoft seems to have finally realized that malicious remote exploitation of a machine relies on the ability for that machine to remain functional to that remote user — in an electrical sense, to be a closed circuit. User Access Control flips the switch that opens the circuit.

Unfortunately, User Access Control is an option; though it’s turned on by default, there’s an easy switch for users to turn it off, and I’m afraid that most non-Microsoft documentation on Vista written to consumers will instruct them to do this first to "avoid the headaches." The very fact that it’s an option creates a new danger point that, I’m hoping in future service packs, will be thoughtfully eradicated: If the "on/off" state of UAC, for instance, is stored someplace in the System Registry, I fear there may be some academic means of spoofing that state or overriding it, so that any attempt to turn it on once it’s off may be ineffective. Of course, if UAC is turned on to start with, this feat may be harder to accomplish.

Getting Over the Demotion

Here is how a "power user" such as myself would tend to set up Vista just like any other operating system: I create an administrator account for myself, under the notion that only someone as smart as I should be responsible enough to serve as the administrator.

But here is a principle that UNIX and Linux administrators learned first: On a well-run system, "admin" should not be a rank. In fact, it doesn’t even really need to be a real person. Rather than denoting the qualifications of a human user, the admin account should be used as a way to authenticate a system-altering activity; and if used well, the authentication should serve only for that activity, not for the entire session.

Microsoft now has a special name for humans, as they pertain to using the operating system: "interactive users." This is a little odd, because it seems we’ve been able to interact with machines in the past; but the company wanted to avoid a culture conflict, perhaps on the part of any Windows users out there who may be sentient, though not necessarily human. Personally, I’d prefer to stick to the special stereotype, if you don’t mind.

Demoting all humans to standard users, then creating the administrator account, simply creates the presence of the admin password. Now, a standard user can know this password, but the principle is, he has to apply that password only when a system-changing activity takes place. The admin account isn’t some constantly-running session that a malicious user can presume to be active someplace in the network; instead, it comes on and turns off like a flashbulb.

With Vista, there’s a little bit of incentive for those whose egos might otherwise be offended by the notion, to demote themselves to the role of standard user: By default, a standard user is not prohibited from initiating any system-altering activity. Instead, CUA simply locks down the system as I described earlier, just before those activities that might have an impact on the system.

For a standard user, this is the first system-stopping dialog he’ll see. After clicking Continue, CUA will stop her again.

Why stop a standard user twice? The two stops give Windows two opportunities to apply policy controls. The first comes when the standard user account is to be elevated to admin status for the purpose of the requested task. Here, a policy setting has the opportunity of halting the operation completely: User Account Control: Behavior of the elevation prompt for standard users can be set to Automatically deny elevation requests, which effectively limits what the standard user can do. You’ll find this in the Local Security Policy console, under Local Policies, Security Options.

This setting effectively turns off the elevator, if you will, changing the meaning of the boundary between the Users group in local group policy and the Administrators group. Shut this off, and one cannot get elevated to the next level, even temporarily.

The second prompt governs what the administrator can do once his account is elevated. A policy setting — specifically, User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode — determines whether the user, who has just been elevated but who stands at the top of the staircase, if you will, has to just click Continue, or whether he has to enter the administrator password and click OK.

Including the password line changes the elevation dialog into a policy enforcer, adding the challenge for the would-be admin to authenticate himself.

As I stated earlier, there doesn’t really have to be an administrator person for there to be an administrator account. In the demonstration whose screenshots you’re seeing here, there isn’t really an administrator account, nor is there a member of the Administrators group in this Vista installation. By keeping Accounts: Administrator account status set to Disabled, you establish a situation where there is no admin account to be hijacked. When Vista is attached to the network, this eliminates a big potential weak spot: the ability for a malicious user to spoof a highly-credentialed user without tapping into Active Directory.

Books and E-books

• McFedries, Paul. Microsoft Windows Vista Unveiled. SAMS Publishing, 2006. Preview "User Account Control: Smarter User Privileges" from Chapter 6, "Security Enhancements in Windows Vista," on Safari.