Make enforcing BitLocker To Go more practicable

[Ephelyon]

Hi all,

I work at a school and we want to require all staff users (but not the students) to use BitLocker encryption on their USB sticks to guard against the acquisition of sensitive data through theft. The Group Policy setting "Deny write access to removable drives not protected by BitLocker" would have been the perfect solution, had Microsoft in their infinite wisdom not decided to make it a per-computer setting (as opposed to per-user as it really ought to be). Some digging revealed, however, that (like most Group Policy options) it's just a Registry setting - a single value in fact - and that neither a logoff/restart nor even a restart of Explorer is required to allow it to begin functioning immediately.

In light of this very convenient fact, the most obvious solution was to just create a logon script for just the staff users (set at the top of the "Staff" OU tree), but this carried the disadvantage that the local admin credentials would have to be stored in the script as well, as normal users can't write to this Registry location. While it's extremely unlikely that any of my users would be able to find this script on the SysVol share (mainly because they wouldn't even know it was running), the fact still remains that it would be possible to read the file if they did, and this was not acceptable. I therefore decided to use AutoIt to create a compiled/compressed executable for this purpose as the credentials would then be obfuscated (and a startup/logon script doesn't necessarily have to be a batch file). The first draft of the script would set the value when it was executed (i.e. on logon) and then unset it again on logoff by means of the OnAutoItExitRegister() function.

Initial trials were successful, but there were two major obstructions to this approach in terms of actually enforcing this policy effectively (i.e. the point of the whole thing). Firstly, it was very easy to get around it by simply inserting the USB stick prior to logon (as Windows only starts to check new volumes from when the Registry setting has been changed). Secondly, it created a number of problems to do with User Switching. For example, if a staff user logged on and the setting was enforced, then switched to another staff user who then logged off, the setting would no longer be in force for the first user. Similarly, and slightly less importantly from the point of view of data security, if a staff user logged on and then switched to a pupil user, that pupil would be unable to write to their own USB stick.

The script as it is now will: set the value on logon, unset it if the session is switched away from, reset it if the session is switched back to and ultimately unset it at logoff (using a different method). It will also check to see if any removable storage volumes (with media inserted, i.e. not SD card slots or the like, also ignoring the A: drive) are mounted on logon or switchback, and dismount them if so after editing the Registry, before asking the user to re-insert their stick to continue using it for that session.

So far I feel this solution is pretty comprehensive; I've been unable to fool it while fiddling around myself and it's been perfectly stable (at least in its final form). I'm submitting this script firstly to see if it will help anyone else, and secondly to see if anyone can identify any other scenarios I've not thought of from a security point of view. I should also mention that, while I'm very adept at Windows batch scripting, I am emphatically not a programmer in any other sense of the word, and this script, while essentially functional, is therefore probably not that well coded...

After changing the "user1234" and "pass1234" values at the top to match the local admin credentials on your workstations, this script should be ready to roll (unless there's anything else hard-coded that's specific to our setup which I've forgotten about)...

Shouts go out to a couple of people whose various snippets posted around this forum were instrumental in formulating the final solution: specifically, Asdend4nt and Valik.

See what you think!

Ephelyon

RDVDenyWriteAccess.au3