9

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.

MDMoore313
  • 5,531
  • 6
  • 34
  • 73

2 Answers2

12

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 run manage-bde -protectors -get C:, copy the ID for the TPM protector (including brackets), then run manage-bde -protectors -delete C: -id {the_id_you_copied} and finally manage-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.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • Perfect. I am familiar with manage-bde, but since we are still rolling out bitlocker in our environment, it's still pretty new here and I didn't think to use it. I've set it up so that on our new machines we enable the tpm and enable bitlocker during our imaging process (sccm), up until this point we've had few machines that needed be to manually unlocked. – MDMoore313 Nov 08 '13 at 15:09
  • This is all coming back to me now: a protector is stored on the TPM key to decrypt the master password that's stored on the (I'm guessing) bootloader, and if that's not accessible then the recovery key has to be entered to decrypt the master key, but the master key itself isn't stored on the TPM chip. Is that the jist of it? – MDMoore313 Nov 08 '13 at 15:10
  • 1
    Yep, that's it. It's pretty rare that I have to unlock a machine (mostly just the dev's messing with settings they shouldn't be). I get calls semi-frequently when people leave bootable USB sticks in their machines though, TPM gets touchy about new bootable media like that (and once TPM is pissed you have to power off completely or it'll stay pissed). – Chris S Nov 08 '13 at 15:13
  • Yeah, she was a tinkerer, but we've started using BIOS passwords to prevent that sort of 'reset to default' thing happening (might not have been the case here but still), which would wreak havoc on our environment. – MDMoore313 Nov 08 '13 at 15:16
  • 1
    We use HP laptops and update the BIOS (if necessary) and flash a "standard" configuration (including company logo and password) to it when the laptop gets imaged using the HPQflash utility (in the BIOS packages you get from them) and bcu (BIOS Configuration Utility). I'd be surprised if Dell didn't have something similar. – Chris S Nov 08 '13 at 15:21
  • Yes Yes, they do, the Dell CCTK utility, which sets BIOS configs you specify. It works great so far, and it runs in WinPE, which is how I'm able to activate and enable the TPM during the image process, BIOS password as well. I don't know if they have the ability to set the company logo though, I'll have to keep an eye out for that. – MDMoore313 Nov 08 '13 at 15:36
3

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):

@Echo Off
cls
SETLOCAL
for /F "tokens=*" %%a in ('c:\windows\system32\manage-bde -protectors -get c: -type recoverypassword ^| findstr "ID: " ') DO SET ID=%%a
ECHO ID FOR DRIVE C IS: %ID%
ECHO.
ECHO REMOVING COLON AND ADDING HYPHEN TO BEGINNING...
ECHO.
set ID=-%ID::=%
ECHO NEW VALUE:
ECHO %ID%
ECHO.
ECHO BACKING UP TO AD...
c:\windows\system32\manage-bde -protectors -adbackup c: %ID%
ECHO.
ECHO DONE  (PLEASE CHECK AD TO VERIFY IT WORKED)
PAUSE
jscott
  • 24,204
  • 8
  • 77
  • 99
Ryan Cheesman
  • 31
  • 1
  • Reset, upload it, then pull it back down to make sure it was changed. Sounds good, +1. Oh, wait: you don't pull it back down? No powershell? You could probably implement the full cycle with powershell. – MDMoore313 Feb 10 '17 at 18:05