Bitlockered devices following updates

[Rigo]

I've got three laptops to come in following bitlocker request after the latest update.
One of them was originally set as a local account so she's got no clue and there's no key in her MS account.
Any suggestion how to get around this?

 

[timeshifter]

Is she able to log in to her account on the computer?

 

[Rigo]

Is she able to log in to her account on the computer?

No, it's asking for the key

 

[NviGate Systems]

No, it's asking for the key

Two possible scenarios from what I see. Someone else setup the device with thier MS Account then created a local account account and deleted the MS Account. That MS Account is the key holder despite it being deleted.

Option 2, Bit Locker is in a "active and waiting" phase, which means keys are available but not assigned. It gets triggered but no recovery keys were handed out. To avoid this situation you have to explicitly disable Bitlocker, not just have a local account.

There is no "getting around". Bit Locker detected something that triggered it, and it's working as intended. There may be rare cases of things going back to normal, but that's not the "normal".

Client learned a hard lesson in not having backups possibly, and you would probably want to explicitly deactivate BitLocker on machines that pass your bench (after suggesting it to your clients of course).

The nice thing is you can squarly blame MS for this. It's not your fault, it's MS. Customer can take it up with MS. Or gets backups in place. Sorry to sound harsh, but it seems Windows 11 is going to need more idiot proofing, courtesy Microsoft. What will MS think of next.

 

[Rigo]

She checked her MS account and there's no key listed.
I'm hoping it's still in the waiting situation as I've been able to access some drive in this instance when connected to another PC.
If not well, not nice.

 

[YeOldeStonecat]

Bitlocker performs two things when you power on a computer...
*Ensure the disk is encrypted in a healthy state
*Ensure the boot process is healthy and proper. In modern systems it does this by communicating with the TPM, which is where the key is stored, and it makes sure "nothing is different than the last time". When larger BIOS updates happen, the system board can be ever so slightly changed. Enough for Bitlocker to say, "Hey, something is different here, let's verify by asking for a manual method to prove the key...because this TPM seems like it might be different".

Hence, why you see some systems ask for the key after some BIOS updates.(but not all BIOS updates).

If no key is found...it's not a good situation...Bitlocker is going its job.

 

[Porthos]

One of them was originally set as a local account so she's got no clue and there's no key in her MS account.

Who first turned on the computer for the first time? if she did not do it there are other questions like how was a local account created? What bypass of the MS account was used?

 

[britechguy]

Enough for Bitlocker to say, "Hey, something is different here, let's verify by asking for a manual method to prove the key...because this TPM seems like it might be different".

"Might be" should not be enough. No normal UEFI/BIOS update should trigger this kind of thing (though I know it does, which is another reason I avoid BitLocker like the plague).

This is one of those, "Why can't Microsoft get this stuff to work as seamlessly and flawlessly as others do?," kind of things. And until they do, no thanks.

 

[YeOldeStonecat]

I put the blame on the vendors..they release the BIOS updates.
Unfortunately BIOS updates are important...they ensure reliability, computability, and a whole slew of other important things.

Bitlockers job is basically two fold...
*Encrypt the disk
*Detect when its disk is...in a changed environment, because...a changed environment could be some nefarious actions upon it. On a normal day to day basis, it expects 100% clarity, 100% visibility, when communicating with the TPM. When BL detects a possibly changed environment, it needs to hit the big red "halt button" and throw up the challenge. That's the other half of its job.

I realize, via reading various tech boards like this, that the fallout stinks for unknowing residential users. And there can be substantial loss...for when those unknowing residential users have no clue about how the computer was originally set up, possibly setup with a Microsoft personal account at some point in time in the past. I know I live the luxurious world of managing Microsoft business accounts for our clients and everything is automated and pulled in and documented...so I'll always have that key avail. And...rather often, we do run into this...BIOS update...computer sits at the BL recovery key prompt...we retrieve that key ..because we manage the clients Microsoft biz accounts and I have an InTune BL policy which captures and stores this key in the tenant. I do not look forward to the day some non managed client of ours presents us with this problem...I suspect it can happen.

But my goal here was to state...this is expected Bitlocker behavior...notably explaining the "why it does this"...from a BIOS update. It's due to a very slight change in the systems BIOS from that update...enough to cause BL to stand up and ask for the key...expected behavior from BL, perhaps the vendor can come up with a more gentle BIOS update that doesn't rip the carpet out from underneath BL. It doesn't happen with every BIOS update...just..the ones that someone affect something between the drive, and/or the TPM.

 

[britechguy]

But my goal here was to state...this is expected Bitlocker behavior...notably explaining the "why it does this"...from a BIOS update.

Which I never doubted for a moment.

That being said, I stand by my position that BitLocker, if behaving as described (and I don't doubt it is), is being "hypersensitive" to what are bound to be routine changes in UEFI/BIOS updates. That's not good, nor is it helpful, and it will likely drive the disabling of BitLocker even in instances where it would serve a very legitimate purpose.

All it's going to take is a "Once Burned," event, and you can be sure that the result will be more than "Twice Shy," when, for whatever reason, keys cannot be obtained and complete data loss results.

If we think people are bad about keeping track of passwords . . .

 

[fincoder]

"Might be" should not be enough. No normal UEFI/BIOS update should trigger this kind of thing (though I know it does, which is another reason I avoid BitLocker like the plague).

I agree. Automatic updates should not trigger Bitlocker (or Device Encryption) to prompt for the key. Regardless of the supposed "reasons" it isn't acceptable. Automatically updates installed is not an actual security risk, when it causes Bitlocker lockdown it's a straight-up Microsoft bug in my opinion.

 

[fincoder]

She checked her MS account and there's no key listed.

When this happens, it always ends up being a different MS account. She needs to attempt Microsoft Account login from a browser for ALL email addresses she has (or had at the time of getting the computer). Account recoveries if necessary.
Only other option is to erase the drive and fresh install of Windows.

 

[Rigo]

Who first turned on the computer for the first time? if she did not do it there are other questions like how was a local account created? What bypass of the MS account was used?

She said her brother helped her set it up. And they did it to a local account.
I've read some articles about an upcoming update that was going trigger bitlocking even if it hadn't been active.
She's got a Surface laptop so I guess these would definitely suffer the indignity.

 

[NviGate Systems]

She said her brother helped her set it up. And they did it to a local account.
I've read some articles about an upcoming update that was going trigger bitlocking even if it hadn't been active.
She's got a Surface laptop so I guess these would definitely suffer the indignity.

My money is on the brother setup a MS Account, then created a local one for her to use. Get her to get him to check his MS account for a recovery key, I'm 99% sure it will be there.

 

[fincoder]

She said her brother helped her set it up. And they did it to a local account.

Does she know the difference between local account and Microsoft account? Most of my customers don't

 

[Markverhyden]

My money is on the brother setup a MS Account, then created a local one for her to use. Get her to get him to check his MS account for a recovery key, I'm 99% sure it will be there.

Not only that but the tablet should show up in his account as an enrolled device.

 

[Rigo]

I got the device today.
Definitely bitlockered.
She says it's listed under her account but with no key.
Her previous now defunct Surface Pro is also listed with the associated key, but none for the newer device.
She's adamant they didn't use her brother account at all and she had him check again.
Sounds like the lock was set without generating a key.
If it's listed under her regular account I assume it can't be associated with any other one?
She's going to review her work and school accounts as well just in case.

 

[Rigo]

Does she know the difference between local account and Microsoft account? Most of my customers don't

Yes, she does.
Reasonably cluey

 

[Rigo]

the brother setup a MS Account, then created a local one for her to use

I queried her about that and she said that didn't happen.

 

[Sky-Knight]

I queried her about that and she said that didn't happen.

She lied.

Not by intent of course, she simply doesn't know. But the fact of the matter is, Windows doesn't encrypt itself without a target to backup the recovery key. Note, this backup includes a USB storage disk! On which it's a text file... it doesn't have to be directed to the online account if it's manually triggered.

Regardless of HOW it happened the lack of the recovery key is the exact same outcome... the data is gone. There are some OEM (Dell / HP) systems that SHIP encrypted.... she may be in this circumstance. But it doesn't change the reality of where she is right now.

You can format the unit, reconfigure it without the data, and return it to service. You cannot recover the data.

Doesn't matter how long this thread gets.
Doesn't matter how much time you waste trying to get the customer to see reality.

Their data is gone, and it's gone because they didn't track their account details. Windows 11 badgers you into oblivion for an online account for a reason. Windows 10 behaves the exact same way on the same hardware. It's not your job to recover the details, just inform them of how it works, rebuild the unit, and help them just long enough to see the new installation's recovery key present in their MS account.

@YeOldeStonecat It's triggered when the hash of the actual EFI microcode changes. The OS sees the EFI as a foreign object, authentication is required. Updates to the Intel Management Engine, do not trigger this process, because the actual code booting the system doesn't change. There is no way to "make things more gentle", if you change the EFI code at all, the hash changes, and this process fires. Which is why the only safe way forward is to suspend bitlocker, or decrypt the disk before a BIOS update.