We're all anxiously awaiting Microsoft's official release of the oft-delayed Windows Vista. In the meantime, Microsoft has released several interim builds of the OS, including the full-featured Vista Community Technology Preview (CTP). In this version, we got our first real look at the new security features and tools that Microsoft plans to include in Vista. One of the most fundamental security changes will be the OS's new least-privilege support, embodied in the User Account Control (UAC) feature. In earlier Vista beta releases, UAC was called Least-Privileged User Account.
In my article "Learn to Be Least" (October 2005, InstantDoc ID 47622), I defined least privilege and showed you how to better honor it in Windows XP. The principle of least privilege states that you should give a user or a piece of code only the privileges it needs to do a job—nothing less, and certainly nothing more. Malicious code can do much more harm when it executes in the security context of a highly privileged account, and highly privileged processes can do much more harm when they're compromised or simply buggy.
Now that Vista is on the horizon, it's time to re-evaluate the concept in light of some new functionality that promises to make it easier for all of us to better honor least privilege. Let's look at how least privilege has evolved, then dive into the new Vista features, including UAC and Admin Approval Mode (AAM), which provide Windows with a more behavior-based dynamic.
Problems Till Now
The problem with XP and earlier OSs is that they require a lot of user discipline to honor least privilege, from both users and administrators. For example, XP administrators who want to honor least privilege must create two accounts: a simple user account (aka a limited account) and an account with administrator-level privileges (aka a privileged account). Then, they must have the discipline to use the limited account to perform their day-to-day work—surfing the Web, reading email, working with Microsoft Office documents—and switch to their higher-privileged account only to perform administrative tasks.
True, in XP and Windows 2000, Microsoft made it easier to switch between logon sessions, but it's still far easier for administrators to use one privileged account to do all their day-to-day work. Using a single account also means the administrative user must remember and maintain only one set of credentials. In XP and Win2K, Microsoft effectively integrated least-privilege tools such as the Secondary Logon service, Fast User Switching (FUS), and the Runas command into the Windows UI. (For more information about these improvements, see "Learn to Be Least.")
The bigger problem is that not only XP administrators but also simple XP users typically use a single account with administrator-level privileges. Working with a limited account in XP can be a frustrating experience because the OS doesn't allow limited user accounts to perform simple administrative tasks such as changing a system's time zone settings, installing additional fonts, or changing power-management options. For this reason, administrators often end up granting simple users administrative privileges. Figure 1 shows the XP warning message that appears when a limited-account user attempts to change the system time.
The bottom line is that average XP users and administrators who value ease of use more than security and who don't want to switch back and forth between two user accounts leave their system open to a wide range of attacks. And let's be honest: How often have you used the built-in local administrator account to log on to your standalone XP workstation?
Redefining Limited Accounts
A fundamental Vista change is that Microsoft has redefined what a limited account can and can't do. For example, Vista lets a limited-account user change the system's time and time zone settings, change display properties, install additional fonts, and change power-management options. This modification essentially removes the need for the Power Users group, which Microsoft has eliminated from Vista. Examples of Vista tasks that still require a privileged account are software installation and disk repartitioning.
Also in Vista, every account—even the built-in administrator account and other administrator-level privileged accounts—initially has only limited user privileges. During logon sessions, users can elevate their privileges to the administrator level when necessary, as I explain later. Starting with Vista Beta 2, this functionality is standard Vista behavior because UAC is enabled by default.
Administrator accounts with initially limited user privileges are possible thanks to a change that Microsoft has made in Vista—specifically, the process of creating access tokens for privileged-account users. An access token contains a user's privileges and is attached to a user-logon session. When a privileged-account user logs on to Vista, the OS creates a filtered token that contains only the user's limited-account privileges and is the user's default token during the logon session. Vista can temporarily expand the filtered token to a full token when the user needs to perform an administrative task or launch an application that requires privileged access. The full token contains all the user's privileged-account privileges.
Redefining Administrative Actions
In Vista, Microsoft has clarified which actions require administrator-level privileges and which don't: All operations that require administrator-level privileges are designated by a shield icon, as Figures 2 and 3 show. Figure 2 shows Vista's Date and Time Properties dialog box. Note that only the Change Date and Time button requires administrator-level privileges; any user can change the time zone settings. Figure 3 shows the Vista System dialog box. As with XP, both changing a computer's name and Windows activation require administrator privileges; Vista, however, marks both actions with the shield icon. Windows administrative buttons that are marked with a shield icon are also called unlock buttons.
In typical enterprise environments, only Help desk personnel will use unlock buttons—for example, when they need to control desktops remotely. In typical home environments, only parents will use the unlock buttons—for example, to make configuration changes for children. With Vista, a Help desk operator or parent can, for example, unlock a Control Panel applet without an employee or child needing to log off first. (This kind of operation is also known as an over-the-shoulder administrative task.) Limited-account users and children can't use an unlock button because they don't know the password of privileged accounts.
When a user clicks an unlock button, selects an action that requires administrator privileges, or starts an installation program that requires administrator privileges, Vista will behave differently depending on whether the user is a limited-account or privileged-account user. If the user is a limited-account user, Vista prompts for alternate administrator credentials; if the user has administrator-level privileges, Vista prompts for consent. Figures 4 and 5 show the dialog boxes that Vista displays when a limited-account user and a privileged-account user, respectively, attempt to change the system date and time.
- In the dialog box that Figure 4 shows, a limited-account user can select one of the system's administrator-level accounts and enter the administrator credentials, or can cancel the privilege-escalation action.
- In the dialog box that Figure 5 shows, a user with administratorlevel privileges can express his or her consent by simply allowing or cancelling the action.
Vista's Group Policy Objects (GPOs) include settings that let administrators change the default Vista prompt behavior for limited-account and privileged-account users. You'll find the UAC-related GPO configuration settings—which begin with the words "User Account Control"—in the Security Settings\Local Policies\Security Options GPO container.
Microsoft refers to this privilegeelevation prompt-based behavior as AAM. Thanks to AAM, users and administrators can honor least privilege in a single logon session. Switching back and forth between limited-account user and privilegedaccount user logon sessions is no longer necessary.
Credential or consent dialog boxes such as the ones that Figures 4 and 5 show can appear multiple times during a user's logon session, appearing whenever a user chooses an action marked with a shield icon. Vista doesn't remember previous elevations to administrator-level privileges. The elevated privileges that are linked to a particular task (e.g., new software installation) automatically expire when the task is finished. For this reason, AAM significantly reduces the Vista attack surface. AAM also presents an important advantage for administrative users, who can now— rest assured—perform their day-today work as regular users and switch to administrative privileges only as necessary or when prompted.