2

We have an MBAM server and tested policies which work normally for nearly every machine we've migrated. Though, I have seen 3 systems now that prompt for a recovery key instead of the users PIN. After recovering, each subsequent reboot asks for recovery keys again, requiring end users to contact support after each reboot. The recovery keys are being escrowed into AD\MBAM just fine.

Seeing as the process has worked on roughly 99% of systems so far, I'm assuming we're dealing with hardware or software level issues. In one case, I have reloaded the system and had BitLocker begin working normally indicating it was some machine state issue.

I've been through the gambit in terms of troubleshooting the TPM state, firmware upgrades, reviewing BitLocker logs, fully decrypting\re-encrypting devices but once the laptop is in this state, it always prompts for recovery.

Is there a way to discover which PCR exactly is triggering the recovery state so I can focus on a single PCR? We're about to go company wide with this process and I'm concerned that we might disrupt more users during migration. I'd at least like to have a plan to troubleshoot.

Residualfail
  • 89
  • 1
  • 10

2 Answers2

2

First, the reason why the systems keep prompting for the recovery key is because you did not reinitialize BitLocker to use the new PCR values. To do so, simply suspend BitLocker, reboot, and enable BitLocker again. However I would advice against this until you find out exactly what is causing the change in PCR values. In the worst case, it can be caused by a bootkit.

The TCG event logs record the full sequence of TPM measurement operations and how they change the PCRs. Windows keep a copy of the logs in encoded form in C:\Windows\Logs\MeasuredBoot\. As described in Decode Measured Boot logs to track PCR changes, you can use either TBSLogGenerator (requires installing the Windows Hardware Lab Kit) or PCPTool (requires building it yourself from source) to decode them. Note that the PCPTool linked in the article only works for TPM 1.2. For TPM 2.0, use the new version at https://github.com/microsoft/TSS.MSR/tree/master/PCPTool.v11

Assuming that your systems are on UEFI firmware, then as per BitLocker Group Policy settings, if the following GPO are not configured:

  • Allow Secure Boot for integrity validation
  • Configure TPM platform validation profile for native UEFI firmware configurations

Then BitLocker is using either PCRs

  • 0, 2, 4 and 11, or
  • 7 and 11

As far as I know, Windows does not record the expected value of each PCR used for unlocking BitLocker, so the only way to find out the offending PCR would be to compare the decoded log after hitting the recovery key prompt with one before when the system booted fine. Just narrow your search down to the aforementioned PCRs and you should be able to quickly find the culprit.

wmjdgla
  • 121
  • 2
  • I apologize for the delayed response. I was able to resolve my issue before your post, but this is still great information! – Residualfail Jun 28 '23 at 22:52
0

It has been a very long time since I worked through this project, so the details are fuzzy, but I did figure out my issue.

BitLocker by default allowed for 32 total failed password attempts before it locks the TPM out, forcing you to recovery mode. TPM 2.0 SHOULD have allowed one of those attempts to drop off every couple of hours. On some devices, the TPM implementation wasn't accounting for hours the device was powered off.

Some of my more in-and-out users would get into their laptop, check on things quickly, then shutdown. The short sessions were preventing the failure counts from decrementing so after a couple months' worth of failures, they'd hit the 32-failure limit and perma-lockout.

To get out of the state I had reset the failure counts by disabling protection on the boot drive, clearing the TPM, then re-enabling protection.

After the TPM was cleared, my root fix was to mercilessly shame my users for mistyping their PINs so frequently.

Residualfail
  • 89
  • 1
  • 10