none
Device Installation Restriction policy not working as expected

    Question

  • We are currently using Symantec Endpoint Protection's Device Control Policies to block use of unapproved USB devices on our computers.  We'll be switching to a different antivirus program soon, so I need to replace the device control functionality. 
    I've begun testing the Device Installation Restrictions group policy settings, but it's not working quite as well as I'd hoped.  The goal is to block all USB devices except those that are whitelisted by hardware ID or device setup class.  I've enabled the settings for:
    • Allow administrators to override Device Installation Restriction policies
    • Allow installation of devices using drivers that match these device setup classes
    • Allow installation of devices that match any of these device IDs
    • Prevent installation of devices not described by other policy settings

    The 2 'allow installation' settings are configured with a list of hardware ID's and device setup classes which should be allowed.  In testing, I found that the policies are blocking installation of all devices, including those which I believe should be allowed.  

    Some devices I expect to be allowed because they should fall under a whitelisted device setup class.  For example, I added device setup class {745a17a0-74d3-11d0-b6fe-00a0c90f57da} (HID Devices) and {4d36e96b-e325-11ce-bfc1-08002be10318} (Keyboards) to the allow list, but when I plug in a USB keyboard, installation is blocked.  I have to allow that specific keyboard's hardware ID in order for it to get past the initial detection of the device.  Once I've done that, the keyboard is detected and installed. Clearly though, it doesn't make sense to enter the hardware ID of every make/model of USB keyboard into the list unless you have a very homogeneous environment.  

    If a device is whitelisted by hardware ID, the initial detection of that device and hardware ID will be allowed, but then another device appears in device manager with a different hardware ID (obviously the same hardware, but detected a bit differently) and that device gets blocked.  If I add that new hardware ID to the whitelist, then another new device appears and is blocked... In some cases I got about 4-5 layers deep before the device was fully installed and available for use.  It doesn't seem like I should have to individually allow the hardware ID's listed at each subsequent level of device detection.  Still, while that would be a big pain, it is possible.  My bigger concern here is that the later devices detected & whitelisted were using very generic hardware ID's, and that by whitelisting those generic ID's I might end up allowing other devices which do not have the same hardware ID, but do fit the same generic hardware ID.  

    Is anyone using these Device Installation Restriction policies in their environment?  If so, did you run into these issues?  How did you deal with them? 




    • Edited by NeighborGeek Thursday, February 23, 2017 3:58 PM
    Thursday, February 23, 2017 3:56 PM

Answers

  • I did eventually get this working well enough to move forward at least.  The info in the <windir>\inf\setupapi.dev.log file did end up being helpful.  Looking at the log entries I quoted above, as it is detecting and attempting to install the driver for each device, there is a line in the log which says "Class GUID of device changed to:" followed by a GUID. In each case, the GUID listed does not match the device setup GUID I had whitelisted for that type of device.  

    For example, I whitelisted the guid {4d36e96b-e325-11ce-bfc1-08002be10318} for Keyboards, but when I plugged in a USB keyboard the log showed "Class GUID of device changed to: {36fc9e60-c465-11cf-8056-444553540000}."  Searching for this guid, I found that it is the device setup GUID for USB host controllers and Hubs.  It seems that the USB Keyboard first had to have a driver installed for a USB Composite device before it could be identified and installed as a keyboard.  Adding the class {36fc9e60-c465-11cf-8056-444553540000} to my whitelist allowed the keyboard to be detected and installed successfully.  

    The other device in my log entries above was a Printer (actually, the Send to Onenote print queue installed as a part of MS Office.)  I had whitelisted the setup GUID for printers, but at the most basic level the print queue was detected and first had to be installed as a "LocalPrintQueue".  The device setup class guid for this was {1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}. Adding this GUID to my whitelist allowed print queues to be added without issue.  

    TL,DR; The specific device setup class GUID you would expect a device to fall under may not be the only GUID it is installed as during setup.  The file "%windir%\inf\setupapi.dev.log" will include a line reading "Class GUID of device changed to:", which lists the device setup class GUID needed to install the device at the lowest level.  By whitelisting that GUID (Or the lowest level Hardware ID that the device was detected as), this will allow the device to install the initial low level driver it needs and continue on with detecting and installing additional/more specific drivers.  


    • Edited by NeighborGeek Tuesday, April 04, 2017 2:34 PM
    • Marked as answer by NeighborGeek Tuesday, April 04, 2017 2:34 PM
    Tuesday, April 04, 2017 2:34 PM

All replies

  • Hi,
    Have you tried to not configure Allow installation of devices that match any of these device IDs policy?
    As far as I know, Hardware IDs are the identifiers that provide the most exact match between a device and a driver package. Device setup classes are another type of identification string. The manufacturer assigns the device setup class to a device in the device driver package. The device setup class groups devices that are installed and configured in the same way. For example, all CD drives belong to the CDROM device setup class, and they use the same co-installer when installed. Please see: https://msdn.microsoft.com/en-us/library/bb530324.aspx
    So we could test with only using Device setup classes in the allow rules and see if it helps.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, February 24, 2017 3:04 AM
    Moderator
  • Sure, I can disable the 'allow installation of devices that match any of these device IDs' policy..  That won't work for long term, but I'm certainly willing to test it.  

    The end goal is to always allow keyboards, mice, printers, etc, while blocking most other devices.  In particular, we want to block all removable storage EXCEPT for a specific model of usb flash drive that we issue.  That's where the need comes in to also allow specific hardware IDs. 

    For the record, the device setup classes I've added to the allow policy are:

    HID (Human interface devices) {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
    Printing Devices {4d36e979-e325-11ce-bfc1-08002be10318}
    Imaging Devices {6bdd1fc6-810f-11d0-bec7-08002be2092f}
    Ports {4d36e978-e325-11ce-bfc1-08002be10318}
    Sensors {5175d334-c371-4806-b3ba-71fd53c9258d}
    Biometric {53d29ef7-377c-4d14-864b-eb3a85769359}
    Keyboards {4d36e96b-e325-11ce-bfc1-08002be10318}
    Mouse {4d36e96f-e325-11ce-bfc1-08002be10318}

    In the policy itself, I entered only the GUID for each of those, I added the bolded text before each one in this post just to reference what each GUID is supposed to represent.   

    Friday, February 24, 2017 1:46 PM
  • Hi,

    I am checking how the issue going, is it working by only using Device setup classes in the allow rules?

    And if the replies as above are helpful, we would appreciate you to mark them as answers, and if you resolve it using your own solution, please share your experience and solution here. It will be greatly helpful to others who have the same question.

    Appreciate for your feedback.

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, February 27, 2017 10:03 AM
    Moderator
  • I made the policy change on Friday but just got the chance to test it this morning.  When I plug in a USB keyboard, it is still being blocked from installing.  
    Monday, February 27, 2017 3:43 PM
  • Hi,

    Please make sure that the change of GPO is applied to clients, you could run gpresult /h command to view the detail group policy settings.

    In addition, here is a thread which discussed a similar problem, you could also refer to:

    Group policy - device installation restrictions do not match hardware IDs

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/87d1902e-5194-45c6-a19e-a778b527edc8/group-policy-device-installation-restrictions-do-not-match-hardware-ids?forum=itprovistasecurity

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, March 02, 2017 2:14 AM
    Moderator
  • Thanks.  I have confirmed that the specific group policy settings are applied.  I also checked the setupapi.dev.log mentioned in the other thread.  I'll include a sample of that log at the end of this post.

    For reference, I have the policy set to allow by device setup class, and the two classes listed below are both allowed: 

    {4d36e979-e325-11ce-bfc1-08002be10318}
    {4d36e96b-e325-11ce-bfc1-08002be10318}

    Those should be the classes for Printers and Keyboards, if I'm not mistaken.   Yet the last 2 entries in the referenced log file clearly show the installation of a keyboard and a printer being blocked.  In this case, the printer was a Print to Onenote virtual print queue, so that might be an unusual case, but the keyboard was certainly nothing special.  Based on these logs, why are the devices not being allowed as expected?

    >>>  [Device Install (Hardware initiated) - USB\VID_0461&PID_4E04\5&3320ddb7&0&3]
    >>>  Section start 2017/03/01 07:07:18.027
         dvi: {Build Driver List} 07:07:18.027
         dvi:      Searching for hardware ID(s):
         dvi:           usb\vid_0461&pid_4e04&rev_0104
         dvi:           usb\vid_0461&pid_4e04
         dvi:      Searching for compatible ID(s):
         dvi:           usb\devclass_00&subclass_00&prot_00
         dvi:           usb\devclass_00&subclass_00
         dvi:           usb\devclass_00
         dvi:           usb\composite
         dvi:      Created Driver Node:
         dvi:           HardwareID   - USB\COMPOSITE
         dvi:           InfName      - C:\WINDOWS\System32\DriverStore\FileRepository\usb.inf_amd64_20f76ee4fbfc4cb8\usb.inf
         dvi:           DevDesc      - USB Composite Device
         dvi:           Section      - Composite.Dev.NT
         dvi:           Rank         - 0x00ff2003
         dvi:           Signer Score - INBOX
         dvi:           DrvDate      - 06/21/2006
         dvi:           Version      - 10.0.14393.0
         dvi: {Build Driver List - exit(0x00000000)} 07:07:18.105
         dvi: {DIF_SELECTBESTCOMPATDRV} 07:07:18.105
         dvi:      Default installer: Enter 07:07:18.105
         dvi:           {Select Best Driver}
         dvi:                Class GUID of device changed to: {36fc9e60-c465-11cf-8056-444553540000}.
         dvi:                Selected:
         dvi:                     Description - [USB Composite Device]
         dvi:                     InfFile     - [c:\windows\system32\driverstore\filerepository\usb.inf_amd64_20f76ee4fbfc4cb8\usb.inf]
         dvi:                     Section     - [Composite.Dev]
         dvi:           {Select Best Driver - exit(0x00000000)}
         dvi:      Default installer: Exit
         dvi: {DIF_SELECTBESTCOMPATDRV - exit(0x00000000)} 07:07:18.120
         ndv: {Core Device Install} 07:07:18.120
         ndv:      {Install Device - USB\VID_0461&PID_4E04\5&3320DDB7&0&3} 07:07:18.120
         ndv:           Parent device: USB\ROOT_HUB30\4&27ea22a9&0&0
    !!!  pol:           The device is explicitly restricted by the following policy settings:
    !!!  pol:           [-] Restricted installation of devices not described by policy
    !!!  pol:      {Device installation policy check [USB\VID_0461&PID_4E04\5&3320DDB7&0&3] exit(0xe0000248)}
    !!!  ndv:      Installation of device is blocked by policy!
    !    ndv:      Queueing up error report since device installation failed...
         ndv: {Install Device - exit(0xe0000248)} 07:07:18.183
         ndv: {Core Device Install - exit(0xe0000248)} 07:07:18.183
    <<<  Section end 2017/03/01 07:07:18.230
    <<<  [Exit status: FAILURE(0xe0000248)]
    >>>  [Setup Import Driver Package - C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesX64\Microsoft Office\Office16\OneNote\\prnms006.inf]
    >>>  Section start 2017/03/03 15:10:58.763
          cmd: integrator.exe /I /Extension /Msi PackageGUID="9AC08E99-230B-47e8-9721-4577B7F124EA" PackageRoot="C:\Program Files (x86)\Microsoft Office\root"
         sto: Driver package already imported as 'oem20.inf'.
    <<<  Section end 2017/03/03 15:10:58.778
    <<<  [Exit status: SUCCESS]
    >>>  [Delete Device - SWD\PRINTENUM\{D00E65A4-6138-449C-B3E8-5C48A528394C}]
    >>>  Section start 2017/03/03 15:10:58.888
          cmd: C:\WINDOWS\System32\spoolsv.exe
    !    dvi: Access denied from Query and Remove
    <<<  Section end 2017/03/03 15:10:58.904
    <<<  [Exit status: SUCCESS]
    >>>  [Device Install (Hardware initiated) - SWD\PRINTENUM\{BB9A40BC-D931-4711-8CE5-A9ABBDF235CC}]
    >>>  Section start 2017/03/03 15:10:59.076
         dvi: {Build Driver List} 15:10:59.107
         dvi:      Searching for hardware ID(s):
         dvi:           printenum\{3ee39114-30b4-45a4-a109-19d4a40fcc22}
         dvi:           printenum\localprintqueue
         dvi:           {3ee39114-30b4-45a4-a109-19d4a40fcc22}
         dvi:      Searching for compatible ID(s):
         dvi:           genprintqueue
         dvi:           swd\genericraw
         dvi:           swd\generic
         dvi:      Created Driver Node:
         dvi:           HardwareID   - {3EE39114-30B4-45a4-A109-19D4A40FCC22}
         dvi:           InfName      - C:\WINDOWS\System32\DriverStore\FileRepository\prnms006.inf_amd64_2f92130612032712\prnms006.inf
         dvi:           DevDesc      - Send to Microsoft OneNote 16 Driver
         dvi:           Section      - OneNotePrintDriver_Install
         dvi:           Rank         - 0x00ff0002
         dvi:           Signer Score - WHQL
         dvi:           DrvDate      - 04/29/2013
         dvi:           Version      - 16.0.1626.4000
         dvi:      Created Driver Node:
         dvi:           HardwareID   - SWD\GenericRaw
         dvi:           InfName      - C:\WINDOWS\System32\DriverStore\FileRepository\c_swdevice.inf_amd64_fe491977357f8d3e\c_swdevice.inf
         dvi:           DevDesc      - Generic software device
         dvi:           Section      - SoftwareDevice
         dvi:           Rank         - 0x00ff3001
         dvi:           Signer Score - INBOX
         dvi:           DrvDate      - 06/21/2006
         dvi:           Version      - 10.0.14393.0
         dvi:      Created Driver Node:
         dvi:           HardwareID   - PRINTENUM\LocalPrintQueue
         dvi:           InfName      - C:\WINDOWS\System32\DriverStore\FileRepository\printqueue.inf_amd64_293dcb0d10d72f40\printqueue.inf
         dvi:           DevDesc      - Local Print Queue
         dvi:           Section      - NO_DRV_LOCAL
         dvi:           Rank         - 0x00000001
         dvi:           Signer Score - INBOX
         dvi:           DrvDate      - 06/21/2006
         dvi:           Version      - 10.0.14393.0
         dvi: {Build Driver List - exit(0x00000000)} 15:10:59.139
         dvi: {DIF_SELECTBESTCOMPATDRV} 15:10:59.139
         dvi:      Using exported function 'ClassInstall32' in module 'C:\WINDOWS\system32\ntprint.dll'.
         dvi:      Class installer == ntprint.dll,ClassInstall32
         dvi:      Class installer: Enter 15:10:59.160
         dvi:      Class installer: Exit
         dvi:      Default installer: Enter 15:10:59.162
         dvi:           {Select Best Driver}
         dvi:                Class GUID of device changed to: {1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}.
         dvi:                {DIF_DESTROYPRIVATEDATA} 15:10:59.164
         dvi:                     Class installer: Enter 15:10:59.165
         dvi:                     Class installer: Exit
         dvi:                     Default installer: Enter 15:10:59.165
         dvi:                     Default installer: Exit
         dvi:                {DIF_DESTROYPRIVATEDATA - exit(0xe000020e)} 15:10:59.165
         dvi:                Selected:
         dvi:                     Description - [Local Print Queue]
         dvi:                     InfFile     - [c:\windows\system32\driverstore\filerepository\printqueue.inf_amd64_293dcb0d10d72f40\printqueue.inf]
         dvi:                     Section     - [NO_DRV_LOCAL]
         dvi:                Basic Driver Skipped:
         dvi:                     Description - 'Send to Microsoft OneNote 16 Driver'
         dvi:                     InfFile     - C:\WINDOWS\INF\oem20.inf
         dvi:                     Section     - [OneNotePrintDriver_Install]
         dvi:           {Select Best Driver - exit(0x00000000)}
         dvi:      Default installer: Exit
         dvi: {DIF_SELECTBESTCOMPATDRV - exit(0x00000000)} 15:10:59.165
         ndv: {Core Device Install} 15:10:59.165
         ndv:      {Install Device - SWD\PRINTENUM\{BB9A40BC-D931-4711-8CE5-A9ABBDF235CC}} 15:10:59.165
         ndv:           Parent device: SWD\PRINTENUM\PrintQueues
    !!!  pol:           The device is explicitly restricted by the following policy settings:
    !!!  pol:           [-] Restricted installation of devices not described by policy
    !!!  pol:      {Device installation policy check [SWD\PRINTENUM\{BB9A40BC-D931-4711-8CE5-A9ABBDF235CC}] exit(0xe0000248)}
    !!!  ndv:      Installation of device is blocked by policy!
    !    ndv:      Queueing up error report since device installation failed...
         ndv: {Install Device - exit(0xe0000248)} 15:10:59.259
         ndv: {Core Device Install - exit(0xe0000248)} 15:10:59.259
    <<<  Section end 2017/03/03 15:10:59.306
    <<<  [Exit status: FAILURE(0xe0000248)]
    

    Tuesday, March 07, 2017 4:28 PM
  • Hi,

    Appreciate for your test and feedback, as the limitation in the forum for to analysis the log, I would suggest you open up a case with Microsoft Technical Support to see if they could get other ideas from product team about the problem: https://support.microsoft.com/en-us/contactus/?ws=support

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, March 10, 2017 1:39 AM
    Moderator
  • I did eventually get this working well enough to move forward at least.  The info in the <windir>\inf\setupapi.dev.log file did end up being helpful.  Looking at the log entries I quoted above, as it is detecting and attempting to install the driver for each device, there is a line in the log which says "Class GUID of device changed to:" followed by a GUID. In each case, the GUID listed does not match the device setup GUID I had whitelisted for that type of device.  

    For example, I whitelisted the guid {4d36e96b-e325-11ce-bfc1-08002be10318} for Keyboards, but when I plugged in a USB keyboard the log showed "Class GUID of device changed to: {36fc9e60-c465-11cf-8056-444553540000}."  Searching for this guid, I found that it is the device setup GUID for USB host controllers and Hubs.  It seems that the USB Keyboard first had to have a driver installed for a USB Composite device before it could be identified and installed as a keyboard.  Adding the class {36fc9e60-c465-11cf-8056-444553540000} to my whitelist allowed the keyboard to be detected and installed successfully.  

    The other device in my log entries above was a Printer (actually, the Send to Onenote print queue installed as a part of MS Office.)  I had whitelisted the setup GUID for printers, but at the most basic level the print queue was detected and first had to be installed as a "LocalPrintQueue".  The device setup class guid for this was {1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}. Adding this GUID to my whitelist allowed print queues to be added without issue.  

    TL,DR; The specific device setup class GUID you would expect a device to fall under may not be the only GUID it is installed as during setup.  The file "%windir%\inf\setupapi.dev.log" will include a line reading "Class GUID of device changed to:", which lists the device setup class GUID needed to install the device at the lowest level.  By whitelisting that GUID (Or the lowest level Hardware ID that the device was detected as), this will allow the device to install the initial low level driver it needs and continue on with detecting and installing additional/more specific drivers.  


    • Edited by NeighborGeek Tuesday, April 04, 2017 2:34 PM
    • Marked as answer by NeighborGeek Tuesday, April 04, 2017 2:34 PM
    Tuesday, April 04, 2017 2:34 PM
  • Awesome, NeighbourGeek. Did you happen to confirm if it needed the original GUID in the whitelist as well?

    Our users take laptops to client sites and need to install printers. I'm trying to allow this without giving them admin rights. I have no control over what printer model it is and I don't get to see/test it first. If I could just allow them to install PrintQueue devices, by using that GUID, and have that cover any printer that would be perfect.

    Tuesday, May 02, 2017 10:31 PM