Bitlockering a server

On May 9, 2014, in Security, by

Balancing paranoia with manageability.

Adding bitlocker to a server and so far I’m comfy with this:

1  Do not bitlocker the C boot drive.  I want the drive to be able to automatically reboot.

2.  Bitlockered the data drives.  One can also add a script or task to mount the bitlockered drives.  (script info from


for the value of -recoverypassword  you enter in the recovery number that you saved to a usb flash drive or printed out.

So here’s how I set this up on a Gen7 microserver, the same TPM chip works for the Gen8.

(on and as an aside, installing 2012R2 on a Gen7, DISABLE the network card in the bios, install the OS, get the bios update on there, reboot the machine, install the nic driver.  If you do not disable the network card the machine gets stuck on finding devices)

So you buy your TPM card.  Cheapest price is more expensive.

Install the card in the slot right at the very very front of the box


That open slot right in front of the tray handle is your TPM chip location.

See it a bit better?

Put it in the slot, then put in that funky plastic thing that makes the TPM more stable.  Once you install this, consider it ‘used forever’ and never move it from this server.  You can’t play then move it to another server.

Go into the bios, enter advanced and enable the TPM security stuff

change disabled to enabled

Reboot the box

On a server you go into server manager and roles and enable the bitlocker role.

Here’s the next trick, once you reboot you expect that when you go into control panel, security that the bitlocker gui will be there.  Oh no, it’s not.

You need to either stick in a previously bitlockered thumb drive for the bitlocker gui to show up – or you right mouse click a data drive and you get the option to now encrypt the drive.

But bottom line that info here:

at step three is wrong for Servers.  There is no gui like that until you encrypt your first thing.  Then you get that gui.


Once you encrypt your first drive, then you get the manage section

Make sure you save the encryption key. 

And finally decide how you want to manage this.  Manually mounting each drive?  Balancing the need of use by setting up a script or a task to auto mount the drives?

Bottom line you have to find the right balance.


14 Responses to Bitlockering a server

  1. Indy says:

    And hope that if/when a motherboard replacement ever occurs on that server you remember to bring the TPM key with you for the replacement install. Or that some update to HP doesn’t bork the TPM install. And that your Key is actually stored safely. In multiple locations, and those are guarded well.

  2. bradley says:

    And a backup so one can reload.

  3. Yes, BitLocker the C: drive. Absolutely. But then enable Network Unlock. This will allow the server to be rebooted remotely, while still preserving full encryption across the entire server. Not protecting the C: drive is just wrong.

  4. bradley says:

    Like I have server licenses lying around? I’m not comfy with bitlockering the c

  5. Indy says:

    If you aren’t comfy bitlockering the system partition, then explain how you are comfortable encrypting the partition holding the actual data? You trust it either completely (install), or not at all(do not install).

    You can get around TPM/Bitlocker by putting a chip in-between TPM and the motherboard. The chip passes through the data that the TPM checks to verify the system is AOK, while a bootloader is installed that actually changes the system into an insecure state. This is high-level stuff, not likely to be used on Susan’s Small Business setup.

    TPM/Bitlocker is another layer of annoyance that is likely to stop the most trivial of attacks. And for that it should be honored. But it also shouldn’t be relied on as an absolute end-all solution to the issue of physical access = machine **can** be compromised.

    If you have the budget to support a Bitlocker support setup on one single partition, you have the budget for a virtual setup or separate server license. Period.
    Also be VERY careful with how that system can be powered off. And make sure you include characters from nonsensical areas of ANSI if possible.

  6. bradley says:

    This is client PDFs. It’s not on a system that can handle hyperV (not enough ram), I really don’t need a virtual setup here, nor do I want one. It’s plain file storage. I’m comfy with the data drives because I back it up in all sorts of other ways that are also encrypted but in a different encryption.

    I want to ensure that at all times I can boot into the system. The network unlock adds another two deployment to patch (excuse me I really don’t want three server OS’s to now patch rather than the one) , and it has WDS services to now deal with. I want this guy to auto boot – and I don’t need the complexity of the network unlock. I reviewed that when I started this project and didn’t like the patching/management/ additional hardware requirements that it demanded. I’m patching seven servers now, I didn’t want that to jump to nine I’d have to maintain.

    Bitlocker is here so that should a physical attack on the office occur I can assure myself that the hard drives have encryption.

  7. Chris says:

    So … your C: drive is unencrypted. And you’ve set up a scheduled task to unlock the data drives, which includes the plain text password. And which is stored on the C:\ drive.

    What’s the point again?

    I’m running Bitlocker with multiple clients on SBS 2011 and Server 2012, no Hyper-V, no network unlock, since 4 years without issues. The key is stored in the TPM. This setup is identical to setting up Bitlocker on your laptop or tablet. As long as you make sure that you have the key safely stored somewhere else, this is safe. I’ve never had an instance where the server didn’t survive a remote reboot. The only times when I had to re-enter the key was when I changed the server hardware (added RAM or a NIC), and at this point the prompt was expected.

    Securing your C:\ drive is the first step when setting up Bitlocker, not the last step. Set it up in a test environment, and get comfortable with it – it’s not as scary as it sounds.

  8. bradley says:

    If the server is stolen, the drives are encrypted. An attacker that steals the system will pull the drives, not boot the server.

    It’s for offline physical theft of the server/data at rest.

  9. Chris says:

    I agree that an attacker will pull the drives, but that’s exactly the problem. After connecting them to another computer, all they need to do is to go to C:\Windows\System32\Tasks (which is not encrypted), and they have your Bitlocker password for the data drives. That’s not a level of security that I’d be comfortable selling to my clients.

    Physical theft is also the reason I’m using Bitlocker, but in my understanding that absolutely requires an encrypted C:\ drive, otherwise it’s quite pointless.

  10. bradley says:

    The physical attacker I see sells the machines, they do not determine that there’s a password in the task folder. They’d have to reset the admin password to get into the system.

    That’s not what physical attackers do based on conversations with Police in my area. They are dumping the equipment and selling it. An attacker that would go after the task to dig out the password is going to send me a phishing link and get remote access to my server. They aren’t going to steal it.

    Bottom line, I have to ensure that the system can be remotely patched and the system can reboot without needing a human entering a password at the console.

  11. Chris says:

    There’s no need to reset the admin password if you connect the drive to another machine 😉

    Reboots without user intervention is exactly what TPM does when used with Bitlocker. As long as the machine hasn’t been tampered with, TPM will supply the password to Bitlocker, which then unlocks the system drive and boots the OS. No user intervention required.

  12. bradley says:

    That wasn’t my experience, it wasn’t mounting the data drive.

  13. Chris says:

    If the system drive is encrypted, you will get a “Turn on auto-unlock” option for any additional drives. Without an encrypted C:\ drive, this option does not exist.

    There’s one exception that took me several months to figure out: If the hard drive is marked as a removable drive (i.e. you can eject it like a USB drive, and Bitlocker lists it under “Removable data drives”), then Bitlocker will only unlock the drive when a user logs in. For SATA drives, this can be fixed by installing the manufacturer’s SATA drivers (which turns the drive into a “Fixed data drive”). For USB drives (should you use these as permanent drives in your server), this can be fixed through a registry change (effectively disabling hotplug for USB drives) or a scheduled task like the one above (which is secure as long as C:\ is encrypted).

  14. bradley says:

    I’ll have to test, as my test bed wasn’t working like that.