In this post I will explain how to configure, enable and deploy Bitlocker via GPO’s (Group Policy Objects). If you or your organisation are able to use or use MBAM (Microsoft Bitlocker Administration and Monitoring), SCCM (Microsoft System Center Configuration Manager) or Intune please use that instead.
The clients in this scenario are members of a traditional domain (non Azure AD) and are equipped with a TPM (Trusted Platform Module) that we want to use for storing the encryption keys. In addition a recovery key is generated that will be stored in AD in case the drive needs to be recovered. As our targets are Windows 10 machines we will be using the new XTS-AES introduced in version 1511.
Configuring Bitlocker GPO’s
The following images are screenshots shared by reddit user /u/Andy202/ and show the configuration we are going to use:
Enabling Bitlocker
While the configuring can be done with Group Policies, actually enabling Bitlocker on client machines needs to be done either by manually enabling it on the machine or by running a PowerShell script. The same reddit user that gave us the example configuration also provides the following PowerShell script used for enabling Bitlocker:
$CdriveStatus = Get-BitLockerVolume -MountPoint 'c:'
if ($CdriveStatus.volumeStatus -eq 'FullyDecrypted') {
C:\Windows\System32\manage-bde.exe -on c: -recoverypassword -skiphardwaretest
}An alternative script using the “new” bitlocker powershell cmdlets:
$BLV = Get-BitLockerVolume -MountPoint 'c:'
if ($BLV.volumeStatus -eq 'FullyDecrypted') {
Add-BitLockerKeyProtector -MountPoint 'c:' -RecoveryPasswordProtector
Enable-Bitlocker -MountPoint 'c:' -TpmProtector
}In short both scripts do the following:
- Set drive information to variable $BLV
- Check if the encryption status equals ‘FullyDecrypted’
- If so add add a recovery password (which is pushed to AD)
- Enable Bitlocker with the TPM option to store the keys in the TPM
While both of the above scripts will work I chose the latter. The script will need to place in a location where client machines can reach it for example the SYSVOL share.
Deployment
The goal here is to automate the deployment. Windows offers several options for performing a task after a predefined trigger namely:
- Logon scripts (runs as the user when the user logs in)
- Startup scripts (runs at system start and before the user logs in)
- Scheduled tasks (runs as any user you like it to run and whenever)
I have tried all the options and the only one that worked was the Scheduled Task. The reason (I think) lies in the fact that for enabling Bitlocker a user with administrative privileges needs to be logged in. For this reason we configure the task to use ‘NT AUTH/System’ privileges and to trigger after a user logs in. After a user logs in the task triggers and runs the PowerShell script made in the previous step. Et Voila, Bitlocker with TPM is now enabled and the recovery keys are safely stored in AD.
(Security) Considerations
Now as a former pentester / ethical hacker I must disclose that this is in no way the most secure Bitlocker setup. While it might, in theory, be possible to prevent attacks targeting memory (DMA/Cold boot) in software (where the decryption keys are stored), time has shown again and again that given enough time every piece of software or hardware can be compromised.
So, if you are in need for a more secure setup please consider using Pre Boot Authentication in addition to the TPM as this requires something outside the system (a password known only by the user) to unlock the TPM and decryption keys. This prevents the keys ending up in places where attackers can access them. More info can be found in the references below.
References:
- Initial config
- Bitlocker Powershell cmdlets
- Bitlocker countermeasures
- Demonstration of memory attacks against Bitlocker
- Repo of PCILeech (a tool to dump the contents of memory)