This documentation is archived and is not being maintained.
Achieve the Non-Admin Dream with User Account Control
At a Glance:
- Why you shouldn't run as administrator
- Addressing problems trying to run as standard user
- How User Account Control works
Fewer users running with administrator privileges is a worthy goal in most IT organizations. But while IT administrators generally agree that restricting users to a standard user account is the way to go, about 80 percent deploy their desktops with admin accounts, making those
machines more susceptible to malware and harder to manage. But it's not that easy to avoid the admin account. The potential obstacles you'll face if you try are numerous.
First, there's application compatibility. Because many applications were written and tested using administrator accounts, they may not even run under standard accounts. (This is most often the case because the applications attempt to write to restricted areas such as the Program Files directory or HKLM registry keys.)
Second, earlier versions of Windows® were overly restrictive about which settings users were allowed to configure. Standard users could not change the time zone, power settings, connect to secure wireless networks, or install ActiveX® controls without calling the helpdesk, which has associated costs.
Fortunately Windows Vista™ addresses these concerns. And even if your users don't have admin accounts, User Account Control (UAC) and other management technologies in Windows Vista make it easier to support and manage those desktops, promote higher productivity for standard users, and do it all without the looser security that results when you modify access control lists (ACLs)—the usual method of providing users greater, customized access. Let's look more closely at how Windows Vista alleviates some of your access control issues.
Virtualization Improves Compatibility
Many applications that will not run as a standard user on Windows XP will be able to run without modification on Windows Vista because of the File and Registry Virtualization capabilities. In Windows XP, many applications break when they attempt to write to protected areas of the file system and registry that the standard user is not permitted to access. Windows Vista will improve compatibility by redirecting writes (and subsequent file or registry reads) to a special location within that user's profile. For example, if an application attempts to write to C:\program files\contoso\settings.ini and the user doesn't have permission to write to that directory, the write will be redirected to C:\Users\username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. If an application attempts to write to HKLM\Software\Contoso\ the action would automatically be redirected to HKCU\Software\Classes\VirtualStore\MACHINE\Software\Contoso. Figure 1 outlines the redirection process. In addition, the Certified for Windows Vista Software Logo Program will require that an application will run as standard user without requiring virtualization; if it doesn't, the logo will not be awarded to the application.
Figure 1 File and Registry Virtualization Process
Standard Users Can Do More
In Windows Vista, standard user accounts have been given additional privileges so users can perform common tasks without helpdesk support and without having the full set of permissions provided by the administrator account. The new privileges include the ability to view the system clock and calendar, to change the time zone, to modify wireless network security settings, to change power management settings, and to download and install critical updates from Windows Update.
Additionally, disk defragmentation is an automatically scheduled process in Windows Vista. Actions that do require administrator privileges are marked with a shield icon, so users can see what configuration changes they can and can't make.
ActiveX Control Installation
ActiveX controls can be particularly tricky to manage centrally because they may update frequently and they need to be repackaged before they can be distributed through a software distribution program like Systems Management Server (SMS) or through Group Policy. Windows Vista includes an optional component called the ActiveX Installer Service that allows IT administrators to use Group Policy to specify Web sites from which standard users will be allowed to install ActiveX controls. To use the ActiveX Installer Service, do the following:
- Enable the ActiveX Installer Service on the client computers. You can enable the service through the Windows Features Control Panel applet or when you configure your desktop image.
- In Active Directory Group Policy, in Computer Configuration | Administrative Templates | Windows Components, select ActiveX Installer Service. Select Enable. Now after the policy is replicated to the users, they will be able to install controls from the sites you specify.
Since ActiveX controls and other executable code could perform malicious tasks, use this feature judiciously; use it only for vendors you trust and only on intranet sites that are under strict control.
The ActiveX Control Installer Service is also integrated with the Windows Vista Eventing Infrastructure, so you can be notified automatically if there are ActiveX controls your users need to install. When a standard user tries to install a control that has not been approved, the service creates an event in the Application Log. In Windows Vista, tasks can be configured to automatically send an e-mail or execute another program as soon as an event is triggered. Then you know when a user needs a control and you can add the site to Group Policy without the user experiencing significant down time. With Windows Vista you can also subscribe to events from multiple machines across your enterprise and generate a list of all the controls your users are trying to install.
Hardware Device Driver Installation
Concerns that users will be unable to install device drivers they need when traveling is another reason administrator permissions remain popular, particularly for laptop users. The new Driver Store infrastructure in Windows Vista alleviates this hurdle by allowing flexible control over devices that standard users can install. First, you can prepopulate the Driver Store with trusted drivers so users can install permitted devices as they need them. Second, you can use Group Policy to give standard users permissions to install classes of devices, such as printers, or even specific device hardware IDs, such as permitted flash drives.
Since the Windows Vista Driver Store is a trusted cache of in-the-box and third-party drivers on the hard drive of each client machine, users may install them without administrator privileges. To stage drivers in the Driver Store, you can either inject them into offline images or dynamically update drivers to online clients over the network. For offline images, use Package Manager to seamlessly stage drivers in the Driver Store.
For online images, use command-line utilities such as pnputil.exe or DevCon in conjunction with software distribution applications to add, update, or delete drivers in the Driver Store. To further streamline and add flexibility to the process of staging drivers, Windows Vista allows IT departments and third parties the ability to sign driver package integrity.
By default, only users with administrator rights can add new drivers to the Driver Store. But there is a critical need for users, particularly mobile users, to install devices like printers while they're on the go. With new Group Policy settings, Windows Vista enables you to give standard users the flexibility needed to install permitted devices even if drivers aren't already staged in the Driver Store. To delegate device driver staging privileges, open the Group Policy interface and navigate to Computer Configuration | Administrative Templates | System | Driver Installation | Allow non-administrators to install drivers for these devices. You'll need to know the GUID for the device classes you want standard users to stage and install. You can find device classes online at MSDN® or if the device is installed on your machine, go to the Device Manager | Properties window. Click on the Details tab and select the dropdown labeled Device Class GUID. You also need to make sure the certificates used to sign the drivers are already in the client machine's Trusted Publishers store, which can be managed via Group Policy.
These advances in Windows Vista now provide standard users with the needed flexibility in device installation so you can move more users to a managed desktop environment.
Levels of Desktop Lockdown
Even with these improvements in the Windows Vista OS, not every organization will be able to deploy all of their Windows Vista desktops with standard user permissions. Some organizations may have applications that still require administrator privileges or they may have users, such as developers, who need to install their own software. That's OK. Windows Vista allows multiple levels of desktop control, configurable through user account selection and Group Policy, all of which provide more manageability and security than a full administrator account on Windows XP. Most system settings relevant to UAC settings can be found in the Security Policy Editor (secpol.msc), which is shown in Figure 2.
Figure 2 Security Policy Editor (Click the image for a larger view)
The first level of control is called Admin Approval Mode. This mode reduces the threat of some types of malware attacks by starting programs with standard user privileges by default and alerting the user if a program is attempting to run with administrator privileges. In this mode you can perform audits through the event log when the user runs a program that requires administrator rights. But keep in mind that while an application may run with standard user privileges, this mode doesn't provide the same security as a true standard user account. The user still has administrator privileges and can change policy settings, install unapproved software, and allow powerful malware such as a rootkit to be installed.
The next level builds upon the first, but uses Group Policy to restrict elevation to programs that are signed with a certificate that is in the Trusted Publishers store. This can help prevent unsigned malware from obtaining administrator privileges and can prevent users from installing arbitrary software. However, when running with administrator accounts, savvy, unscrupulous users, or sophisticated malware could disable the policy, at least temporarily, to perform unauthorized actions. Therefore, these first two levels should be used as interim measures while resolving any issues that prevent you from issuing true standard user accounts.
The next level of security comes from removing users from administrator accounts and making them standard users. One feature of UAC is called the Over the Shoulder Credentials Dialog, which standard users will see by default if they start a program that requires administrator credentials. Standard users are blocked from performing that action, but if they know the username and password of an administrator, they may enter it and continue the action. A typical scenario in which this feature could be used involves a traveling laptop user. If, for example, the user has an urgent need to install a piece of software while he is on the road, he could call the helpdesk who could provide the password for a local administrator account, which the user could enter and allow the program to run (see Figure 3). If you provide the administrator password to the user, I recommend that you have processes and tools in place to reset the administrator password when the user reconnects to the network, and that you log the programs that have been run using the administrator credentials. Also be aware that if the PC has been infected by malware, the administrator may be tricked into giving demonstrators privileges to malware that they did not intend to.
Figure 3 Requiring an Admin Password (Click the image for a larger view)
You also have the option of disabling the credentials dialog using Group Policy. Set the User Account Control: Behavior of the elevation prompt for standard users setting to Automatically deny elevation requests (see Figure 4). This is the way we recommend that most enterprises that deploy standard user desktop should configure UAC. Most organizations would do this to prevent the user from calling helpdesk for a password that the IT department doesn't want them to have.
Figure 4 Application Blocked by Group Policy (Click the image for a larger view)
For the strongest level of desktop lockdown you can use UAC and standard user accounts combined with Windows Software Restriction Policies (SRP). With SRP, enterprises can go an extra step and prevent any software from running that they did not specifically allow. SRP is designed to block the execution of software unless it meets specific criteria based on Authenticode® certificate, hash, path, or Internet Zone. SRP is managed through Group Policy, and you can create a very powerful policy to prevent the installation and execution of non-approved programs with little work. A typical policy might disallow all executables except any found in these paths: %WINDIR% and %PROGRAMFILES%, and apply polices to all users except administrators.
With this policy in place, the IT staff can still install whatever software programs it wants into the Program Files directory without having to add each .exe to a whitelist (a list of accepted items). And since the standard user does not have access to these directories, he or she cannot place it somewhere that it will execute.
You may have noticed there was no mention of the Power User group. That's because the Power User group has been removed from Windows Vista. Some organizations used the Power Users group in an attempt to limit administrator privileges. While making someone a power user may prevent him from making unapproved system configurations, he (or malware running with power user credentials) may be able to gain additional rights and permissions and even complete administrative credentials. For that reason, Windows Vista has administrator and Standard user as the two primary account types.
Desktop Management Infrastructure
Using File and Registry Virtualization, the new Driver Store infrastructure, and the other features I discussed will make it much easier for you to deploy Windows Vista desktops with standard user accounts. Even with these techniques, however, you will not be able to support a standard user environment completely unless you have the management infrastructure—tools, processes, and people—to support users who cannot do some things on their own. Some of the issues you need to consider are:
Software Installation If users can't install software on their own, you need to provide another way. One way, which doesn't require any other management software, is to use Group Policy. With Group Policy, you can add a program to the Add/Remove programs list. If a user installs a program using this method it will launch with the elevated permissions needed for the user to complete the installation. For a richer solution you could also use SMS or a similar product. Some solutions even allow you to create self-service Web portals where standard users can pick and choose the software they want to install.
Software Updating You'll need to have a way to install updates on your PCs, other than sending out an e-mail that says, "Please install this update!" To manage and deploy most Microsoft updates you can use Windows Server Update Services, which is a free download for Windows Server. To deploy a broader range of updates, again, you may consider a desktop management product such as SMS.
Support Processes and Staffing When a user calls the helpdesk about something that is causing a performance problem or wants to install something new, in many cases you won't be able just talk them through the process over the phone, since they may not have permissions. Your IT department will need to make greater use of remote assistance and remote administration tools to diagnose issues and change settings. Even Windows Remote Assistance will work differently because logged-in standard users cannot approve the prompts for actions that require administrator privilege, though helpdesk staff could use Remote Desktop to make administrative changes remotely.
It will be critical to have clear, efficient processes for handling policy exceptions. Let's say someone in the marketing department needs to install a trial version of a new graphic design tool she is evaluating for her department. Who gives the approval to install that software—her manager, her director, or the CIO? How will it get installed and how long will she have to wait? We suggest creating a simple approval workflow that is integrated with the helpdesk issue tracking system. A basic workflow could be:
- User submits request to install a program and the link to the installation program (on their local hard drive or in their CD tray), and confirms that the software was not obtained illegally and is not being used for malicious purposes.
- Request is sent to manager for approval.
- Request is routed to application lead in IT department who can check to ensure there are no known compatibility problems, perform a virus scan, and make sure that the company has not already purchased a site license for that program or a similar program from another vendor.
- Request is forwarded to a support technician to remotely initiate the installation and notify the user when the software is ready for use.
To create the workflow interface you could either script dynamic Web pages or obtain a commercial helpdesk or issue-tracking package. You will also require different staffing for a managed versus an unmanaged environment. Hopefully, you will need fewer technicians to physically diagnose or reimage unstable or infected PCs. However, you may need to initially allocate additional staff to software packaging and deployment.
Over the long run, you should experience lower support costs as machines remain stable longer, but initially you may experience an increase in helpdesk calls from users asking for help with configuration. The helpdesk calls will taper off after you configure your desktop images and group policies with the settings users need and expect.
The final hurdle is not technological, but psychological. Some users may have an adverse reaction to the idea of not having administrator privileges. But I believe most users won't notice a difference. And if you deploy Windows Vista at the same time that you enforce standard user accounts, the productivity benefits of the integrated desktop search, the new Aero™ (glass) user interface, and the improvements for mobile users will outweigh any inconveniences that come from not being an administrator. However, if poor processes cause people to wait for weeks to get permission to install a piece of software, then you can expect to have some unhappy employees.
Fundamentally, it's the IT department's responsibility to ensure the security of the PC assets, prevent the use of unlicensed software, and enforce compliance with government regulations and internal policies. Most companies will find that the only way to do this is to enact a new policy of restricting the number of users who have administrator privileges. Luckily, you'll find this much easier to do on Windows Vista.
For help in reducing administrator privileges: