IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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:
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…