windows-itpro-docs icon indicating copy to clipboard operation
windows-itpro-docs copied to clipboard

Published 20 hours ago • verified publisher icon MicrosoftDocs

WRONG! Bitlocker is still NOT resumable and does not resist a reboot forced by a CSP policy when joining a domain

Open verdy-p opened this issue 1 year ago • 1 comments

[Enter feedback here] Your statemetn saying that Bitlocker can be resumed even if we shutdown or reboot Wnidows is FALSE. Bitlocker encyption CANNOT be resumed as long as it has not finished encypting the filesystem metadata (notably NOT if encryption is started in parallel on all drives.

When an already intalled PC, which has other mounted volumes, e.g. on an external RAID with many NTFS/ReFS volumes, it can take MUCH MORE than 10 minutes to compelte the initial step and allow Bitlocker to be paused in a safe state.

But when we join a PC to an AD domain, it instantly tries to apply enterprise policies: some policies instruct to encrypt all drives in parallel, and then display a notice that the PC will be force rebooted in 10 minutes. When that time comes, that policy does NOT properly pause Bitlocker in a resumable state.

After the reboot, even if the encyption keys were properly backed up on the domain, these volumes will no longer mount! All their data will be lost and recoverable!

The forced reboot makes incorrect assumptions, and by trynig to accelerate writes made by Bitlocker, it corrupts its log, stops all I/O before the journal containing the state of encryption is properly saved in order.

I have seens that EXTEREMELY SEVERE bug multiple times! Bitlocker encyption does NOT cohabitates cleanly with the FORCED reboot that you can place together in a CSP policy: This is stupid. Take the time to pause Bitlocker properly, reboot even if drives are still not fully encrypted, but then the PC can continue with not all policies applied (and the effective joining will be delayed if needed, or can be reversed if enryptnig everything is completely undesired. After that users have the rime to disconnect or unmous all their drives. And they should be offered a way to NOT encrypt all volumes, just the essential system volumes for booting Windows, and being able to logon, even if it's still with a local account or Personal Microsoft accout.

Now users have the choice to reverse the Bitlocker and restore the volumes to plaintext, and eventually stopping their attempt to join the domain, or they will just encrypt their drives volumes ONE BY ONE (imagine a RAID or Storage space with many volumes created on the same array of hard drives, or on the same Storage pool: encrypting all of them ni parallel uses TOO MUCH I/O and for TOO LONG TIME).

So there are too bugs:

  • (1) Bitlocker cannot be always be paused safely (in a resumable state).
  • (2) The Forced reboot (after a specific time, even it it's more than 10 minutes by default, does NOT check that Bitlocker (or other encryption system is going on) and does not properly pauses it, instead it kills them abruptly, and completes some I/O in arbitrary order and then reboots before all of them are performed and flushed to the storage. The result is LOSS of ALL the data on the volume.

And don't hope that encryption keys will help: the keys will be accepted, but Bitlocker will complain that the volume cannot be mounted, because it is UNABLE to continue if the NTFS/Refs journal was PARTIALLY written and instead the journal stored a I/O completion event BEFORE the I/O was effectively applied.

  • The combination of the two bugs is MUCH MORE DRAMATIC than the effects of a ransomware, and domains that use such CSP when we join them behave worse than ransomware: they completely and permanently destroy all personal data, because all essential NTFS metadata becomes unusable.: this includes in fact almost ALL AD domains hosted on Azure or in many enterprises that stupidly apply the default CSP policies. This includes Microsoft own domains to which users may be permitted to have an account (such as "free" Azure trial domains, or Windows Insiders domains !
  • Enforcing the encryption and policies at the same time, and using forced reboots is only safe if loosing everything on the PC is not a problem because all the data is already preserved elsewhere. But users on their personal PC are given NO chance. Users must be given time to complete all steps. It's YOUR RESPONSBILITY to guide them, but not force them with really bad assumptions; and users should have a way to press an EMERGENCY STOP button without being forced to reboot, even if this limits what they are allowed to do in the domain as long as all policies are not (timely) applied.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

verdy-p avatar Jul 31 '22 17:07 verdy-p

Thanks @verdy-p for the feedback. We'll need to discuss with PMs about what of this we should include as a callout in the docs versus what is product feedback. In the meantime, I encourage you to also file this information via the Feedback Hub to provide it directly to the engineering team.

aczechowski avatar Aug 03 '22 02:08 aczechowski