:::: MENU ::::

Zero-Touch BitLocker Deployment

Difficulty Level: Intermediate\Advanced

Outline

  1. Prerequisites
  2. Background
  3. Vocabulary 
  4. Active Directory Functional Level for Recovery Keys
  5. Machines with TPM Installed, and Enabled.
  6. Group Policy Settings
  7. PCR Settings
  8. Commands to Manage BitLocker
    1. System Drive Partition
    2. Create the Recovery Key
    3. Create the TPM Key
    4. Enable Encryption
    5. Suspend BitLocker Encryption
    6. Check BitLocker Status
  9. Life Cycle Management with Sample Scripts
    1. Provisioning
    2. Troubleshooting
    3. Re-imaging\Re-Provisioning
    4. Recovering from Recovery Mode
    5. Decommissioning
  10. Caveats
  11. Security Implications
  12. Conclusion

Prerequisites\Requirements:

Server End:

  1. Windows Server 2008 domain functional Level or higher
  2. Any Endpoint Management Server – SCCM, Kace, LanDesk, etc…

Client End:

  1. OS:
    1. Windows 7 Enterprise or greater
    2. Windows 8.1 Professional or greater
    3. Windows 10 Professional or greater
  2. TPM 1.2 or greater – Required, no chance of automation without this.
  3. Lenovo\Dell\any big name box systems with remote Bios manageability – Not required, but useful
    • “Physical Presence for Provisioning” is Disabled – In Bios\firmware
    • CSM\Legacy Bios

Background:

BitLocker is a free encryption feature in Windows that comes standard on most versions of Windows (specific requirements listed above). BitLocker allows for the encryption of drives on the system, as a layer of security.

With traditionally unencrypted disks (the vast majority of the world’s computers), perpetrators could extract all of the data available on the local disk. This can be done by simply docking the system’s HDD onto another computer to browse the file system. Or by running a live distro of Linux\WinPE where the data would be in clear text.

Not only is the local data on an unencrypted disk at risk, but other sensitive data like password hashes could also be recovered and used for other malicious purposes.

Therefore, drive encryption is an integral part of good security. With encryption in place, hackers would have to work extra hard to disarm the encryption, in order to recover any useful information.

The problem with enabling BitLocker, or any other security feature, is that it poses a significant burden on administrators in terms of: manageability, reliability, and required knowledge. Therefore, there is a large barrier to entry for most admins who do not have time or the skills to manage BitLocker, even if the environment supports it.

In this article, I piece together fragmented information from across the web to describe a truly zero touch, transparent encryption deployment. It is remotely administrable with full cradle-to-grave life-cycle manageability. This is without having to implement MBAM, or any third party products. The only requirements are those listed above, at the beginning of this article.

With all of that said, this form of implementation is the least secure available. There won’t be a pin code for users to remember, there won’t be a usb key required at logon, it will be 100% transparent as far as users are concerned. Therefore, no multi-factor authentication.

Instead, the goal is to provide “better than nothing” encryption, which is far superior to leaving the disks in clear text. And because the process is completely automated, there are no significant costs to this implementation, besides the initial costs of setting up the policies\scripts. This is enforceable onto to as many systems as supported. And can be integrated into pre-existing workflow\ task sequences via script.

Therefore, if you meet the requirements (and have the time) you should implement this.

Vocabulary:

TPM

The “Trusted Protection Module” is a microchip that comes built-into some laptops and desktops ordered today. It provides a way of creating and encrypting keys that could be used for BitLocker and for other security related features. With TPM & BitLocker, the system would automatically decrypt the PC on startup, without requiring the use of a pin, usb, or other form of authentication.

Owner Password

When TPM is enabled, an Owner Password is used to authenticate God-like rights over the chip. This password can be auto generated and stored. But in recent editions of Windows, it is auto generated and tossed. More information on this later.

FVEK

The “Full Volume Encryption Key” is a key used by BitLocker to encrypt the entire C: drive. The FVEK is stored in metadata which itself is encrypt by the VMK, explained below.

VMK

The “Volume Master Key” unlocks the FVEK, which in turn decrypts the C: drive. This is automatically generated and managed by BitLocker.

The VMK itself is further encrypted by “Key Protectors”. Knowledge of the VMK and FVEK is not necessary for BitLocker implementation, but knowledge of the key protectors is required (as discussed below).

Key Protectors

A key protector is yet another key that protects the VMK, which in turn protects the FVEK, which in turn protects the data. The key protector comes in many forms:

a. A USB drive could be configured as a so-called “key protector”. When this is done, that flash drive has to be plugged into the pc at boot up in order to unlock the drive and boot the system.

b. A passcode (whether short or long, numerical, alphabetical, or alphanumerical) could be used as a protector. When this is in place as a key protector, the end user must supply the passcode at each boot

c. A Recovery Key can be created and stored in Active Directory. This is a must, for data recovery in an emergency. -This is needed.

d. Finally, the TPM may be used to protect the FVEK. When this is used, no information is required on the part of the user. The system automatically decrypts the drive at boot up. – This is needed.

Furthermore, you may use any combination of these encryption methods together, in order to further strengthen security. But a multi-factor authentication approach must be manually configured, so it is not a zero touch deployment and is out of scope of this article.

Active Directory Functional Level

When preparing a zero touch deployment of BitLocker, you must first consider how the recovery information will be stored. By default, BitLocker will not backup a recovery key. It’s very important to keep a copy of the recovery key for each pc.

The recovery key will grant you access to the HDD in an offline\out-of-band scenario, it will also unlock the drive if recovery mode has been triggered. Microsoft allows these keys to be stored in Active Directory. To do this requires Windows Server 2008 domain functional level or greater.

There should be a tab in Active Directory Users & Computers under each computer object. The BitLocker Recovery tab will list all of the recovery keys available per machine. Each key is assigned a GUID and timestamp to better identify the key of interest.

Detailed info this is available here: https://technet.microsoft.com/en-us/library/dd875529(v=ws.10).aspx

Machines with TPM Installed and Enabled

TPM is a requirement for zero touch BitLocker deployments. Without TPM, a user would need to setup a pin code, usb, or combination of both to access the machine on boot up. TPM allows the computer to automatically boot into Windows without any user interaction at all. This works because TPM uses some type of hardware level encryption to store the BitLocker keys. TPM checks the computer at startup for signs of corruption\compromise. If the PC passes the tests (PCR settings) then Windows is automatically unlocked. At this point, the weakest link in your security would be the minimum complexity requirements for user account passwords on the computer. This is less secure than a multi-factor authentication, requiring a pin or usb at startup, but TPM provides unparalleled convenience.

The Trusted Protection Module is a chip, and so it is something that either comes with the machine or not. You can check the machines in your environment for the existence and enablement of TPM by running this WMI query in PowerShell:

(Get-WmiObject win32_tpm -Namespace root\cimv2\Security\MicrosoftTPM).isenabled() | Select-Object -ExpandProperty IsEnabled

WMI Filter:

Select * from win32_tpm Where IsEnabled_Initialvalue='True'

NOTE: It’s possible that the TPM value changes after the WMI object is instantiated. So running the IsEnabled() method would give a more up-to-date result. But the IsEnabled_InitialValue should suffice under normal circumstances.

It’s best to purchase machines with the TPM Enabled out of the box, less work for you. If the machine(s) require some type of configuration for TPM, follow directions provided by the manufacturer, which may entail manual configuration. A lot of newer machines come with TPM pre-enabled in the Bios\firmware.

Group Policy

There’s a myriad of different policies available for BitLocker. How BitLocker behaves in your environment is dependent upon the settings configured here. For decent security and zero touch consider the following settings:

Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption:

  1. Choose drive encryption method and cipher strength – AES 256-bit
  2. Store BitLocker recovery information in Active Directory Domain – Enabled
  3. Services (Windows Server 2008 and Windows Vista): Require BitLocker backup to AD DS – Enabled
  4. Select BitLocker recovery information to store – Everything (Recovery passwords and key packages)

Create a GPO with these settings and put it in an OU containing the target PCs. These settings must be applied prior to enabling BitLocker. These settings are pretty safe and have no adverse effects if applied to all machines.

PCR Settings

This is actually a setting that would be enforced via group policy or registry. But I am going to dedicate an entire section solely to this configuration, because this is where most of your time should be spent testing\configuring. The goal here is to avoid triggering Recovery Mode under normal use scenarios.

PCR stands for platform configuration register. Broadly speaking, the PCR settings configured for BitLocker establish the required integrity checks that a booting machine must pass prior to releasing keys stored in TPM (think FVEK, VMK, etc…). This is supposed protect against tampering or hacking attempts. If the machine passes these checks, the TPM will release a set of keys usable by BitLocker to unlock the OS.

In practice, when the integrity checks fail, the machine will enter the dreaded BitLocker Recovery Mode. In this state, the machine requires manual intervention by someone to either reboot it or input the recovery password and continue the boot process.

The PCR stores a signature of the boot configuration and system state at the time of encryption. For example, the Bios version, Bios settings, the boot configuration, the MBR state, BCD settings, DEP settings, etc. All of these environmental conditions are noted by the computer at the time of encryption and are considered to be the trusted state of the machine. After a machine has been encrypted, if something as simple as the boot order changes (even if using F12 on the fly) the Recovery Mode is triggered and the Recovery Password must be applied in order to continue the boot process. Once the Recovery password is entered in, the boot configuration state calculated during that last boot attempt becomes the new benchmark\trusted set of PCRs. So, future boots with the new Bios\environmental settings should no longer trigger the Recovery Mode.

As you can imagine this would be very difficult to deal with, if a fleet of machines were remotely configured to change one of these sensitive settings. Every machine would require manual intervention by a technician that is physically present.

To avoid this nightmare scenario to begin with, I suggest changing the default PCR settings for the TPM. In Group Policy, there are settings to limit the type of PCRs required for TPM to release the keys.

These settings are found in the ADMX template for BitLocker:

Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for Bios-based firmware configurations

The listed PCR indices are as follows:

PCR 0: Core Root of Trust Measurement (CRTM), Bios and Platform Extensions

This PCR is the most important as it is the core root of trust and establishes the validity of all other PCRs. If possible, this should be left on.

PCR1: Host Platform Configuration

This PCR detects unauthorized changes to Bios configuration. This includes things as SMBios structures, CMOS data, passwords, etc… By default, this is not used by BitLocker. You may consider using this with a Bios password implemented to further protect the machine from tampering. Furthermore, if Bios passwords are not used in your environment, this integrity check could be sufficient for your Bios security requirements. As the machine would refuse to boot the OS if the Bios had been changed by any means. So, a perpetrator could examine the Bios, but could not tamper with it expecting to boot into Windows.

In terms of life cycle management, you must remember to suspend BitLocker encryption on machines that have this PCR as a requirement, whenever a change to the Bios is made. This would include all settings in the Bios and actual Bios firmware upgrades. If you do not suspend BitLocker prior to performing any of the above changes, you will trigger recovery mode. Bitlocker can be suspended remotely by use of a simple command in a script, while the machine is loaded in Windows, more on that later.

PCR 2, 3: Option ROM Code

This PCR checks any option ROMs for change.

PCR 4 & 5: IPL Code and Configuration Data

These are responsible for checking the initial program loader code. This measures the handoff from the Bios to the OS. This PCR is the most difficult to deal with, as it creates a digest for the boot device on each boot. If the digest does not match what was last measured, then you’ve failed the integrity check. In practice, this makes a mixed environment with various boot methods\PXE booting options highly prone to accidental Recovery Mode. I suggest you do not use this, as the pros of enabling these 2 PCRs are heavily outweighed by the proliferation of recovery mode occurrences across the board. But there are security implications to be considered when disabling this as with any other PCR.

PCR 6: Measures Power State Transitions

I didn’t bother with enabling\testing this, as this is not among the default enabled PCRs recommended by Microsoft. Furthermore, if a machine fails to resume from any of the sleep states for any reason, there could be a chain of trust violation, i.e. Recovery Mode.

PCR 8: NTFS Boot Sector

This helps to validate the OS initialization code. This protects against rootkits and Trojans.

PCR 9: NTFS Boot Block

This PCR ensures that the NTFS boot block has not been tampered with.

PCR 10: Boot Manager

This PCR ensures that the Operating System boot has not been tampered with.

PCR 11: BitLocker Access Control

This is required to enable BitLocker with TPM.

By default, Bitlocker automatically selects and uses: PCRs: 0, 2, 4, 5, 8, 9, 10 and 11. But in my experience, the 2, 4, & 5 PCRs are too problematic in some complex environments. For example, by having 2, 4, & 5 selected, you are exposing yourself to the possibility of triggering Recovery Mode over something as mundane as escaping a usb boot attempt on startup.

What’s worse is the case where a machine successfully PXE boots to a PXE boot server on startup during the time of encryption. From there on after, the machine requires that the PXE boot server provide the PXE boot menu on every startup, in order to unlock the OS. If there is a network problem of any kind: a bad wire, unplugged Ethernet cable, problems with the switch, the NIC, or if the server goes down, or changes are made to the boot menu; all the machines that were configured to startup on that server will fail to boot. This could be a widespread issue. A DOS attack could be as simple as overloading the TFTP\PXE server in order to bring the entire BitLocker enabled network down.

So like all things security related, you must weigh the pros and cons. In my tests with Lenovo systems, it is best to use: 0, 1, 8, 9, 10, & 11 if the goal is to have a zero touch config. With this configuration, Recovery Mode will almost never be triggered by accident.

In my tests, the Recovery Mode would only be triggered when:

  1. The Bios on the machine is updated, or any of the settings have been changed.
  2. The system wide DEP/BCD settings are changed.
  3. Any Hardware changes – Not including docking stations, but this varies per manufacturer and must be tested.

Other than that, Recovery Mode is not a concern. You must read in-depth articles on the pros\cons of enabling\disabling each of these PCR requirements.

Final note is that these settings are not transferable to UEFI firmwares. These have their own PCR indices, with their own meaning. However, the same principle applies.

https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf

Useful commands

In order to roll out BitLocker in an automated fashion, scripts must be used. I will list useful commands in both CMD and PowerShell:

Partition HDD for BitLocker

Before BitLocker can be enabled, the HDD has to be partitioned appropriately. You can run the useful BdeHdcfg.exe tool to automatically configure partition on the drive for BitLocker.

CMD: BdeHdCfg.exe -target %SystemDrive% shrink -quiet –restart

 

Create a recovery key (for emergency access only, stored in AD):

CMD: manage-bde.exe -protectors -add c: -recoverypassword

PS: Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -RecoveryPasswordProtector

Create the TPM key (used to auto boot encrypted OS):

CMD: manage-bde.exe -protectors -add %SystemDrive% -tpm

PS: Add-BitLockerKeyProtector -MountPoint $env:SystemDrive –TpmProtector

Enable BitLocker Encryption

CMD: manage-bde.exe -on %systemdrive%

PS: Enable-BitLocker -MountPoint $env:SystemDrive

Encryption begins after a reboot. During this boot, the PCRs kick in and creates a digest of the environmental conditions during that boot. Once the OS boots encryption starts, you could continue to use the PC as normal. It would continue encrypting in the background until complete, even after multiple reboots\sleeps\shutdowns.

All of the commands listed above should be implemented in full scripts, where prerequisites like the TPM state are checked prior to pulling the trigger on encryption. Sample scripts will be provided later on.

Check Status

To remotely (or locally) check on the status of encryption on a machine, you may use manage-bde command on its own or with psexec.

CMD: Manage-bde –status –cn %computername%

Suspension

To suspend BitLocker, run the following command in PowerShell. This makes the machine behave as though it were not encrypted at all, for a maximum number of reboots. This is to be used prior to making any changes to the Bios, boot process, HW changes, or BCD\DEP settings.

PS: Suspend-BitLocker -MountPoint C: -RebootCount 2

You may verify suspension by looking at the C drive icon, or using the status flag on manage-bde.exe.

 Life Cycle Management

Provisioning:

  1. Run the same deployment tools you had previously to install Windows.
  2. Post Install, place the machine in an OU containing the GPO settings for BitLocker.
  3. Add the machine to the appropriate groups for the BitLocker provisioning scripts to run.
    • All of of the above should be automated via EMS, WMI filters, Group Membership, item level-targeting etc…

The sample scripts for #3:

Partition System Drive for BitLocker & Reboot

$TPM = Get-WmiObject win32_tpm -Namespace root\cimv2\security\microsofttpm | where {$_.IsEnabled().Isenabled -eq 'True'} -ErrorAction SilentlyContinue
$WindowsVer = Get-WmiObject -Query 'select * from Win32_OperatingSystem where (Version like "6.2%" or Version like "6.3%" or Version like "10.0%") and ProductType = "1"' -ErrorAction SilentlyContinue
$SystemDriveBitLockerRDY = Get-BitLockerVolume -MountPoint $env:SystemDrive -ErrorAction SilentlyContinue

if ($WindowsVer -and $tpm -and !$SystemDriveBitLockerRDY) {
    Get-Service -Name defragsvc -ErrorAction SilentlyContinue | Set-Service -Status Running -ErrorAction SilentlyContinue
    BdeHdCfg -target $env:SystemDrive shrink -quiet
    Restart-Computer}

Create TPM Protector, Create Recovery Key,  Enable BitLocker, Backup Recovery Key to AD:

$TPM = Get-WmiObject win32_tpm -Namespace root\cimv2\security\microsofttpm | where {$_.IsEnabled().Isenabled -eq 'True'} -ErrorAction SilentlyContinue
$WindowsVer = Get-WmiObject -Query 'select * from Win32_OperatingSystem where (Version like "6.2%" or Version like "6.3%" or Version like "10.0%") and ProductType = "1"' -ErrorAction SilentlyContinue
$BitLockerReadyDrive = Get-BitLockerVolume -MountPoint $env:SystemDrive -ErrorAction SilentlyContinue

 
#If all of the above prequisites are met, then create the key protectors, then enable BitLocker and backup the Recovery key to AD.
if ($WindowsVer -and $TPM -and $BitLockerReadyDrive) {
 
#Creating the recovery key
Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -RecoveryPasswordProtector
 
#Adding TPM key
Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -TpmProtector
sleep -Seconds 15 #This is to give sufficient time for the protectors to fully take effect.
 
#Enabling Encryption
Start-Process 'manage-bde.exe' -ArgumentList " -on $env:SystemDrive -em aes256" -Verb runas -Wait
 
#Getting Recovery Key GUID
$RecoveryKeyGUID = (Get-BitLockerVolume -MountPoint $env:SystemDrive).keyprotector | where {$_.Keyprotectortype -eq 'RecoveryPassword'} | Select-Object -ExpandProperty KeyProtectorID
 
#Backing up the Recovery to AD.
manage-bde.exe  -protectors $env:SystemDrive -adbackup -id $RecoveryKeyGUID
 
#Restarting the computer, to begin the encryption process
Restart-Computer}

Troubleshooting Machines:

Suspend BitLocker prior to any Hardware/BCD/DEP/ or Bios changes. This can be done remotely for x number of reboots using Mange-BDE.exe as mentioned earlier.

The Script\Command you need is this:

PS: Suspend-BitLocker -MountPoint C: -RebootCount 2

 

Re-imaging previously imaged\provisioned machines:

Follow the same steps for provisioning. Windows will re-provision the TPM automatically. You may redeploy and re-enable BitLocker N times with impunity, it seems. Only consequence of this is that the AD computer object will continue to keep record of the recovery keys through time, though not a big deal and may actually be desirable.

Recovering from Recovery Mode:

If ever Recovery Mode is triggered, you have two choices:

  1. Undo the changes that caused it.
  2. Go to AD Computer Object, get the recovery key with the latest timestamp, and use it to manually unlock the system.

Decommissioning Machines:

If the TPM on a machine only contains the randomly generated keys used for BitLocker (which is the default), then it is typically safe enough to merely format the C drive with One pass zero write (or even a simple format).

Caveats

When the TPM is initialized in Windows, the Owner password is generated, then tossed.  There is no record of it unless the machine is pre-configured to back up the Owner PW to MBAM or AD (which requires a Schema change). Another option would be to back up the Owner Password to the registry of the local machine. Because the machine would get encrypted, it is *theoretically safe*.

Best practice is to NOT do any of this, and leave it as default, allowing the password to be randomly generated then deleted, not knowing what it is.

From my tests, the TPM chip gets re-owned upon reinstallation of Windows. When Windows is installed, the TPM chip is recognized and automatically provisioned for use. This goes against what is commonly said online; that once a TPM chip has an owner, no software or user is capable of claiming ownership outside of manually resetting the chip to factory defaults.

To test this, I used the Get-TPM cmdlet to make note of the SHA-1 hash of a manually configured owner password. From there, Windows is redeployed to auto provision the TPM. Once installed, Get-TPM is used again to verify the hash. If the hash changes, then the owner password is not the same between installs. Thus, the TPM has been re-owned.

Results revealed that not only is the password not the same between installs, but that the OwnerAuth attribute\object does not contain any value upon auto-re-provisioning. I do not know if this is to be expected or not, but makes sense given how Windows keeps no record of the owner pw upon initial provision. Which means that software, in this case Windows, CAN take ownership of a previously configured TPM chip.

The Trusted Computer Group’s Spec sheet for TPM 1.2 Says:

Clearing the TPM is the process of returning the TPM to factory defaults. It is possible the platform owner will change when in this state.

The commands to clear a TPM require either TPM Owner authentication or the assertion of physical presence.

The TPM_ForceClear must only be possible when the issuer has physical access to the

platform. The manufacturer of a platform determines the exact definition of physical access.

The commands to clear a TPM require either TPM Owner authentication, TPM_OwnerClear,

or the assertion of physical presence, TPM_ForceClear.

TPM and platform manufacturers will determine the actual implementation approach. The strength of the protection mechanisms is determined by an evaluation of the platform.

For more information – https://trustedcomputinggroup.org/wp-content/uploads/mainP1DPrev103.pdf

Based on my findings in Windows, a new owner is set and so previous information has to be cleared upon installation of Windows. This could be caused by one of the following conditions:

  1. The manufacturer (In this case, Lenovo) considers the installation and configuration of Windows as “physical access” and “Clearing the TPM” prior to taking ownership is part of Windows’ TPM provisioning process.
  1. Provisioning the TPM does NOT require “Physical access” and “Clearing the TPM” prior to taking ownership is part of Windows’ TPM provisioning process.

I believe that I am experiencing condition number 2, as the systems I am dealing with comes with the following TCG Bios settings pre-configured:

“Physical Presence for Provisioning” is Disabled

“Physical Presence for Clear” is Enabled

Condition #2 is fine by me. Whether or not these settings are available is completely dependent upon TPM version, and manufacturer. The Bios settings should be remotely administrable in WMI. Anyone with more\better\accurate information on this is welcome.

End result is that you may re-image a BitLocked system as much as you want, and allow Windows to auto provision the TPM and subsequently BitLocker. You don’t have to actively manage this.

Security Implications\Countermeasures

Windows OS Security Matters

Implement least-privileges policy across the board if not done already, and require complex AD passwords. Configure a software firewall to your best ability. Have an antivirus active scanning agent on the OS. Also, run EMET to defend against zero days. Finally, run SCM on the image to further reduce attack surface.

Basically do best practices to harden Windows as much as possible via GPO or any EMS. Because, although the machine is encrypted, it will still boot to the Windows login screen automatically.

Owner Password (if stored in registry of local machine):

An attacker could allow the machine to auto decrypt and boot to the login screen. From there, the machine could be given network access, where exploits could be used to gain remote registry access over SMB\RPC. With the Owner Password stored in the registry, the attacker could use it to gain access to the encrypted drive.

A countermeasure for this would be to leave the owner password as default: Allow Windows to auto generate a complex password and delete it. Do not store it.

Implement a Lockout Policy

To protect the machine from brute force attacks on cached domain credentials, implement a lockout policy on BitLocker. If the system detects a brute force attempt, the machine is put into Recovery Mode

https://technet.microsoft.com/en-us/library/jj966264(v=ws.11).aspx

Direct Memory Access Attacks

This is harder to defend against. DMA can be done once the machine is running, or sleeping. What this means is that a tool can be used to read the contents in memory where the FVEK could be floating around somewhere.

This is less of an issue for modern systems, especially mobile systems, that do not even have DMA ports available.

But to protect against this:

  1. Upgrade to Windows 10, as I could not find any point and shoot scripts that are proven to work for 10 as there are for 8.1 & 7.
  2. Disable the SBP-2 driver in the BitLocker GPO. https://support.microsoft.com/en-us/kb/2516445
  3. Force machines to hibernate rather than sleep. As the contents in memory are saved to disk during S4, therefore encrypted. I do not know if the PCRs I selected would prevent DMA when detected on startup or not. This requires more testing.
  4. Implement multi-factor encryption. Not zero touch.
  5. Implement EMET:

The BDESVC.dll is run under the svchost process. Protecting the svchost process with as many mitigation techniques as possible in EMET may help. While I have no clue as to the efficacy of using EMET under this scenario, the idea of memory randomization and obfuscation sounds like it could be useful to break hard coded DMA scripts. Anyone with more info on this is welcome.

Conclusion

Once implemented, this is a truly automated config that you do not have to actively manage. And you will enjoy better security as a result. Comment below with any additional knowledge\suggestions.


Script(s) Mentioned in This Post:

Enable BitLocker (https://adameyob.com/scripts/create-tpm-protector-create-recovery-key-and-enable-bitlocker/)

Partition Disk for BitLocker (https://adameyob.com/scripts/partition-system-drive-for-bitlocker/)


 


Subscribe
Notify of

53 Comments
Inline Feedbacks
View all comments

First off great post on the Zero-touch bitlocker deployment. I really wished I would have found that earlier. didn’t select PCR 2. Do you know of any vulnerabilities for not checking that part? Reason asking is I am currently deploying bitlocker and we have Thunderbolt docks. If a user boots a pc off the dock, it requests a bitlocker. It sees undocking as a hardware change. I found your fix but I haven’t found any documentation on what opens as in vulnerabilities.

Thanks and love the post,

John Mintz

Thanks for this post! It was the missing piece I needed. I’m using UEFI but the scripts still worked after a tweak.

On the first, the variable $LogFile is not defined before it is used.

On the 2nd script the variable $SystemDriveBitLockerRDY is evaluated on line 7 but the actual variable is $BitLockerReadyDrive in this script.

fanatastic work! thank you!

Few questions left:

1. Why do you enable the HDD-Defrag-Service in your first script?

Get-Service -Name defragsvc -ErrorAction SilentlyContinue | Set-Service -Status Running -ErrorAction SilentlyContinue

2. Is this necessary for SSDs?

All PCs we purchase in future will have SSDs…

Thanks, Oliver

What a great post. Thank you for sharing. Microsoft should hire you to write this article and post it in their official site. I have deployed BitLocker with a 3rd party app (BeachHead) and MBAM now, and you pointed out bits of info I was not fully aware of, that are really important.

Hi Adam, Great post on deploying Bitlocker. I am currently using your enable Bitlocker script as a logon script to automate the process. Had to modify the script as Oliver mentioned by correcting incorrect variable to $BitLockerReadyDrive. However, as the script is working as a logon script it creates log on\restart loop as the current script doesn’t have any way to check that Bitlocker is being deployed so it keeps running the script and restarting after a successful network boot. I’m trying to find a way to add a variable that it checks to see if Bitlocker has already been… Read more »

Thanks for your answer and suggestions Adam. Yes, is probably not ideal to run the Bitlocker script at logon and it is best to do it while building the machines at the start using MDT but I’ve got quite a few Windows 10 devices deployed without encryption which I would like to capture remotely. I had a look at the Run once reg key suggestion but eventually I came up with a different solution: I modified the script to do a check for a 4th variable, a text file called bitlocker.txt in C drive. If this is missing the script… Read more »

What about updating this line?
if ($WindowsVer -and $TPM -and $BitLockerReadyDrive.VolumeStatus -eq “FullyDecrypted”) {

Hello Alejandro,
could you please share your script with me … I liked how you solved the problem

Trying to use this to enable/deploy bitlocker in my environment. I was able to get the powershell script to output that it backed up the Recovery Key in AD. However I do not see it in our AD for the device in question. Any ideas?

We are running 2008 R2.

Yes, I just verified in Domain and Trusts that the Funtional level is Windows Server 2008 R2.

I think you may be right about running the script as a localsystem account though. I will try that.

Thanks for putting all this together in one place, the scripts should prove useful. Just testing on a couple of laptops – on one I manually cleared the TPM using the MMC console but the other just used the script. However on the scripted machine the TPM information says this: “TPM is ready for use with reduced functionality Information Flags 0x100 The TPM owner authorization is not properly stored in the registry” This seems to be tied into the “Caveats” section at the end of your article so is it expected to see this message and safely ignore it provided… Read more »

Hi Adam, great work ;) I found that OS reinstall, don’t clearing TPM Owner Info. Powershell command “Initialize-Tpm -AllowClear $true” and reboot does. Question from me is: Is there possibility to insert AD user credentials to your script ?

Just wanted to say thanks for posting this up. It was a massive assistance to me getting it working at my site, just on the off-chance its useful to someone else. This was how I ended up going about it as we have Azure Active Directory and needed to throw the recovery keys into the cloud. # Generate Encryption Key Protectors Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -RecoveryPasswordProtector Add-BitLockerKeyProtector -MountPoint $env:SystemDrive –TpmProtector Sleep -Seconds 15 # Enable BitLocker # (NOTE: using aes256 instead of xts_aes256 DIDN’T WORK) Manage-bde.exe -on C: -em xts_aes256 # Pull recovery key and add to AAD $RecoveryKeyGUID = (Get-BitLockerVolume… Read more »

I found I needed to add this registry entry before Backup-BitlockerKeyProtector saving the key to AD to get this to work:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]
“ActiveDirectoryBackup”=dword:00000001

There are several other entries in FVE but the ActiveDirectoryBackup allowed the other power shell scripts to work.
So
Step 1:
#Enable BitLocker Drive Encryption
Enable-BitLocker -MountPoint $env:SystemDrive -TpmProtector -UsedSpaceOnly -SkipHardwareTest
Add-BitlockerKeyProtector -MountPoint $env:SystemDrive -RecoveryPasswordProtector
While ((Get-BitLockerVolume -MountPoint $env:SystemDrive).VolumeStatus -eq “EncryptionInProgress”) {
sleep -m 1000
}

step 2 add the above registry entry

step 3:
# Backup the bitlockerkey protector with this command:
Backup-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId (Get-BitLockerVolume -MountPoint $env:SystemDrive).KeyProtector[1].KeyProtectorId

Thanks for this great article.

Hi SIr,

I’ve try your powershell script and it’s success only one time for each machine.

When I turned off the bitlocker and apply the 2nd script one more time it always failed and show the error after reboot.

The error message is “Bitlocker could not be enabled, The bitlocker encryption key cannot be obtained. verify that the trusted platform module is enabled and ownership has been taken”

It’s strange as I can still enabled the bitlocker through its console and of course TPM is enabled in the bios with UEFI + secure boot.

I see. Thanks a lot for your explanation.

First of all. Thanks for all the work. Best article on Bitlocker IMHO. I’m trying to find out a way to test the script in different scenarios hopefully ending up with all machines encrypted even though they weren’t from the beginning. I’m having the same bit of problem like itsarapong simply because testing is done on one PC but I’m deleting the old keys so I thought I was in the clear. It seems to work if I run the script manually or line by line but when runnning via GPO it doesn’t work. After it’s supposed to work I… Read more »

I have used two different methos, the first was “manage-bde” and the second was “remove-bitlockerkeyprotector”. I’m having a similar setup myself though I’m not reloading/reinstalling Windows each time that would take a lot of time unless I had a VM with a restorepoint but then I would need a virtual TPM setup which I haven’t gone into. Bitlocker never actually gets to encrypt anything because of the missing TPM keyprotector but of course it would try and start when I did some of this manually where I afterwards would decrypt the harddrive again by either removing the keys or doing… Read more »

This is super helpful, thanks for taking the time to write this up! We already have BitLocker integrated into our SCCM task sequence and have been running fine for a few years. The issue we are struggling with now is that we’d like end users to change their PIN when deploying a new laptop to them, but have it prompt the USER instead of relying on the user to remember to go in to Control Panel and change their PIN. Something similar to the Active Directory functionality of “User must change password at next logon” but for BItLocker – if… Read more »

Today i found this excellent article and want to thank you for this.
I have only one question – why some modern laptop (that comes with Win10 Pro pre-installed) doesn’t need any drive preparation with scripts, but PC (with TPM, of course) with same Win10 need to run scripts before? Are they already prepared from factory?

Hi!!

Thanks for helping us with this deployment.

It really worked for me and now i´m trying to deploy it to my domain workstations.
Does it have some way to automatize this script, once it only works at the first time.

If i did a logon script it got error because its already applied. The GPO´s setting worked properly.

Any ideas?

This article is great thank you for taking the time to put it together. I’m trying to get past an error that keeps popping up after the restart which essentially nullifies the process. I run the script with PDQ, when the PC restarts and I log in I get “Bitlocker Encryption Cannot Be Enabled. Please make sure TPM is enabled and Ownership Has Been Taken.” Now obvious things being obvious, I check tpm.msc and TPM status is set to ready. TPMAutoProvisioning is enabled as well. If I just use the Manage Bitlocker option built into Win10, everything works like it’s… Read more »

This post is awesome! Before we roll it out, I had one question. We have a lot of remote users, and in your experience have you ever heard of anyone having issues connecting when they’re offsite and not actually connected to the local network of the domain.

Thanks

I’m guessing if they are not connected to the VPN, they will not be able to login to your computer. Correct?

Thanks for the lengthy and detailed post! I am really new to BitLocker deployments so this has been really helpful. I am working on a zero touch deployment to about 1500 devices. They are all Dell devices. So far I’ve been able to enable & activate TPM on older devices via a Pdq with Dell Command configure “C:\Program Files (x86)\Dell\Command Configure\X86_64\cctk.exe” –tpm=on –valsetuppwd=XXXXXX “C:\Program Files (x86)\Dell\Command Configure\X86_64\cctk.exe” –valsetuppwd=XXXXXX –tpmactivation=activate Our inventory system can report which devices have TPM enabled and active. In other words, Tpm activation is confirmed prior to bitlocker deployment. Then I’m Enabling BitLocker: manage-bde.exe -on C: -RecoveryPassword… Read more »

Now that its 4 years later, UEFI is pretty normal and BIOS is pretty much not used anymore in my environment. Are you willing to edit or make a comment on which of the UEFI PCR’s are necessary? I plan on using 0,8,9,10,11 for the bios machines. I need to be able to change the firmware and bios settings. Another thing, when you are shrinking the drive (which i have seen mentioned elsewhere, that you need a special partition) is that necessary? My OS install has a 500mb EFI system partition on it, all machines in the company with windows… Read more »

Thank you for this post, it’s a good job. I just have a question, do we have to execute the two scripts on the users’ computers and the Bitlocker recovery key appears in the AD or do we have to execute the scripts on the server?
For my part I launched the scripts on my computer but I do not have a recovery key that appears in the AD.
Help please!

I’m working to push this out via GPO and on my initial tests it worked fine. Now I’m seeing that some computers work while others fail with an error “Bitlocker could not be enabled. the bitlocker encryption key cannot be obtained. verify that the Trusted Platform Module (TPM) is enabled and ownership has been taken”. I put a “Pause” in the script and after running manage-bde.exe -protectors -add %SystemDrive% -tpm I get an error saying “a required privilege is not held by the client.”

Any help would be great I can’t seem to find a solution to this anywhere.

Make sure not to have legacy bios with tpm 2.0 as your prerequisites because you will find your bitlocker recovery screen in a loop every time the computer boots.

Adam, Chandu here. Nice article and very detailed. As most of users are working from home due to COVID-19, the IT team prefer to set a common PIN and distribute to users. The problem we have is BItlocker is not enabled at all on all laptops and we are not sure whether all laptops have TPM enabled. To minimize complexity, I am thinking to have GPO to enable bitlocker PIN without TPM for all laptop and enforce. However, the question I have is, can we set and enforce a common PIN for users and distribute the PIN to them for… Read more »

Hello! Colleagues will join this question and add a little of my own. I want to use $ Comp = $ env: COMPUTERNAME $ PIN = Get-Random -Minimum 1000000 -maximum 99999999 | ConvertTo-SecureString -AsPlainText -Force $ PIN | Out-file \\ hpsim \ data \ $ Comp.txt to randomly generate a PIN and save it in a shared folder and then transfer it to the user. Can the script be modified to completely exclude the user from the process of his work? In order for the script to be launched by the GPO when the user connects, the backup key is… Read more »

Great article, I couldnt have achieved anything without it, just a small question, so after setting up everything will this only work for computers that have the TPM chip right? it wont work for computers that doesn’t have?

Thanks Adam for sharing this. I’m testing BitLocker GPO our laptops, all Win 10 Pro with SSD drives. I don’t use scripts, only GPO settings, on Dell Latitude 5400 laptops encryption starts automatically after I run gpupdate /force command but on HP EliteBook 840 G5 laptops it only works when I start BitLocker manually. PowerShell is disabled in our domain, I only have access to PDQ or PsExec. Is there a way I could start BitLocker using manage-bde tool on remote hosts? I’m encrypting only the OS drives and need to encrypt about 500 laptops. Thanks!