Windows DevCenter    
 Published on Windows DevCenter (http://www.windowsdevcenter.com/)
 See this if you're having trouble printing code examples


Windows Server Hacks

Windows Server Hacks: Preventing Users from Installing Devices

by Mitch Tulloch, author of Windows Server Hacks
04/20/2004

I get frustrated with Windows sometimes, and few things frustrate me more than the complications of installing and configuring new hardware. In the days before Plug and Play (PnP), installing hardware was complicated, but at least you learned about the guts of how Windows managed resources like IRQs, I/O ports, and drivers. It gave you a feeling of control to know how to install and configure legacy hardware, and a feeling of accomplishment when you finally got everything to work.

PnP promised to abolish such difficulties, but the transition from legacy to fully PnP-compliant hardware has been a rocky one over the years. I still get annoyed when I reboot my desktop at home and it recognizes legacy hardware that is already installed and asks if I'd like to install it again. This happens in particular with my HP LaserJet 3100 multifunction printer, and Microsoft's suggested workaround in this case seems to fail. When I try to walk through the New Hardware Wizard as Microsoft recommends, the wizard hangs and installation fails, leaving me with extra copies of this printer in my Printers folder and for some reason I'm unable to delete them.

What a mess. I suppose it's not just Microsoft's fault though, as HP could update their printer installation software to resolve the problem if they tried (I tried their latest driver and it still doesn't resolve my problem). Or perhaps it's my fault for using a printer that is not fully PnP, and I should bite the bullet and shell out money every few years to buy a new printer. That's right -- blame the user.

Installing Hardware on Client Machines

On a company network things can get even more frustrating. One of the great things about recent versions of Windows is Group Policy, which lets you lock down various aspects of your users' environment to limit the amount of damage they can do to their computers when they start messing around. But Group Policy doesn't cover everything, so sometimes you have to look for other ways of locking things down, for instance preventing users from installing new hardware.

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

Normally in Windows 2000/XP only administrators have sufficient rights to install new hardware on a machine, but PnP provides a way around that in some cases. This is because there are two ways in which PnP can install new hardware: server- or client-side installation.

Server-side installation is when you connect a PnP device to your computer and it detects the device and automatically installs it without any user intervention. This kind of installation is performed using SYSTEM credentials and usually happens when the driver (.inf file) for your device was shipped with your version of Windows or if a similar device was previously installed on your machine. The PnP Manager handles everything and the whole process happens in SYSTEM context.

Client-side installation is when you connect a PnP device to your computer and it detects the device but can't find an .inf file suitable for the device or finds an .inf file but it's not digitally signed. At this point installation switches to user mode and the Found New Hardware Wizard prompts you for administrator credentials to complete the installation.

And therein lies the problem. Ordinary users lack sufficient privileges in Windows 2000/XP to install hardware manually using the Add Hardware in Control Panel. But unless you've plugged the USB ports on the back of their computers with epoxy, they can still connect a camera, scanner, flash drive, or other USB device to their machines and see what happens. And if Windows contains a driver for the device, a server-side installation will occur and the device will automatically be installed without a hitch (if Windows doesn't have a driver for the device then the user is out of luck unless he's somehow obtained the password for an administrator account).

Unfortunately Group Policy doesn't provide a way of preventing this, but there's an interesting workaround. Just delete the Driver.cab file, which contains all of the device drivers included with your release version of Windows. This file is found in the C:\Windows\Driver Cache\I386 folder on a desktop system, but it's a hidden file so you have to change your folder options to view it.

If you delete this file on a user's machine, then when a user connects a new device to his or her machine and the PnP Manager starts the install process, it won't find a driver locally and will prompt the user for administrator credentials to complete the installation. If you've kept your system patched and up to date with the latest service pack (Service Pack 4 for Windows 2000) then also be sure to delete the sp4.cab file found in the same folder because this file also contains drivers for supported devices.

An alternate approach is changing the ACL on the Driver.cab file so that the SYSTEM built-in identity has Deny Full Control permission. This may also work, although I haven't tried it yet. You could change the ACL on the file using cacls.exe in a login script.

Another approach might be to change the following registry key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\DriverCachePath

So that it points to some other folder than %SystemRoot%\Driver Cache. That way the PnP Manager won't be able to find the driver cache and installation should fail. I haven't tested this either, so try it on a test system before deploying this registry change using Group Policy.

Still another approach would be to use a third-party product like SecureWave's SecureNT or SmartLine's DeviceLock to lock down I/O and device interfaces on your desktop machines.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.


Return to WindowsDevCenter.com.

Copyright © 2009 O'Reilly Media, Inc.