TechNet Magazine > Home > Issues > 2007 > June >  Security: Managing Hardware Restrictions via Gr...
Security
Managing Hardware Restrictions via Group Policy
Jeremy Moskowitz
 
At a Glance:
  • Restricting hardware installations
  • Restricting specific devices
  • Restricting classes of devices

You know it’s true: those USB thumb-disk keys and removable media doo-dads make your personal life easier, but your professional life harder. You want a way to control which
hardware devices can be installed and which can’t. Fortunately, with Group Policy in Windows Vista™ and the next version of Windows Server®, code-named "Longhorn," you have the option to allow USB mice but disallow USB disk-on-keys, permit CD-ROM readers, but not DVD-writers, or allow Bluetooth but not PCMCIA.
Two sections in Group Policy can help you secure your hardware: Computer Configuration | Administrative Templates | System | Removable Storage Access (see Figure 1), and Computer Configuration | Administrative Templates | System | Device Installation | Device Installation Restriction (see Figure 2).
Figure 1 Predefined hardware restrictions in Group Policy (Click the image for a larger view)
Figure 2 Customize the kinds of hardware you want to restrict (Click the image for a larger view)
The first set (Removable Storage Access) is fairly self-explanatory: if you enable a policy setting for that kind of removable storage (CD/DVD, floppy disk, and so on), then you can restrict reading and/or writing to that whole device type, if desired. But it doesn’t quite have the superpowers Device Installation Restrictions has.
In Removable Storage Access, there are policy setting groups named Custom Classes: Deny read access and Custom Classes: Deny write access. This sounds good, but the Removable Storage Access policy doesn’t actually prevent the drivers from being installed—the driver for the class is already installed when the hardware is detected. What the policy does is prevent the device from being read or written to. In the next section, when I explore the Device Installation Restrictions policy settings, I’ll lock down the use of the whole driver itself.

Getting a Handle on Classes and IDs
First things first: you need to know what you want to restrict. You can think big or you can think small. That is, you can restrict a specific "class" of devices or get super-specific and restrict a single hardware type. Or you can do the converse and allow only specific device classes, like USB mice. Here’s the trick, though: to really be effective you’re going to need to track down the hardware you want to restrict.
So, if you want to say "No joystick drivers can be installed" and "Only USB mice can be installed," you need to get hold of a joystick and a USB mouse. The alternative is to use the Internet to track down either the Hardware ID, Compatible ID, or Device Class. However, it’s much easier if you have one of the actual devices in front of you. That way, you can introduce it to your machine and see for yourself what the Hardware ID, Compatible ID, or Device Class is. Once you know that, you’ll know exactly how to squash it (or leave it available).
In the following example, I’ll squash a specific sound card family: a Creative AutoPCI ES1371/ES1373. If you want to squash something else (like specific USB devices, USB ports, and so on), just follow along and substitute the device you want.
Fire up Device Manager on a machine that already has the hardware items installed. When you find the device, right-click it and select Properties, then the Details tab. By default you’ll see a "Device description." While interesting, it’s not that useful. Select the Property dropdown and choose "Hardware Ids" as in Figure 3.
Figure 3 The Details tab of the device (Click the image for a larger view)
The Hardware Ids page shows you from top to bottom the most-specific to least-specific device ID. If you look closely at the topmost item in the Hardware Ids value list, you’ll see this sound card is specifically a Rev 2 of the ES1371 sound board. That’s pretty darned specific. As you go down the list, the description becomes less specific to encompass the whole family.
Moreover, you can change the Property to Compatible Ids. These also describe the hardware and are considered less specific than what you find in Hardware Ids. You might choose to use the information in Compatible Ids to try to corral more hardware that’s similar into your don’t-use list—because it’s less specific and might actually net more results. Of course, the tradeoff is that you might restrict something you didn’t want to restrict.
And, finally, the least-specific category can be found by selecting Device Class from the Property dropdown. In my case, the sound card shows up as simply Media. But a number of items can be considered Media, so again, the less specific you go the more cautious you should be.
Once you’ve decided which value to use, right-click it, select Copy, and paste it into Notepad for safekeeping. Copying it directly as it’s presented is important because in the next steps, the value must be entered exactly. All uppercase and lowercase characters in the value must be transferred precisely.
If you want to be a command-line commando instead of using Device Manager to capture the Hardware Ids or Device Classes, check out the Devcon command-line utility at support.microsoft.com/kb/311272. And note that Microsoft has a number of identifiers for common classes that may be helpful if you don’t have physical access to the device; see the information at go.microsoft.com/fwlink/?LinkId=52665.

Hardware Access Control via Group Policy
While we’ll explore all the policy settings located in Computer Configuration | Administrative Templates | System | Device Installation | Device Installation Restriction (shown in Figure 2), there is really only one we’ll need to complete this initial example.
First create a Group Policy Object (GPO) and link it to an OU (or domain, and so on) that contains the machines running Windows Vista that you want to control. Now edit the GPO and drill down into Computer Configuration |Administrative Templates | System | Device Installation | Device Installation Restriction | Prevent installation of devices that match any of these device IDs. Select Enabled in the policy setting, click Show (also in the policy setting), and select Add in the "Show Contents" dialog. Then in the "Add Item" dialog box, paste in the device information you saved before, as shown in Figure 4.
Figure 4 Paste the device ID to capture the description exactly (Click the image for a larger view)
Now here’s the catch. If a machine already has the device installed, it doesn’t magically uninstall and restrict access to it. So, if you’re going to restrict hardware, you’ll want to do this early in your Windows Vista deployment. However, it should be noted that Windows Vista will recheck whenever a device is then removed and reinstalled. Items like USB thumb drives (which get removed and reinserted later) thus are excellent candidates for this process. Since Windows Vista only rechecks when the device is reintroduced, the device is restricted at that time (even if the device driver was initially loaded on the machine). The more difficult problem concerns devices that ship with a machine and don’t get removed and reintroduced. And for those devices, there’s no immediately obvious solution.
When you turn on a machine that has never seen the hardware device before, Windows will try to install the driver, providing status information as it progresses. If you’ve set up a policy restricting such devices, you’ll see a result as in Figure 5.
Figure 5 A device installation being prevented  (Click the image for a larger view)

More Hardware Restrictions
In the example above, we squashed just one device. If you wanted to, you could go the opposite route, restricting all hardware by default and then allowing some. Again, you can see a list of these policy settings in Figure 2, which shows the Computer Configuration | Administrative Templates | Device Installation | Device Installation Restrictions branch of Group Policy. You can choose from several available settings.
First, there’s "Allow administrators to override Device Installation Restrictions." By default, local administrators on Windows Vista must honor the restrictions that are put in place. If you enable this setting, local administrators can override the restriction and install whatever hardware they want.
Next is "Allow installation of devices using drivers that match these setup classes." By entering device descriptions in this policy setting, you’re expressly allowing those hardware devices to be installed on the system. Note that this policy setting honors only setup classes, not device IDs (like those used in the example).
To achieve the opposite effect, you can set "Prevent installation of devices using drivers that match these device setup classes."
The two settings "Display a custom message when installation is prevented by policy (balloon text) and (balloon title)" help you customize the message, as in Figure 5.
As mentioned earlier, the least-specific way to describe hardware is based on hardware class. It should be noted that the policy setting "Allow installation of devices that match any of these device IDs" does not honor Class ID descriptions. To use Class ID descriptions, use either "Allow installation of devices using drivers that match these device setup classes" or "Prevent installation of devices using drivers that match these device setup classes." This latter policy is best used with the setting "Prevent installation of devices not described by other policy settings." By preventing everything (by default) and then using this setting you can specify precisely which devices you want to allow.
In the example, I used the policy "Prevent installation of devices that match any of these device IDs" to restrict a specific type of hardware based on device IDs. If you wanted to implement restrictions using Device Classes, you would have to leverage other specific policy settings such as "Allow installation of devices using drivers that match these device setup classes" or "Prevent installation of devices using drivers that match these device setup classes."
"Prevent installation of removable devices" is a quick, generic way to restrict any hardware device that describes itself as removable, including USB devices. This setting is rather general, so it’s best not to use it too often. Instead, use the techniques described earlier to get moderately restrictive Device IDs and lock them down specifically.
Finally, "Prevent installation of devices not described by other policy settings" is the catchall policy setting that basically restricts all hardware unless you’ve specifically dictated that something can install. This policy in conjunction with the various "Allow" policies (such as "Allow installation of devices that match any of these device IDs") makes a really powerful tool for allowing only the hardware you want in your environment.

Conclusion
Group Policy in Windows Vista has a number of new superpowers, which are extremely useful for allowing only the hardware you want in your environment. Just implement your policy settings early in your deployment, so the hardware you don’t want on your network never finds a way to connect.
Interview with Michael Dennis, Lead Program Manager for Group Policy at Microsoft
I recently had the opportunity to interview Michael Dennis, who has steered the Group Policy ship at Microsoft since its inception. Michael is leaving the Group Policy team to pursue other opportunities within Microsoft. I sat down with Michael to reflect on the last nine years of Group Policy, where it’s been, and where it’s going.

Jeremy Moskowitz Michael, I think lots of people would like to know what you consider your best achievements during your time running the Group Policy team at Microsoft.

Michael Dennis The biggest achievements go back some time, when we focused on developing what was to be known as Group Policy. We already had System Policy in Win­dows NT® 4.0, so we looked at that and its problems. Since this was during the period of Active Directory® development, we looked at where we needed to better address the manageability of clients and servers.
The idea that Group Policy was to be built in a hierarchy and that this idea had never been done before was a big deal to us. So, we concentrated on core infrastructure, client processes, and integration with Active Directory.
The byproduct of our best achievement was also our worst achievement. That’s because the GUI that we shipped in Windows 2000 was problematic. People needed a PhD in Group Policy to use it effectively because administrators needed to know how the whole thing worked. I wish we could have created the Group Policy Management Console (GPMC) and Resultant Set of Policy (RSoP) and delivered it back then (it was in the specs).

JM What items do you wish could have been included in the Group Policy experience?

MD The good news is that the things I’ve wanted since the Windows 2000 release are here now in Windows Vista—things like RSoP, the GPMC, the increased settings, and so on. I wish we could have done those things a whole lot sooner.
Additionally, I wish that the Group Policy infrastructure could be more easily extended by partners. Our server-side/client-side extension model requires a good deal of work by developers. However, it could be argued that our ADM/ADMX template structure does provide an easily extensible framework. But, it would be even better if that part of the system enabled people to extend more types of settings.
I also wish that the GPMC reporting was more extensible for partners and third-party tool developers. It’s an area in which third-party tool vendors have been pretty vocal.

JM What are some things people don’t know about the Group Policy team?

MD Sometimes it’s not clear to people where the Group Policy team fits into the overall picture. The idea is that we build the infrastructure, the transport, and the server and client-side pieces. But in Windows Vista alone we partnered with about 120 different teams at Microsoft to get the new settings in place for this release.
Readers should note that Group Policy is not to blame for system slowdown issues at boot or logon. It’s the Group Policy payload that’s to blame if things are slow. If you tell Group Policy to do something that’s heavyweight, it’s going to just do it. For instance, if you tell it to install Microsoft Office on a per-machine basis, great. But just know that it will do what you asked for; it will install all of Office before you get a logon prompt. Is that a slowdown? You betcha, but as an admin that deployed it, it’s exactly what you wanted the system to do.

JM What’s your favorite thing to show off using Group Policy?

MD These days, I like to show off some of the new settings that made it into Windows Vista. The removable devices settings (to restrict things like USB sticks, and so forth) are settings people had been clamoring for. There are about 2,400 settings available in Windows Vista, which brings a significant level of control to admins. I like asking customers what they want to control and then showing them how to do it.

JM Why did you change from ADM to ADMX files?

MD Technically, we didn’t need to do that to get to the new central store feature in Windows Vista. The big push for converting to ADMX was to allow us to support multiple languages appropriately.
Previously, in multilanguage environments you would often run into a situation in which the contents of the ADM files inside a GPO would be inadvertently written by another language. Historically, we borrowed the ADM format from Windows NT 4.0, which had borrowed it from Windows 98, which had borrowed it from Windows 95. If XML had been around then, it would have been a good candidate for our file format.
But, now that we have XML, it has become easier to support multiple languages, and it presents future opportunities to make registry and settings enhancements with our now schematized language.

JM What was the biggest internal challenge you had to overcome while working on the GP team?

MD The biggest ongoing problem the team faces is trying to get other components of Windows to policy-enable their features.
Team X might respond "We just built this great new feature. Why would anyone want to turn it off?" And we can understand that. But we worked through a lot of those issues.
There are also technical challenges regarding enabling some things by policy, for instance, the new Windows Firewall with Advanced Security (WFAS). WFAS was tough to do. It’s not easy or straightforward to policy-enable it correctly. The interface that the WFAS team created for Windows Vista is superb, but doing it right has been tough.
In versions of Windows before Windows Vista, the product teams themselves didn’t always think about policy-enabling their components. But, during Windows Vista development, a fair number of teams asked us how to do it. That was huge!
JM What’s next for you?

MD I’m moving to the "Mobile Information Worker" team, which is responsible for Smart Phones, Pocket PCs, and so on. My role will be to extend some of the management technologies in Windows Server System to Windows Mobile® devices.
I will try to take my same vision and passion for manageability and apply it in this new space. Meanwhile, I’m leaving the Group Policy team in an outstanding position to move things forward without me.

JM Anything else you’d like to tell our readers?

MD All through the development of Group Policy, one important step was to get in front of customers and really understand what they’re trying to do. If customers have a well-structured opinion about scenarios they would like to see Group Policy cover and they have a business case for doing something, they need to communicate that back to us.
We have a good feedback mechanism that’s available to everyone at WindowsServerFeedback.com. Look for the Group Policy button.
If your folks can say "here’s my problem, here’s my business case, and I need the system to be able to do this and here’s why" that kind of information is very, very valuable to us. Those who make decisions about Group Policy going forward read every entry that comes through that source.
Again, if you want to have an impact in Group Policy moving forward, tell us about what you need. But please don’t just tell us "We need a policy setting that does X" without telling us why. The "how" is our job to figure out. What the Group Policy team really needs to know is the "why."
JM Thanks for taking the time to tell us about your experiences on the Group Policy team at Microsoft. All the best!
MD Thank you, Jeremy.


Jeremy Moskowitz, MCSE and MVP in Group Policy, runs GPanswers.com, a community forum on Group Policy. He runs a series of Group Policy intensive training workshops. His latest book is Group Policy: Management, Troubleshooting and Security (Sybex, 2007). Contact Jeremy at www.GPanswers.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Page view tracker