BitLocker doesn't auto unlock fixed data disk with TPM encrypted OS on Hyper-V host

Daniel Ray 106 Reputation points
2020-11-02T12:43:31.737+00:00

Working with a Windows 2019 Hyper-V server and was asked to implement Bitlocker for disk encryption. The hardware has an TPM and the OS disk has been encrypted.

The VMs are on a fixed data disk that needs to be encrypted, then unlocked on boot so the VMs can automatically start. manage-bde and the related Powershell commands only allow auto unlock of the fixed data disk based on the user, so the user has to login once before the disk becomes unlocked.

Anyone know how to tell the TPM encrypted OS to unlock the fixed data disk before the hypervisor starts up?

Windows for business Windows Server Devices and deployment Configure application groups
0 comments No comments
{count} votes

Accepted answer
  1. Daniel Ray 106 Reputation points
    2020-11-08T12:54:50.993+00:00

    So we ran the gambit here on replies. A few "it just works," and a couple of replies that aren't related. The issue here is that Bitlocker stores the key material for fixed data disk's autounlock in the user's profile, and only does the auto unlock when the user logs in, as per Microsoft's documentation. I was hoping there was some way around this.

    Following this link, which documents the issue:
    https://www.techiessphere.com/2017/04/system-startup-script-to-auto-unlock-bitlocker-encrypted-drive.html

    The AD approach does the unlock later in the boot process. You could also use an AT/Sched Task in the same way. In the end, I wrote a Windows service that runs the manage-bde command to unlock the drive early in the boot process. The keys are marked hidden and the ACL only allows the service to read them.

    2 people found this answer helpful.

3 additional answers

Sort by: Most helpful
  1. Anonymous
    2020-11-03T07:59:20.157+00:00

    Hi,
    For fixed data drives, you can set the drive to automatically unlock when you unlock the PC, if you prefer, as long as the operating system drive is BitLocker protected.

    You could try turning on the Auto-unlock for BitLocker Drive following this instruction:
    https://www.tenforums.com/tutorials/37662-turn-off-auto-unlock-bitlocker-drive-windows-10-a.html

    Please note: Information posted in the given link is hosted by a third party. Microsoft does not guarantee the accuracy and effectiveness of information

    Best regards.

    ============================================

    If the Answer is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    1 person found this answer helpful.

  2. Bagitman 596 Reputation points
    2020-11-02T18:40:36.32+00:00

    What makes you think it has to do with user logon? It hasn't.
    We are in the same boat and it just works. (Hyper-V 2019 Core with c: and d: bitlocked and d: autounlocks very well).


  3. Sebbl 1 Reputation point
    2020-12-27T11:00:02.627+00:00

    Hi,
    I have basically the same problem as DanielRay: Bitlocker volumes won't auto-unlock unless a user logs into the system.

    My setup:
    Physical machine with Windows Server 20H2 (Core) and Hyper-V enabled. Two storage pools (one "simple", one "mirror") with two Disks and two Volumes (D: and E:). Both volumes are BitLocker encrypted with auto-unlock enabled. I use a Ryzen 5 3rd gen consumer CPU with firmware TPM.
    However, when I restart the server and don't login once, all my shares on volume D: and E: are missing. Also, the administrative shares (D$, E$) won't show up. Accessing via Windows Admin Center WebGUI, I can see, that there is only one volume (C:) under "Files & file sharing".
    Once I log in (e.g. via Remote Desktop), the administrative shares instantly appear and Windows Admin Center displays volumes D: and E:. I have to login with the user which enabled Bitlocker auto-unlock, as any other user won't work.
    This seems to be, because the ExternalKey encrypter, which has the AutoUnlockProtector=True flag, is stored in the HKCU-registry hive (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\FveAutoUnlock\<ProtectorGuid>). The HKCU-hive only get loaded, when the specific user signs in. So, the system cannot unlock Bitlocker volumes during system start.

    However, I had this exact same scenario working on an older version of Windows Server and different hardware. So, I thought, I made a mistake and encrypted / decrypted all volumes multiple times - even reinstalled the whole system, but I cannot get this to work.

    I did some further testing inside some Hyper-V virtual machines with Hyper-V TPM emulation:

    • Windows Server 2019 Desktop Experience, "regular volume" for reference and Storage Pool Disk+Volume. Auto-unlock worked as expected without the need for a user to login.
    • Windows Server 2019 Core, "regular volume" for reference and Storage Pool Disk+Volume. Everything worked as expected. My assumption was, that that the GUI versions did something different.
    • Windows Server 20H2 (Core), "regular volume" for reference and Storage Pool Disk+Volume. Even in this scenario, everything worked as expected. I have no idea why, because it matches my physical machine best.

    The main difference between my physical machine and my virtual machines I noticed was, that the HKCU...\FveAutoUnlock is not present. I assume, that’s why auto-unlock works, because it is not dependent on the HKCU-hive. Sadly, I don't know why BitLocker behaves differently.

    Some reasons I can think of:

    • Different behavior of systems with Hyper-V Hypervisor / without Hyper-V Hypervisor (although I got this working some years ago on a bare metal Hyper-V host).
    • Different behavior of AMD Firmware TPM and Hyper-V emulated TPM
    • ?

    If anyone has additional ideas or hints, I could test, please let me know. Next Thing I try is using a discrete TPM.


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.