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
.
Good stuff. This a use case of item-level targeting that I hadn't considered before. This will be going into my Group Policy tool kit.
Thanks for posting!
Hi John,
When you say "Group Policy Preferences settings under User Configuration, which have the ability of setting registry values under both HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE", is there a reliance on the logging on user account have local administrative rights to perform a right under HKLM or does GPP circumvent that somehow?
Thanks,
Mark.
In MBAM 2.5 setup – We want the users to decide if they want to encrypt the Removable Drive OR not, but also want to make sure that when they insert the USB, they get a choice(prompt) to encrypt the Removable drive. If user chooses not to encrypt, they
should still be able to write to the removable drive. How can we accomplish that? I tried your approach of preference setting the registry value selectively (all "domain users" get RDVAllowBDE=1 and RDVDenyWriteAccess=0). Thanks in advance
A perfect example of how powerfull are GPP 🙂
Thank you for sharing it.
Rafa, Thank you!
Couldn't agree more! GPP has allowed me to come up with many creative custom solutions/workarounds in a much quicker, easier, and repeatable manner than trying to use custom ADM/ADMX|ADML templates!
Great content!
Thank you for sharing 😉
John, Thanks for the timely article. Would you have the registry setting when MBAM is used. Would it be the same registry settings under "FVEMDOPBitlockerManagement" key? The settings in a MBAM The MBAM setting "Allow the user to be exempted" doesn't seem to work.
Hi Mano, sorry for not replying sooner, I had to do some digging around to understand how MBAM's user exemptions worked…
Regarding whether or not I would make the registry changes under the MBAM subkey under FVE, the answer is no. Although the BitLocker policies from my blog are recreated under the MBAM-specific folder in the GP Editor UI, under the hood, they still write the registry values to the same non-MBAM specific registry key.
Regarding the MBAM user exemptions not working, what exactly is it that the user is not being exempted from that you expected they would be exempted from?
After discussing this with our MBAM supportability team, what I learned is that MBAM user exemptions only exempt users from having to encrypt Fixed & OS Drives that are otherwise forced to be encrypted via policy. Any other settings, like the ones I use in my blog, would still apply to MBAM exempted users.
There are several local accounts created on my PC. I have set bitlocker to automatically unlock on this computer using an admin account. The problem is that when i log on using a non-admin account, I am prompted to key in the password.
I want the automatic unlocking option to work for all the user accounts on that computer.
Please help me.
@ShaileshShah_Weil
Try setting RDVAllowBDE=0x1, RDVConfigureBDE=0x1, & RDVDenyWriteAccess=0x0…
Note though, that since you are not trying to enforce different Bitlocker requirements on different users, you wouldn’t want to use the approach of setting HKLM registry values via GPP under User Configuration. You should be doing everything under Computer
Configuration (using existing policy settings if they meet your needs, or GPP if you need to set some combination of values not possible with the existing policies).
Also, when testing this, make sure to verify that the registry values are getting set as expected/intended under [HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftFVE].
@ Mark
By default, GPP applies user preferences as SYSTEM, so HKLM permissions are not a concern for this solution:
http://technet.microsoft.com/en-us/library/cc772371.aspx
HTH!
RDVDenyWriteAccess is under HKLMCCSPoliciesMicrosoftFVE not HKLMpolicies with the rest.
Hey John, Just wondering if this should be working for Windows 8.1 also? I’ve a client who wants pretty much exactly what your client wanted in this scenario, but it doesn’t appear to work. The settings are appearing in the expected places, but bitlocker
isn’t prompting me for a decision one way or the other.
Cheers and thanks very much for this post as it shows I’m not alone out here with demanding clients.
Barry