Today I experienced an issue which I want to share on my blog, it is related to a setting related to BitLocker which gets tattooed meaning that it doesn’t get removed from the device if you modify the setting afterwards.
Let me explain the scenario first.
For a customer who is using both the Security Baseline for Windows 10 and later and the Microsoft Defender for Endpoint Baseline with the default settings I received the request to make writing to a removable drive not protected by BitLocker available for a certain group of users within the organization. And what started as a simple task, ended up with some heavy troubleshooting in order to create a solution.
So normally when I want to create exceptions to the Security baselines, I remove the settings defined in the Security Baseline and define a Configuration Profile with the same settings, allowing me to specify a group which gets excluded from these settings. By doing so I can keep the settings in the baseline for the majority of users, while allowing for exceptions.
The Concept
For the setting “Block write access to removable data-drives not protected by BitLocker” I first needed to make modifications in both the Security Baseline for Windows 10 and later and the Microsoft Defender for Endpoint Baseline
For the Security Baseline for Windows 10 and later the following settings were changed
For the Microsoft Defender for Endpoint Baseline the following settings were changed
Once the settings were removed from the baseline, I created a new configuration profile using the settings catalog with the following settings
I then assigned the new configuration profile to the same group as the assignments for the baselines, and created a new group for the exclusion users which I excluded from the policy.
The issue
So up until this point I thought it was an easy task, and I started testing the results on one of my test devices, but for some reason after inserting a portable USB drive, it still kept asking for the “Before you can save files on this drive, you need to encrypt it using Bitlocker”
I started troubleshooting the process in order to determine whether the setting was applied to my system using the article I wrote earlier on MDM policy processing, but nothing could be found. The new policy got applied correctly which was reflected in both the Eventlog and the Registry as well. I also tried to see if the issue would resolve itself after a reboot, but that wasn’t the solution either.
The solution
After a lot of Googling I found the following thread on Reddit: “Bitlocker removable drive exception” and decided to check the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE registry path
So it turned out that even though the setting was reverted, this was not populated to this registry location. So after first testing the outcome of setting the RDVDenyWriteAccess key to 0 and validating that I could insert a USB drive again without me asking for BitLocker to Go encryption.
Normally when tattooing takes place, you could just deploy a setting undoing the initial setting, but since the setting in the Configuration Profile only allows for yes and not configured, and therefore lacks the No option, I couldn’t create a policy which would solve the issue. I decided to solve the issue by creating a small PowerShell script which I deploy to the exception group.
The script contains the following command: Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE -Name RDVDenyWriteAccess -Value 0 -Type Dword
Keep in mind that you would only need this setting if the user received the policy Denying access, and afterwards gets added to the exception group.
Conclusion
Even though Microsoft changed the behavior of the CSP policy processing more than one year ago where they moved away from tattooing the CSP settings to a model where the settings were removed if the CSP profile got unassigned as well. There are still some exceptions as this blogpost proves though. Let’s hope someone experiencing the same issue finds this article and can more easily solve the issue.
Microsoft mentions the tatooing behavior in it’s documentation: Assign user and device profiles in Microsoft Intune
