Solving User Account Problems

I recently needed to print an airline e-ticket in Internet Explorer (IE) using my Windows 7 notebook in a small guesthouse. I could have copied the information to a Microsoft Word document, transferred the file to a USB drive, and asked the hotel owner to print the document from his own laptop, but he kindly offered me his inkjet printer, which I promptly connected to my notebook. The owner suggested that maybe I’d need the driver disk to complete the installation. I confidently declined his offer in the faith that my Internet-connected notebook would have no problem locating the appropriate driver on Windows Update, which it did within a few seconds, and I was able to print. The entire process was fast and painless, and most importantly, didn’t require me to elevate my standard user account to admin privileges to complete the installation.

Unlike previous version of the OS, Windows 7 searches Windows Update before checking the system for drivers. This makes the process of installing new devices more reliable and much faster than before, provided you have a connection to the Internet.

The first step many sys admins take when provisioning a new computer, especially notebooks, is to move domain user accounts into the local administrators group and, worse still, disable User Account Control (UAC) in Vista and later. This is often to facilitate support, in situations similar to that described above, where users need to install a device driver or perform some other admin-level task. However, changes in the implementation of UAC and the security model in Windows 7 make it more realistic for users to run without admin privileges.

Installing Devices

The DevicePath registry value has existed in Windows for a long time. It lets admins specify trusted locations in addition to the default %SystemRoot%\inf folder where the system searches for device drivers when a new device is connected. Starting with Windows 7, standard users can add signed drivers to the local driver store from locations specified in the DevicePath registry value or Windows Update.

If you store driver packages on the network, you can modify the DevicePath value in the registry to include the appropriate network path to make sure Windows scans both the in-box drivers and the network repository: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath. Additional paths should be separated from each other by using semicolons: %SystemRoot%\Inf;\\servername\drivers.

Windows 7 still requires that drivers be signed with a valid certificate that’s trusted by the local computer. Additionally, 64-bit versions of Windows have special requirements for kernel-mode drivers, which must be signed by a Software Publishing Certificate from Microsoft’s list of approved Certification Authorities (CAs). Although the majority of devices available can now be installed in Windows 7 without admin privileges, the Windows Driver Kit contains the tools required to sign device drivers. It’s available for free download at Microsoft’s website.

Windows 7 and Windows Vista contain a handy utility called pnputil.exe that can be used to pre-stage drivers in the local driver store. After a driver is placed in the local store, it’s considered trusted and will install silently when a user connects the associated device. While pre-staging drivers by using pnputil.exe might not be strictly necessary, it provides the most reliable user experience when a previously uninstalled device is connected. Drivers already added to the local driver store can be enumerated using pnputil.exe and specifying the -e switch. Additionally, pkgmgr.exe (Vista WAIK) and DISM (Windows 7) can be used to add drivers to the local store of offline system images.

A Group Policy setting in Windows 7 and Vista lets you specify devices that standard users can install by GUID. The Allow non-administrators to install drivers for these device setup classes policy setting can be found in Windows Server 2008 and later under Computer Configuration\Policies \Administrative Templates\System\Driver Installation. Standard users can install device drivers in the following scenarios:

• Windows includes a driver that supports the device being connected.

• The driver for the device has been pre-staged by an administrator in the local driver store using pnputil.exe or dism.exe.

• A driver signed with a valid certificate and trusted by the local computer is available on Windows Update or in a location specified in the system’s DevicePath registry value (Windows 7 only).

• A driver signed with a valid certificate and trusted by the local computer is available and the associated device GUID is listed in the Allow non-administrators to install drivers for these device classes policy setting (Vista and above).

 

 

Network Printers

As if deploying and managing printers isn’t difficult enough, introducing standard user accounts on your workstations can make the task even more arduous. Much confusion surrounds the ability of standard users to install drivers for networked printers. One of the frequently overlooked advantages of utilizing Windows Print Servers on your network is that in most cases, users don’t require admin privileges to install network printers hosted on Windows Servers. If the printer driver installed on the print server is an in-box Windows driver (i.e., included as part of the default Windows installation), or a signed printer driver package, users don’t require admin privileges to install those printers. Furthermore, Group Policy can be utilized to deploy printers via the Print Management console without requiring users to have admin privileges.

Because many companies have an aversion to the additional expense of running a Windows Print Server, there are some workarounds to get other networked printers installed for standard users. The key problem in dealing with networked printers that aren’t hosted on a Windows Print Server is that to deploy the printer, a local TCP/IP port must be configured on each client, which requires admin rights.

Group Policy Preferences can be used to deploy TCP/IP printers to standard users, but the catch is that for the initial deployment, the printer must be installed on a Windows Print Server to distribute the driver. Once the printer has been installed on all the required devices, the Windows Print Server can be switched off and print jobs sent directly to the device. Some vendors provide their own solutions, such as HP’s Universal Print Driver. In practice, using Group Policy Preferences to deploy TCP/IP printers to standard users has a couple of caveats:

• You’ll need to deploy the Group Policy Preferences client-side extensions to computers not running Windows 7.

• If you use computer configuration preferences to deploy TCP/IP printers, you should additionally disable the Point and Print Restrictions setting in Group Policy under Computer Configuration\ Administrative Templates\Printers to ensure that warnings or elevation prompts aren’t shown during the installation.

• Group Policy Preferences supports deployment of printers only if the WinPrint print processor is selected when installed for deployment on the Windows Print Server. If you select anything else, the print processor must already be installed on devices to which the printer will be deployed. The WinPrint print processor might not support advanced functionality of your printer.

Unwanted UAC Elevation Prompts

Over the last few years, I’ve come across a few applications that insist on being run with admin privileges without good reason. For example, you log in as a standard user, try to launch an application, and you’re presented with a UAC elevation prompt demanding the password for an administrator account. In this situation, failing to enter a password and clicking No in response to Do you want to allow the following program to make changes to this computer? means you won’t be able to run the program.

At first glance, it might seem there are only two solutions: Run the application with admin privileges or turn off UAC, neither of which is likely to be desirable. Each executable on a system can be accompanied by an application manifest, which is an .xml file that specifies several parameters in relation to how the application interacts with UAC. Usually application manifests are embedded inside executable files, but can sometimes be found as standalone files in an application directory.

To work around the problem outlined above, Microsoft has included a shim as part of the application compatibility infrastructure: RunAsInvoker enables the application to run with the privileges associated with the creation process, without requiring elevation. Wherever possible, however, it’s preferable to modify the executable’s manifest.

 

 

Heaven Tools has a program called Resource Tuner that lets admins modify application manifests embedded in precompiled executables. Running the tool and modifying the .xml code couldn’t be simpler. All you need to do is find the Manifest folder in the resource browser and change the requestedExecutionLevel value from requireAdministrator to asInvoker, then save the changes to the executable. Here’s an example of the security tag in an application manifest file:

uiAccess="false"/>

If you’re using Visual Studio (VS), mt.exe can be used to add or modify an application manifest. It’s also part of the Windows SDK.

If modifying the application manifest isn’t possible, you can load the Application Compatibility Toolkit (ACT) 5.5, a free download from Microsoft, and use Compatibility Administrator to create a compatibility fix using the RunAsInvoker shim and deploy the resulting database to your workstations:

1. Log in to Windows 7 as an administrator and install ACT.

2. Open Compatibility Administrator in the Application Compatibility Toolkit 5.5 folder on the Start menu, and below Custom Databases in the left pane select New Database and press Ctrl+R.

3. Give the new database a name and press Enter.

4. Press Ctrl+P to create a new application fix. In the Create new Application Fix dialog, type the name of the program to be fixed.

5. Click Browse and find the executable you want to apply the fix to and click Open. Click Next to continue.

6. On the Compatibility Modes screen, select None under Operating Systems and click Next. On the Compatibility Fixes screen scroll down the menu and select the RunAsInvoker fix, which Figure 1 shows.

7. At this point you can click Test Run to see if the fix has the desired effect on the application. Click Next to continue.

8. On the Matching Information screen, you can fine-tune how the compatibility engine identifies the executable. Let’s leave the default settings and click Finish.

9. Click the Save icon at the top of the Compatibility Administrator window (see Figure 2), and save the database to the C drive on the local computer.

10. Select Install from the File menu and click OK to confirm the installation of the database. You should now be able to run the targeted application without the need to elevate privileges.

After the compatibility fix has been thoroughly tested, it can be distributed. To do so, use Group Policy and a batch file that calls the sdbinst.exe command line.

UAC as a Security Boundary

Microsoft has famously stated that UAC is a security feature and not a security boundary. Though logging in using a protected administrator account doesn’t provide a security boundary, a standard user account with UAC enabled provides a boundary of sorts. The default UAC configuration enables what’s known as over-the-shoulder (OTS) elevation. If UAC is triggered by an application installer, or an application manifest requires an executable be launched with admin privileges, you are prompted to enter an administrator password before you can proceed. This process takes you to the secure desktop, a session that’s isolated from the user’s desktop to stop interference from malware, where you can safely enter an administrator password. It sounds pretty secure.

The dilemma with OTS elevation is that malware could imitate the secure desktop and steal the administrator password as it’s entered by an unsuspecting user. Hence, Microsoft recommends disabling OTS elevation for standard user accounts in Group Policy to mitigate this vulnerability in enterprise environments.

Disabling OTS elevation also means that you’ll no longer be able to right-click an executable and select Run as administrator from the menu. This might seem like a drawback for support staff, but you can hold Shift and right-click to select the Run as different user menu option.

An alternative to disabling OTS elevation is to turn on the Secure Attention Sequence (SAS) in Group Policy settings. Instead of being automatically taken to a secure desktop for the OTS elevation prompt, users must press Ctrl+Alt+Del before the secure desktop is presented (see Figure 3). As the SAS can’t be emulated other than by physically pressing Ctrl+Alt+Del, the user can be sure that the secure desktop is genuine. SAS can be enabled in the Require trusted path for credential entry Group Policy setting under Computer Configuration\Policies\Administrative Templates\Windows Components\Credential User Interface. Bear in mind that SAS might present a considerable inconvenience if elevation is required on a regular basis.

No Security Utopia

Windows 7 makes it easier than ever to work as a standard user, both at home and in the enterprise. However, as more users log in without admin privileges, malware is likely to evolve and target the user’s login session. Technologies such as Software Restriction Policies in Vista and earlier and AppLocker, available in Windows Server 2008 R2 and in some editions of Windows 7, can be used for application whitelisting, which will become increasingly important in preventing the execution of malware of this type.