다음을 통해 공유


Bitlocker and Domain Controller Logical Disks

Recently I had a customer hit an issue that was hard to resolve.....until we stopped looking at the data and reconsidered our design.

What We Had

  1. Virtual DC (Hyper-V guest running in Azure, but the location and virtualization doesn't matter!)
  2. C$ OS, E$ Sysvol/NTDS
  3. Bitlocker enabled for all drives 

What Happened

The customer installed a relatively small and innocent piece of software, rebooted, and then we entered the BSOD loop -- hard to see since it was on a guest in Azure.  After working through the night on the Azure aspect and out of ideas, we asked an AD guru to take a look.  Within minutes he had figured it out!

So what was going on?

  1. When the VM boots up, it tries to unencrypts the OS drive first. This OS disk key is stored in AD (accessible on another DC) or in 3rd party tool, like CloudLink
  2. Once the OS is unencrypted, Bitlocker frantically tries to unlock any data drives.....
  3. Meanwhile AD services are starting up (among the first services), but they can't get to the AD database (it's sitting on that locked E$.....)
  4. AD determines it can't get to it's database, crashes, throws the BSOD (with a nice pause so you can frantically try to write down the error message), and then reboots the server.
  5. The cycle repeats....

Basically our DC is so secure, even we can't use it!  Luckily a DC is easily rebuilt and we all know better than to only have a single DC in the domain, right?

Lesson Learned

If you want to Bitlocker your DCs, put all those critical DC bits on the C$! 

 

A big thanks to John Bay, our AD guru!

Comments

  • Anonymous
    January 13, 2016
    and enable ReadOnly Cache on the C: drive to meet the AD requirements if it is an Azure VM :)