• subscribe
June 23, 2010 02:29 PM

Solving User Account Problems

Changes in Windows security models help you configure User Account Control and Least-Privileged User Accounts
Windows IT Pro
InstantDoc ID #125157

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).

 



ARTICLE TOOLS

Comments
  • Stenberg
    2 years ago
    Aug 09, 2010

    (please ignore double post - refreshed an old browser window and it sent message again...sorry).

    Thanks Russell - I'll try both your suggestions. Regards, Bryce.

  • 2 years ago
    Aug 09, 2010

    Thanks Russell - good article. I still have one situation I can't get around - I was hoping you may have some ideas to help. When some machines are logged on with admin accounts I want some commands to run that are in the startup folder but they need elevated admin rights - instead of even prompting they just fail to run putting out a message to command window 'The requested operation requires elevation (Run as administrator)'. I don't think I can change the manifest for the command prompt, if one even exists. For example one command is a 'netsh' run from a '.cmd' file. I tried creating a shortcut to it and then under 'properties, compatability tab' set the option 'run this program as administrator', but this is always greyed out. Do you know of a way around this sort of issue without turning off UAC?
    On more than one occassion I've wanted batch files to run that need elevated privilege and would even find it acceptable if the user was just prompted for elevation instead of commands failing and user having to manually open a command prompt with admin privilege and then navigate to batch file and run it. Is there a way to do any of this with Windows 7 that is a domain member? Thanks.

  • Smith
    2 years ago
    Aug 09, 2010

    The easiest way around this would be to set up a Group Policy startup script to run the netsh command. GPO startup scripts run in the context of the local machine account, which has administrative privileges. As the name suggests however, startup scripts run once before users log on.
    If the netsh command must run as users log on, the elevation power toy (http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx) should do the trick.

  • Stenberg
    2 years ago
    Aug 08, 2010

    Thanks Russell - good article. I still have one situation I can't get around - I was hoping you may have some ideas to help. When some machines are logged on with admin accounts I want some commands to run that are in the startup folder but they need elevated admin rights - instead of even prompting they just fail to run putting out a message to command window 'The requested operation requires elevation (Run as administrator)'. I don't think I can change the manifest for the command prompt, if one even exists. For example one command is a 'netsh' run from a '.cmd' file. I tried creating a shortcut to it and then under 'properties, compatability tab' set the option 'run this program as administrator', but this is always greyed out. Do you know of a way around this sort of issue without turning off UAC?
    On more than one occassion I've wanted batch files to run that need elevated privilege and would even find it acceptable if the user was just prompted for elevation instead of commands failing and user having to manually open a command prompt with admin privilege and then navigate to batch file and run it. Is there a way to do any of this with Windows 7 that is a domain member? Thanks.

  • Smith
    2 years ago
    Jul 23, 2010

    Thanks for the feedback. Maybe the executable really does require administrative privileges to run? So when you force it to start as a standard user it fails to launch or hangs. You might try using Process Monitor from the Sysinternals tool set to investigate the problem further.

You must log on before posting a comment.

Are you a new visitor? Register Here