Some way some how, a user's machine couldn't get read the bitlocker password off of the TPM chip, and I had to enter the recovery key (stored in AD) to get in. No big deal, but once in the machine, I tried to suspend bitlocker per recovery documentation, and got an error message about the TPM not being initialized. I knew the TPM was on and activated in the BIOS, but Windows still made me reinitialize the TPM chip, and in the process it created a new TPM owner password.
I found that odd because it prompted me to save this password or print it (there wasn't an option not to), but it made no reference of a recovery password, nor did it back this password up to AD.
After the user took her laptop and left I started thinking that if the TPM password change, does the recovery password change also? If so, that new recovery password will need to be uploaded to AD, but MS' documentation doesn't make that clear, and doesn't back up the new recovery key (if one exists) to AD automatically when the group policy says it must, and from a network standpoint AD is accessible.
When BitLocker encrypts a drive it keeps the master encryption key on the drive itself, though not in plain text. The master password is kept itself encrypted by "Protectors". Each of these keeps a separate copy of the master key as only the protector that encrypted it can decrypt that copy of the master key.
When you have Windows encrypt a volume through the GUI it typically creates two protectors: a Recovery Password (RP) and a TPM key. As noted above, these are stored completely separately. If you have the GPO configured each time a RP is create it is stored in AD. This is completely automatic and if you have the GPO configured a RP cannot be saved to disk without uploading to AD (ie, no offline RP creation as AD wouldn't be available).
I strongly suggest ditching the GUI. It glosses over the function of BitLocker too much for a system administrator, and the actual operation of BitLocker really isn't that complicated. The CLI utility
manage-bde
comes with every version of Windows that supports BitLocker. It's pretty straight forward, though the syntax is a bit verbose.To see what the laptop's drive is doing right now simply run
manage-bde -status C:
. As for TPM issues, after unlocking the PC and booting Windows I always runmanage-bde -protectors -get C:
, copy the ID for the TPM protector (including brackets), then runmanage-bde -protectors -delete C: -id {the_id_you_copied}
and finallymanage-bde -protectors -add C: -tpm
. It's 30 seconds more work, but you know exactly what it's doing, and exactly where you stand afterward.I know this is old, got here looking for something else, but in my experience the automatic upload to AD after a change like that isn't always successful. I've been bitten at work several times because of this. After the 2nd time getting bit, I decided to script the upload process to ensure it happens instead of depending upon the automagic upload process that is supposed to happen. Here is what I wrote (BitLocker_UploadToAD.cmd):