Get better security with Vista by implementing best practices for using User Account Control - UAC Print

Author: Greg Shields
Category: Client

Operating your PC when you’re logged in with an Administrator account is an inherently insecure thing to do. If you’re a user with highly-elevated privileges across multiple machines or an entire Active Directory domain, running your everyday processing with these privileges can be dangerous to the point of negligence.

But as Windows administrators we’ve always known this. We’ve always known that remaining logged into our primary desktops or laptops with our elevated privileges can easily hurt ourselves and others around us. And yet even with all the warnings and the occasional real-life exploit or disaster, many of us continue to work in this unsafe way, and we routinely set up end user PCs with administrative privileges too.

Click here to see Greg Shields' video - Tweaking UAC

Those admin privileges can be dangerous when not used correctly. A user with administrative privileges across an Active Directory domain has the ability to manipulate or contaminate data all across that domain. If malware infects their PC, it is likely to leverage existing administrative privileges for infecting other computers across the network. And malware isn’t the only problem: if they make an inadvertent change on their desktop, widespread administrative privileges can accidentally pass that change throughout the entire IT environment.

And yet until the release of Windows Vista, remaining logged in with administrative privileges was the easiest way for administrators to get their jobs done — and many end users couldn’t work effectively with limited accounts either. Vista’s implementation of least privilege through User Account Control protects the network and makes a limited account more useful, and it doesn’t have to be a succession of irritating prompts either.

Least Privilege, least damage
The idea of Least Privilege is simple enough; there’s even a 30-year-old US Department of Defense definition. “[The principle of Least Privilege] requires that each subject in a system be granted the most restrictive set of privileges…needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.”

Windows has a range of account levels with different privileges you can give users: Account Operator, Backup Operator, Power User, and the all-powerful Administrator. That lets you separate users who are trusted to manage the overall IT system from those who simply need to use it. It’s logical to have a trusted few individuals with rights to affect the experience and configuration of others, and having access to the entire environment for its regular care and feeding should be the exception rather than the rule.

However, Microsoft’s implementation has an intrinsic problem. When you assign a privilege to a user, the user carries that privilege no matter what action they attempt to accomplish. If an administrative user is working in a Microsoft Word document, they retain the same privileges as if they were modifying an Active Directory attribute. This ‘always-on’ approach to privileges and their assignment actually goes counter to the definition of Least Privilege. With Least Privilege, a user’s assigned privileges should rise to meet the needs of the activity they are attempting to accomplish. With Windows, no matter what the activity, the privileges remain the same. Because of this inherent security with the architecture of entitlements, Microsoft has long recommended that users with Administrator access actually login with a separate, non-administrative account for their daily activities. In the very early days, Administrators needed to log out and back in with their elevated account when necessary to accomplish some action. This process was highly time-consuming and faced with being productive or being secure, many admin users ended up sacrificing security.

The way round that is the RUNAS command-line tool which lets you launch an individual process with an alternative account, so you’re running only specific and needed processes with elevated privileges as necessary. Still, RUNAS has its own problems. It still means remembering to take an extra step to launch an application. Some applications don’t work properly with the tool. And most importantly there is no mechanism for governance, ensuring that Administrators use the tool properly.

With Windows Vista, Microsoft integrated RUNAS into the operating system and the user interface through the User Account Control service (which was originally called the Least-privileged User Account). This enforces the idea of privileges and elevation of those privileges only when the extra rights are required. That means administrative users don’t have to be logged in as admin all the time, but they don’t have to remember to request rights before starting a task either. You can set users up with limited accounts because they no longer need admin rights to change the time zone or install a printer driver. And if the MD insists on being able to install applications on his laptop, you can at least limit the damage that can be done because he won’t be running as an Administrator all the time.

Defining User Account Control
With User Account Control, the login token for a user who has administrative privileges is separated into two halves. The first half includes only the necessary privileges required by a standard user. If that user attempts to accomplish a task that requires the use of their administrative privileges, they then switch to using the other half of their login token. This login token includes their assigned administrative privileges. Once complete, the user is switched back to their standard user token again.

The benefit of splitting the user token is that an Administrator can now launch an elevated activity without requiring the extra steps of RUNAS or a login/logout cycle. At the same time, when they do not need the use of their administrative privileges, those privileges remain unavailable for use. This action protects the Administrator from the results of their actions and the potential result of actions caused by malware infections on their system. And if malware attempts to make a change in the system that you haven’t requested, you’ll see the dialog box and have the chance to deny permission.

Unfortunately, the implementation of UAC is not without some issues itself. There have been many negative press reports about User Account Control because of the mechanism by which the credential switch occurs. When the user attempts to accomplish an elevated task, processing on the system is effectively paused while the user is prompted to approve the switch in a dialog box. With the sheer number of activities considered ‘administrative’ by Vista, this can happen dozens or hundreds of times per day depending on the tasks that need to be accomplished.

In the RTM version of Vista, renaming some folders could produce up to four UAC prompts because the SIDs wouldn’t match if you move a hard drive from a PC to an enclosure, for example. SP1 reduces the number of prompts you’ll see because it reduces the number of tasks that require elevation. According to Microsoft’ calculations, 80% of the UAC prompts in Vista RTM were caused by just ten applications. As of April 2008, UAC is turned on in 88% of Vista accounts, 66% of all Vista sessions have no elevation prompts – and only 7% of all UAC prompts are cancelled. Most of those cancellations are in Internet Explorer, where users will encounter an increasing amount of malware.

But there’s an issue with users who you don’t want to give any administrative privileges to. When they try to make an administrative change – like setting the system time rather than just switching to a different time zone – instead of receiving an ‘Access Denied’ error, that user now sees what is called an Over The Shoulder (OTS) elevation prompt. This prompt asks the user to enter an alternative administrative credential to complete the action.

At first glance, this looks like an easy way of doing things, but it’s bad practice for the Administrator to simply provide the credentials to the user, because handing over administrative credentials to standard users for one activity effectively gives them the set for later use. If you’re in the office, ask the user to move away from the keyboard so you can enter the credentials. If not, it’s tempting to give the username and password over the phone but a better alternative is to use Remote Assistance; you both need to be running Vista SP1 for you to be able to handle UAC prompts.

Best practices for using UAC
UAC by default is configured to behave in the most secure way possible, a behaviour that is acceptable to many: the out-of-the-box configuration requires no further changes to work as intended, just some time spent explaining to users what prompts they should accept and which they should cancel. But some Administrators consider UAC prompts to be more of a distraction than an effective security control. Others may see an inappropriate shift of the onus onto the individual user for determining which elevated actions are appropriate.


If you decide you’re comfortable with reducing account security to avoid the prompts or you don’t want limited users to see prompts that you’re not going to allow them to accept, you can choose to turn off UAC. For individual computers that are not part of an Active Directory domain, there are two ways of doing this. From a command line (or on the Start menu), enter the command MSCONFIG.EXE to open the System Configuration control panel (which in itself requires you to confirm a UAC prompt).

 Click on the Tools tab and scroll down to find the entries Disable UAC and Enable UAC. Double-clicking either of these and rebooting the computer will reconfigure UAC.

-- click image to enlarge --







If you prefer a more graphical way to accomplish this process, you can download a free tool called TweakUAC. This gives you a more graphical way to enable or disable UAC. Simply select the option you wish, click OK, and reboot the computer to change UAC’s behaviour.

-- click image to enlarge --
For multiple PCs that are within an Active Directory domain, it’s much easier to use Group Policy. To eliminate UAC using Group Policy, create a new GPO and navigate to ‘Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options’. There are ten group policy objects for configuring UAC.


Three of these are important for completely disabling UAC:
1. ‘User Account Control: Detect application installations and prompt for elevation.’ Set this to Disabled.


2. ‘User Account Control: Behavior of the elevation prompt for standard users.’ Set this to ‘Automatically deny elevation requests’.


3. ‘User Account Control: Run all administrators in Admin Approval Mode.’ Set this to Disabled.

While completely disabling UAC is one way

to eliminate its prompting, doing so is not considered a best practice. Disabling UAC eliminates the protections given to executables that ensure they are launched with the least privileges necessary. It also eliminates the protections given to Internet Explorer through Internet Explorer Protected Mode (IEPM). IEPM adds strong protections against malware by relocating downloaded content to on-system areas that are protected by Windows Integrity Control. Moving downloads to a protected area significantly reduces the chance that downloaded malware can affect the system as a whole.


In the situation where UAC’s prompts interrupt too much, but you wish to retain some of its protections, you can configure UAC to operate in ‘quiet mode’. In this mode, UAC still splits administrator tokens and swaps sessions between the token halves as necessary to complete actions on the system. What it does not do is prompt the user to accomplish that swap. Setting UAC to quiet mode effectively takes the user’s consent out of the process, by automatically assuming any elevation request is approved. Doing this eliminates the prompting, but at the risk that an instance of malware can elevate credentials in the background without the knowledge of the Administrator.


Again you can set this for single systems that are not part of an Active Directory domain with the TweakUAC tool. To use Group Policy for setting UAC behaviour across multiple machines, create a new GPO and navigate to the same location discussed above. In this case, configure only the policy named ‘User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode’; setting it to ‘Elevate without prompting’. Be aware that disabling UAC in this manner will cause balloon notifications to appear on user desktops noting that UAC has been disabled, which may cause them to be more cautious. If you feel they’re more confusing than helpful they can be disabled by configuring the Group Policy setting found at ‘Computer Configuration > Policies > Administrative Templates > Windows Components > Security Center’. There, set ‘Turn on Security Center (Domain PCs only)’ to Disabled.

As you’ll see in navigating through UAC’s Group Policy options, more granular configuration control is available to dial down UAC’s behaviour beyond the options shown here.

-- click image to enlarge --

Your mileage will vary, especially when considering the tradeoff between usability and security within your environment. Given the improvements in UAC elevation in Vista SP1, it’s better to start with more security and find out how far you and your users can live with occasional prompts than to reduce security from the start.


Key Resources
Windows Integrity Control and how it impacts IEPM: