First published on TechNet on Jun 09, 2013
Hi readers, John Sanz here. A customer of mine came to me with a business requirement that couldn’t be satisfied out of the box, so I thought I would share the solution with you.
The business requirement was that they needed to be able to enforce BitLocker encryption on Removable drives by users, instead of by computers. Specifically, they needed to address the following 3 distinct user group scenarios:
1. Subset of Users should only be able to have Read-Only access to removable drives, whether the drive is encrypted or not.
2. Subset of Users should be able to have Read-Only access to removable media that is not encrypted, and Read/Write access to removable drives that are BitLocker encrypted. In addition, if they connect a drive that is not encrypted they should get prompted to encrypt the drive. If they choose to encrypt the drive, they should then have Read/Write access.
3. Subset of Users should be able to have Read/Write access to all removable drives, regardless of encryption.
Out of the box, it is already possible to do this via Group Policy, however only based on Computers (policy settings only exist under Computer Configuration) and the customer needed to do this based on Users… These are the policy settings under Computer Configuration:
To accomplish this, we decided to leverage Group Policy Preferences settings under User Configuration, which have the ability of setting registry values under both HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE. Now, because we are configuring HKLM settings via User preferences, these would normally stick and apply to the next user to log in. To avoid this behavior, for every GPP setting, there has to be an exact inverse (mutually exclusive) targeted item to unset the value in question (as depicted in the Item Level Targeting screenshots below). This way, if users satisfy ‘condition x’ then that means that all other users automatically satisfy ‘condition y’ which unsets the value in question.
Here are the specifics of the groups and preference settings we implemented:
GROUPS:
- BITLOCKER_PROMPT
- BITLOCKER_RESTRICT
GROUP POLICY PREFERENCES:
Note, all of the registry values being configured here are REG_DWORD values under the “[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]”
- RDVAllowBDE - set the value to 1 if user is a member of the BITLOCKER_PROMPT user group
- RDVAllowBDE - set the value to 0 if user is not a member of the BITLOCKER_PROMPT user group
This preference setting has the effect of causing members of the BITLOCKER_PROMPT user group to be prompted to encrypt a removable drive that is not already encrypted. For all users that are not members of the BITLOCKER_PROMPT user group, they will not be prompted to encrypt the dive.
- RDVConfigureBDE - set the value to 0 if the user is not a member of BITLOCKER_RESTRICT
- RDVConfigureBDE - set the value to 1 if the user is a member of BITLOCKER_RESTRICT
- RDVDenyWriteAccess - set the value to 0 if the user is not a member of BITLOCKER_RESTRICT
- RDVDenyWriteAccess - set the value to 1 if the user is a member of BITLOCKER_RESTRICT **(Updated on 8/12/13)
These preference settings have the effect of removing control of removable drive encryption from Bitlocker. This means that users that are not members of BITLOCKER_RESTRICT will be able to Read/Write to all removable drives without getting prompted to encrypt if the drive is unencrypted, whereas users that are members of the BITLOCKER_RESTRICT will get prompted to encrypt removable drives that are not encrypted and will be have Read-Only access to unencrypted drives and Read/Write to encrypted drives.
In case any of you are wondering whether or not this same approach can be utilized for any number of other Computer Configuration policy settings, the answer is yes, but not all of them. Whether or not this approach will work, depends on how and when the affected component/application reads in the settings from the registry. In the case of enforcing Bitlocker Drive Encryption requirements on Removable Drives, those settings are read in each and every time a drive is connected to the system, which is why this approach works.
I hope you found this helpful and informative, and if you have any questions, just ask…
John Sanz