This document has an overview of Bitlocker, explains how to enable storage of bitlocker recovery keys to the NETID domain via group policy, and how to recover those recovery keys when needed.
Introduction to Bitlocker
Using Bitlocker on systems in a Delegated OU is recommended for any system which is regularly used to interact with restricted or confidential data. Bitlocker provides at-rest volume-level data encryption.
To be secure, Bitlocker requires a Trusted Platforms Module (TPM) 1.2 or newer chip. Bitlocker can be used without a TPM, but this is not as secure.
The TPM chip allows the volume based encryption to check whether the computer has been tampered with, and trigger a recovery mode if it detects that it has been tampered with.
Bitlocker recovery mode can be triggered by a number of situations, including:
- A malicious attempt by a person or software to change the startup environment. Rootkits are one example.
- Moving the BitLocker-protected drive into a new computer.
- Installing a new motherboard with a new TPM.
- Turning off, disabling, or clearing the TPM.
- Updating the BIOS.
- Upgrading critical early boot components that cause system integrity validation to fail.
- Forgetting the PIN when PIN authentication has been enabled.
- Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
- Having a USB drive in at startup (this can be fixed by removing the USB drive at bootup).
When Bitlocker recovery mode is triggered, you must provide the recovery keys to get access to the Bitlocker enabled volumes on the computer. The recovery keys are provided to the user enabling Bitlocker, and can optionally also be written to AD.
It is a good idea to write Bitlocker recovery keys to AD, because users can often have a hard time keeping track of the recovery keys for when they later need them; it enables IT support personnel to help users when they run into Bitlocker recovery mode. When the recovery keys are written to AD, only users who have full permissions to your computer objects can read them. By default, this is your OU Admins, the NETID domain admins, and whoever created the computer account.
Microsoft’s BitLocker Drive Encryption documentation provides a good introduction and background material for Windows 7 that you might want to review. See BitLocker for the equivalent Windows 8 documentation and BitLocker for the equivalent Windows 10 documentation.
How to Enable AD-based Storage of Recovery Keys
To enable AD-based storage of your Bitlocker recovery keys, you’ll need to do the following:
Create a GPO linked to your delegated OU which enables the following settings:
- Computer Configuration\Policies\Administrative Templates\Windows Components\MDOP MBAM (Bitlocker Management)\Operating System Drive\Choose how BitLocker-protected operating system drives can be recovered = Enabled
- Under options set the following:
- Save BitLocker recovery information to AD DS for operating system drives: Box checked
- (Recommended) Do not enable BitLocker until recovery information is stored to AD DS for operating system drives: Box checked
- There are similar settings for Fixed and Removable Data Drives
The setting “Do not enable BitLocker until recovery information is stored to AD DS for operating system drives” is not technically required in order to store your keys in Active Directory. However,We recommend that you enable this setting, because if you don’t, you’ve lost your assurance that this information will be available for recovery when needed. For more information, see the Microsoft BitLocker Group Policy Settings document.
What to do when Bitlocker Drive Enable happened BEFORE joining the NETID domain
- Ensure that you’ve enabled AD-based Storage of Recovery Keys as described above.
Method 1
- If you have a current PowerShell environment, these two lines will back up the recovery key for a volume called “C:” to AD:
$BLV = Get-BitLockerVolume -MountPoint “C:”
Backup-BitLockerKeyProtector -MountPoint “C:” -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId
Method 2
- Open an elevated command prompt on the system.
- Run the command:
manage-bde -protectors c: -get - You will receive output similar to this:
BitLocker Drive Encryption: Configuration Tool version 6.1.7600
Copyright (C) Microsoft Corporation. All rights reserved.Volume C: [Windows]
All Key ProtectorsNumerical Password:
ID: {9557D616-0BD0-4B2A-8A2A-9DD4C5C21CCC}
Password:
527560-068585-114378-134288-010131-496430-662706-631224TPM:
ID: {5EB69F42-4ABC-4D6B-87C5-C894A3840FC4}
What you are looking for is the Numerical Password ID. - In this example to backup the password to AD you would type the following command: manage-bde -protectors c: -adbackup -id {9557D616-0BD0-4B2A-8A2A-9DD4C5C21CCC}
- When that completes you will receive the message: Recovery information was successfully backed up to Active Directory.
The documentation for manage-bde states you do not have to specify the ID but, in fact, you do.
How To Recover AD-based Storage of Recovery Keys
For Windows 8 and Later
Send an email to help@uw.edu to request assistance in obtaining a computer’s recovery key.
For Windows 7 and Earlier
To obtain the Bitlocker recovery key for a computer which has stored it in AD, run the Get-BitLockerRecoveryInfo.vbs script.
You will only be able to obtain a recovery password from AD for computers in your delegated OU. Domain admins are capable of recovering any recovery password in AD, if for some reason your OU admins are unavailable.
Usage: Get-BitLockerRecoveryInfo.vbs [computername]
If [computername] is omitted, the script assumes the local computer.
For example:
C:\bin>Get-BitLockerRecoveryInfo.vbs naboo
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
Accessing object: LDAP://CN=NABOO,OU=pottery,DC=netid,DC=washington,DC=edu
name: 2007-10-23T13:44:12-08:00{62E83AE2-DB9F-4B4E-BC7C-2ED057E13FC4}
msFVE-RecoveryGuid: {62E83AE2-DB9F-4B4E-BC7C-2ED057E13FC4}
msFVE-RecoveryPassword: 327679-031823-308099-108900-464640-385660-335214-476806
