Device Control preventing function of a hardware encrypted flash drive that is on the trusted device list.

[GS23]

We are using KES 11.0.1.90 with KSC 10 and the Device Control functions to disable optical disc drives. In the past some USB devices create a virtual CD-ROM device to serve installers and drivers and adding them to the trusted devices list has always allowed them full function. This also lets us allow specific people access to specific devices without issue. One of our departments wants to use a few hardware encrypted flash drives, Kingston IronKey D300 specifically, to transfer some internal data. This device mounts a small virtual CD-ROM and a flash drive as two separate drive letters. The unlocking software is contained on this small virtual disc, and without running it, the drive is unusable. Adding the device to the trusted devices list allows the virtual CD-ROM device to mount and even allows me to browse its files, but when I run the unlock software, the splash screen shows then the program silently closes. Running this unlock program on a computer with optical drives unrestricted allows full normal operation, and allowing all optical drives on the initial computer also allows it to run without issue. While the virtual CD-ROM is trusted but not working, the autorun.ini file does not process properly, as the drive letter icon remains default. While functioning properly it shows a custom drive icon applied by the autorun.inf. I can't see any other devices added outside of the virtual CD and base storage device, and I haven't been able to find anything in the system logs nor in the KSC Event logs being blocked when it fails. Am I missing something, or is this a compatibility issue with the KES device control driver?

[Nikolay Arinchev]

Hi, Have you tried to add a decrypting software to KES trusted zone? Please attach an export of KES active policy to your answer as well.

[GS23]

Hello, and thanks for the quick response. Yes, I have tried adding the decrypting software to the trusted zone as "**\IronKey.exe" and also added other programs based on this list. I stopped pursuing the application route at this point after I found that disabling device control for CD-DVD drives was the only difference between it working or not. Here are links to our Global Policy and the Policy Profile in use for these PCs and users just in case the profile isn't part of the main export. I have confirmed that the PCs are using the profile through local event logs.

[Nikolay Arinchev]

Could you please collect KES traces while the issue reoccurs? Please use any file sharing resource to upload traces and provide us with a link.

[GS23]

Here is the trace data for the test computer. During trace collection I connected the flash drive and attempted to run the unlock software, only to have it close. Same behavior as before. I then removed the flash drive and turned off tracing. I placed a simple password on this zip archive. The password is "trace" I will be unavailable for the next two weeks, so take your time. Thanks.

[Nikolay Arinchev]

Hi, Thank you for that info! Could you please provide us with an export of active KES policy that is applied to the group of hosts that should use Kingston IronKey D300?

[GS23]

The export of the policy profile for these hosts is available at this link.

[GS23]

If there is something I missed adding to the trusted zone that was revealed in the trace logs I feel it would have been helpful to tell me about it, rather than marking the issue as resolved when it is not.

[GS23]

I found the answer on my own. Our policy was granting access to only the user account of the user we specifically granted access to, but the software was running under local service and system accounts so they were being blocked by device control. Once I granted trusted device access to the "NT AUTHORITY\LOCAL SERVICE" and NT AUTHORITY\SYSTEM" accounts in addition to the security group, the specified users could access the drive on the computers which had this policy profile active.