BitLocker unique identifiers are values used to identify the ownership of an encrypted volume. The device that performs the encryption holds the unique identifier and as encryption begins, it also records this against the metadata of that encrypted volume.
The identifiers are typically used in tandem with the BitLocker removable data-drive setting write access to devices configured in another organisation which, if set to block, will prevent write operations on devices where the unique identifier of the removable drive doesn’t match a list of unique identifiers managed on the device. The idea here is you want to enforce BitLocker on removable drives to improve data loss (encrypted drives, if found, are unreadable without the means to decrypt them), but you only want them to be encrypted within your organisation: someone can’t encrypt their device elsewhere and then copy data to it. You may want to do this because it means you, as an administrator, would not be able to decrypt it if required.
In some scenarios, such as Hybrid Azure AD Joined devices, when you enable the aforementioned setting to block write access unless it was encrypted within your organisation, you will find that after a reboot, the encrypted volume can’t be written to. That’s because Intune did not give your device (and therefore the encrypted volume) a unique identifier. When the encrypting device reboots, it loses the fact the encrypted volume was encrypted by itself, thus rendering it ‘unwritable’.
Group Policy provided a very simple way to manage unique identifiers (Windows Components\BitLocker Drive Encryption\Provide the unique identifiers for your organization) but the setting is not exposed through Intune endpoint security settings or configuration profiles. Originally I presumed I could just ingest the ADMX into Intune, however, Microsoft actually prevent the ingestion of most first-party Group Policies except a small list found here.
When all else fails, PowerShell 🙂
All the group policy does is manage registry entries:
- HKLM\Software\Policies\Microsoft\FVE\IdentificationField
- This is a DWORD set to 1 or 0, to enable or disable the use of a unique identifier
- HKLM\Software\Policies\Microsoft\FVE\IdentificationFieldString
- This is a string field which contains the unique identifier
PowerShell makes it pretty straight forward to update the registry, and you can do it for this using the below, where I use rucam365 as the identifier:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\FVE" $enable = "IdentificationField" $string = "IdentificationFieldString" $identifier = "rucam365" if(!(Test-Path $registryPath)) { New-Item -Path $registryPath -Force | Out-Null New-ItemProperty -Path $registryPath -Name $enable -Value 1 -PropertyType "DWord" -Force | Out-Null New-ItemProperty -Path $registryPath -Name $string -Value $identifier -PropertyType "String" -Force | Out-Null} else { New-ItemProperty -Path $registryPath -Name $enable -Value 1 -PropertyType "DWord" -Force | Out-Null New-ItemProperty -Path $registryPath -Name $string -Value $identifier -PropertyType "String" -Force | Out-Null} |
When the Intune Management Extension (IME) on the client next runs the script, registry will update:
Immediately, drives encrypted with BitLocker will have the identification field populated. This only applies to new encryption.