deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-17 19:33:37 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

restart re-org

Browse Source
This commit is contained in:
Justin Hall
2018-02-01 09:55:37 -08:00
parent 01c6963b9d
commit 897162ef2b
640 changed files with 2802 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

254
windows/security/information-protection/bitlocker/bcd-settings-and-bitlocker.md Normal file
View File

@ -0,0 +1,254 @@
---
title: BCD settings and BitLocker (Windows 10)
description: This topic for IT professionals describes the BCD settings that are used by BitLocker.
ms.assetid: c4ab7ac9-16dc-4c7e-b061-c0b0deb2c4fa
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 08/21/2017
---
# BCD settings and BitLocker
**Applies to**
- Windows 10
This topic for IT professionals describes the BCD settings that are used by BitLocker.
When protecting data at rest on an operating system volume, during the boot process BitLocker verifies that the security sensitive boot configuration data (BCD) settings have not changed since BitLocker was last enabled, resumed, or recovered.
## BitLocker and BCD Settings
In Windows 7 and Windows Server 2008 R2, BitLocker validated nearly all BCD settings with the winload, winresume, and memtest prefixes. However, this high degree of validation caused BitLocker to go into recovery mode for benign setting changes, for example, when applying a language pack BitLocker would enter recovery.
In Windows 8, Windows Server 2012, and later operating systems BitLocker narrows the set of BCD settings validated to reduce the chance of benign changes causing a BCD validation problem. If you believe that there is a risk in excluding a particular BCD setting from the validation profile, you can increase BCD validation coverage to suit your validation preferences. Alternatively, if a default BCD setting is persistently triggering recovery for benign changes, then you can exclude that BCD setting from the validation profile.
### When secure boot is enabled
Computers with UEFI firmware can use Secure Boot to provide enhanced boot security. When BitLocker is able to use Secure Boot for platform and BCD integrity validation, as defined by the **Allow Secure Boot for integrity validation** group policy setting, the **Use enhanced Boot Configuration Data validation profile** group policy is ignored.
One of the benefits of using Secure Boot is that it can correct BCD settings during boot without triggering recovery events. Secure Boot enforces the same BCD settings as BitLocker. Secure Boot BCD enforcement is not configurable from within the operating system.
## Customizing BCD validation settings
To modify the BCD settings BitLocker validates the IT Pro will add or exclude BCD settings from the platform validation profile by enabling and configuring the **Use enhanced Boot Configuration Data validation profile** Group Policy setting.
For the purposes of BitLocker validation, BCD settings are associated with a specific set of Microsoft boot applications. BCD settings are either associated with a specific boot application or can apply to all boot applications by associating a prefix to the BCD setting entered in the Group Policy setting. Prefix values include:
- winload
- winresume
- memtest
- all
All BCD settings are specified by combining the prefix value with either a hexadecimal (hex) value or a “friendly name.”
The BCD setting hex value is reported when BitLocker enters recovery mode and is stored in the event log (event ID 523). The hex value uniquely identifies which BCD setting caused the recovery event.
You can quickly obtain the friendly name for the BCD settings on your computer by using the command “`bcdedit.exe /enum all`”.
Not all BCD settings have friendly names, for those settings the hex value is the only way to configure an exclusion policy.
When specifying BCD values in the **Use enhanced Boot Configuration Data validation profile** Group Policy setting, use the following syntax:
- Prefix the setting with the boot application prefix
- Append a colon ‘:’
- Append either the hex value or the friendly name
- If entering more than one BCD setting, you will need to enter each BCD setting on a new line
For example, either “`winload:hypervisordebugport`” or “`winload:0x250000f4`” yield the same value.
Setting that applies to all boot applications may be applied only to an individual application, however the reverse is not true. For example, one can specify either: “`all:locale`” or “`winresume:locale`”, but as the bcd setting “`win-pe`” does not apply to all boot applications, “`winload:winpe`” is valid, but “`all:winpe`” is not valid. The setting that controls boot debugging (“`bootdebug`” or 0x16000010) will always be validated and will have no effect if it is included in the provided fields.
> **Note:**  Take care when configuring BCD entries in the Group Policy setting. The Local Group Policy Editor does not validate the correctness of the BCD entry. BitLocker will fail to be enabled if the Group Policy setting specified is invalid.
 
### Default BCD validation profile
The following table contains the default BCD validation profile used by BitLocker in Windows 8, Windows Server 2012, and later operating systems:
| Hex Value | Prefix | Friendly Name |
| - | - | - |
| 0x11000001 | all | device|
| 0x12000002 | all | path|
| 0x12000030 | all | loadoptions|
| 0x16000010 | all | bootdebug|
| 0x16000040 | all | advancedoptions|
| 0x16000041 | all| optionsedit|
| 0x16000048| all| nointegritychecks|
| 0x16000049| all| testsigning|
| 0x16000060| all| isolatedcontext|
| 0x1600007b| all| forcefipscrypto|
| 0x22000002| winload| systemroot|
| 0x22000011| winload| kernel|
| 0x22000012| winload| hal|
| 0x22000053| winload| evstore|
| 0x25000020| winload| nx|
| 0x25000052| winload| restrictapiccluster|
| 0x26000022| winload| winpe|
| 0x26000025 |winload|lastknowngood|
| 0x26000081| winload| safebootalternateshell|
| 0x260000a0| winload| debug|
| 0x260000f2| winload| hypervisordebug|
| 0x26000116| winload| hypervisorusevapic|
| 0x21000001| winresume| filedevice|
| 0x22000002| winresume| filepath|
| 0x26000006| winresume| debugoptionenabled|
### Full list of friendly names for ignored BCD settings
This following is a full list of BCD settings with friendly names which are ignored by default. These settings are not part of the default BitLocker validation profile, but can be added if you see a need to validate any of these settings before allowing a BitLocker–protected operating system drive to be unlocked.
> **Note:**  Additional BCD settings exist that have hex values but do not have friendly names. These settings are not included in this list.
 
| Hex Value | Prefix | Friendly Name |
| - | - | - |
| 0x12000004 | all| description|
| 0x12000005| all| locale|
| 0x12000016| all| targetname|
| 0x12000019| all| busparams|
| 0x1200001d| all| key|
| 0x1200004a| all| fontpath|
| 0x14000006| all| inherit|
| 0x14000008| all| recoverysequence|
| 0x15000007| all| truncatememory|
| 0x1500000c| all| firstmegabytepolicy|
| 0x1500000d| all| relocatephysical|
| 0x1500000e| all| avoidlowmemory|
| 0x15000011| all| debugtype|
| 0x15000012 |all|debugaddress|
| 0x15000013| all| debugport|
| 0x15000014|all|baudrate|
| 0x15000015 | all| channel|
| 0x15000018 | all| debugstart|
| 0x1500001a | all| hostip|
| 0x1500001b | all| port|
| 0x15000022 | all| emsport|
| 0x15000023 | all| emsbaudrate|
| 0x15000042 | all| keyringaddress|
| 0x15000047 | all| configaccesspolicy|
| 0x1500004b | all| integrityservices|
| 0x1500004c | all| volumebandid|
| 0x15000051 | all| initialconsoleinput|
| 0x15000052 | all| graphicsresolution|
| 0x15000065 | all| displaymessage|
| 0x15000066 | all| displaymessageoverride|
| 0x15000081 | all| logcontrol|
| 0x16000009 | all| recoveryenabled|
| 0x1600000b | all| badmemoryaccess|
| 0x1600000f | all| traditionalkseg|
| 0x16000017 | all| noumex|
| 0x1600001c | all| dhcp|
| 0x1600001e | all| vm|
| 0x16000020 | all| bootems|
| 0x16000046 | all| graphicsmodedisabled|
| 0x16000050 | all| extendedinput|
| 0x16000053 | all| restartonfailure|
| 0x16000054 | all| highestmode|
| 0x1600006c | all| bootuxdisabled|
| 0x16000072 | all| nokeyboard|
| 0x16000074 | all| bootshutdowndisabled|
| 0x1700000a | all| badmemorylist|
| 0x17000077 | all| allowedinmemorysettings|
| 0x22000040 | all| fverecoveryurl|
| 0x22000041 | all| fverecoverymessage|
| 0x31000003 | all| ramdisksdidevice|
| 0x32000004 | all| ramdisksdipath|
| 0x35000001| all | ramdiskimageoffset|
| 0x35000002 | all| ramdisktftpclientport|
| 0x35000005 | all| ramdiskimagelength|
| 0x35000007 | all| ramdisktftpblocksize|
| 0x35000008 | all| ramdisktftpwindowsize|
| 0x36000006 | all| exportascd|
| 0x36000009 | all| ramdiskmcenabled|
| 0x3600000a | all| ramdiskmctftpfallback|
| 0x3600000b | all| ramdisktftpvarwindow|
| 0x21000001 | winload| osdevice|
| 0x22000013 | winload| dbgtransport|
| 0x220000f9 | winload| hypervisorbusparams|
| 0x22000110 | winload| hypervisorusekey|
| 0x23000003 |winload| resumeobject|
| 0x25000021| winload| pae|
| 0x25000031 |winload| removememory|
| 0x25000032 | winload| increaseuserva|
| 0x25000033 | winload| perfmem|
| 0x25000050 | winload| clustermodeaddressing|
| 0x25000055 | winload| x2apicpolicy|
| 0x25000061 | winload| numproc|
| 0x25000063 | winload| configflags|
| 0x25000066| winload| groupsize|
| 0x25000071 | winload| msi|
| 0x25000072 | winload| pciexpress|
| 0x25000080 | winload| safeboot|
| 0x250000a6 | winload| tscsyncpolicy|
| 0x250000c1| winload| driverloadfailurepolicy|
| 0x250000c2| winload| bootmenupolicy|
| 0x250000e0 |winload| bootstatuspolicy|
| 0x250000f0 | winload| hypervisorlaunchtype|
| 0x250000f3 | winload| hypervisordebugtype|
| 0x250000f4 | winload| hypervisordebugport|
| 0x250000f5 | winload| hypervisorbaudrate|
| 0x250000f6 | winload| hypervisorchannel|
| 0x250000f7 | winload| bootux|
| 0x250000fa | winload| hypervisornumproc|
| 0x250000fb | winload| hypervisorrootprocpernode|
| 0x250000fd | winload| hypervisorhostip|
| 0x250000fe | winload| hypervisorhostport|
| 0x25000100 | winload| tpmbootentropy|
| 0x25000113 | winload| hypervisorrootproc|
| 0x25000115 | winload| hypervisoriommupolicy|
| 0x25000120 | winload| xsavepolicy|
| 0x25000121 | winload| xsaveaddfeature0|
| 0x25000122 | winload| xsaveaddfeature1|
| 0x25000123 | winload| xsaveaddfeature2|
| 0x25000124 | winload| xsaveaddfeature3|
| 0x25000125 | winload| xsaveaddfeature4|
| 0x25000126 | winload| xsaveaddfeature5|
| 0x25000127 | winload| xsaveaddfeature6|
| 0x25000128 | winload| xsaveaddfeature7|
| 0x25000129 | winload| xsaveremovefeature|
| 0x2500012a | winload| xsaveprocessorsmask|
| 0x2500012b | winload| xsavedisable|
| 0x25000130 | winload| claimedtpmcounter|
| 0x26000004 | winload| stampdisks|
| 0x26000010 | winload| detecthal|
| 0x26000024 | winload| nocrashautoreboot|
| 0x26000030 | winload| nolowmem|
| 0x26000040 | winload| vga|
| 0x26000041 | winload| quietboot|
| 0x26000042 | winload| novesa|
| 0x26000043 | winload| novga|
| 0x26000051 | winload| usephysicaldestination|
| 0x26000054 | winload| uselegacyapicmode|
| 0x26000060 | winload| onecpu|
| 0x26000062 | winload| maxproc|
| 0x26000064 | winload| maxgroup|
| 0x26000065 | winload| groupaware|
| 0x26000070| winload| usefirmwarepcisettings|
| 0x26000090 | winload| bootlog|
| 0x26000091 | winload| sos|
| 0x260000a1 | winload| halbreakpoint|
| 0x260000a2 | winload| useplatformclock|
| 0x260000a3 |winload| forcelegacyplatform|
| 0x260000a4 | winload| useplatformtick|
| 0x260000a5 | winload| disabledynamictick|
| 0x260000b0 | winload| ems|
| 0x260000c3 | winload| onetimeadvancedoptions|
| 0x260000c4 | winload| onetimeoptionsedit|
| 0x260000e1| winload| disableelamdrivers|
| 0x260000f8 | winload| hypervisordisableslat|
| 0x260000fc | winload| hypervisoruselargevtlb|
| 0x26000114 | winload| hypervisordhcp|
| 0x21000005 | winresume| associatedosdevice|
| 0x25000007 | winresume| bootux|
| 0x25000008 | winresume| bootmenupolicy|
| 0x26000003| winresume |customsettings|
| 0x26000004 | winresume| pae|
| 0x25000001 | memtest| passcount|
| 0x25000002 | memtest| testmix|
| 0x25000005 | memtest| stridefailcount|
| 0x25000006 | memtest| invcfailcount|
| 0x25000007 | memtest| matsfailcount|
| 0x25000008 | memtest| randfailcount|
| 0x25000009 |memtest| chckrfailcount|
| 0x26000003| memtest| cacheenable|
| 0x26000004 | memtest| failuresenabled|

540
windows/security/information-protection/bitlocker/bitlocker-basic-deployment.md Normal file
View File

@ -0,0 +1,540 @@
---
title: BitLocker basic deployment (Windows 10)
description: This topic for the IT professional explains how BitLocker features can be used to protect your data through drive encryption.
ms.assetid: 97c646cb-9e53-4236-9678-354af41151c4
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 04/19/2017
---
# BitLocker basic deployment
**Applies to**
- Windows 10
This topic for the IT professional explains how BitLocker features can be used to protect your data through drive encryption.
The following sections provide information that will help you put together your basic deployment plan for implementing BitLocker in your organization:
- [Using BitLocker to encrypt volumes](#bkmk-dep1)
- [Down-level compatibility](#bkmk-dep2)
- [Using manage-bde to encrypt volumes with BitLocker](#bkmk-dep3)
- [Using PowerShell to encrypt volumes with BitLocker](#bkmk-dep4)
## <a href="" id="bkmk-dep1"></a>Using BitLocker to encrypt volumes
BitLocker provides full volume encryption (FVE) for operating system volumes, as well as fixed and removable data volumes. To support fully encrypted operating system volumes, BitLocker uses an unencrypted system volume for the files required to boot, decrypt, and load the operating system. This volume is automatically created during a new installation of both client and server operating systems.
In the event that the drive was prepared as a single contiguous space, BitLocker requires a new volume to hold the boot files. BdeHdCfg.exe can create these volumes.
> **Note:**  For more info about using this tool, see [Bdehdcfg](http://technet.microsoft.com/library/ee732026.aspx) in the Command-Line Reference.
 
BitLocker encryption can be done using the following methods:
- BitLocker control panel
- Windows Explorer
- manage-bde command line interface
- BitLocker Windows PowerShell cmdlets
### Encrypting volumes using the BitLocker control panel
Encrypting volumes with the BitLocker control panel (click **Start**, type **bitlocker**, click **Manage BitLocker**) is how many users will utilize BitLocker. The name of the BitLocker control panel is BitLocker Drive Encryption. The BitLocker control panel supports encrypting operating system, fixed data and removable data volumes. The BitLocker control panel will organize available drives in the appropriate category based on how the device reports itself to Windows. Only formatted volumes with assigned drive letters will appear properly in the BitLocker control panel applet.
To start encryption for a volume, select **Turn on BitLocker** for the appropriate drive to initialize the BitLocker Drive Encryption Wizard. BitLocker Drive Encryption Wizard options vary based on volume type (operating system volume or data volume).
### Operating system volume
Upon launch, the BitLocker Drive Encryption Wizard verifies the computer meets the BitLocker system requirements for encrypting an operating system volume. By default, the system requirements are:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Requirement</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Hardware configuration</p></td>
<td align="left"><p>The computer must meet the minimum requirements for the supported Windows versions.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Operating system</p></td>
<td align="left"><p>BitLocker is an optional feature which can be installed by Server Manager on Windows Server 2012 and later.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Hardware TPM</p></td>
<td align="left"><p>TPM version 1.2 or 2.0</p>
<p>A TPM is not required for BitLocker; however, only a computer with a TPM can provide the additional security of pre-startup system integrity verification and multifactor authentication.</p></td>
</tr>
<tr class="even">
<td align="left"><p>BIOS configuration</p></td>
<td align="left"><ul>
<li><p>A Trusted Computing Group (TCG)-compliant BIOS or UEFI firmware.</p></li>
<li><p>The boot order must be set to start first from the hard disk, and not the USB or CD drives.</p></li>
<li><p>The firmware must be able to read from a USB flash drive during startup.</p></li>
</ul></td>
</tr>
<tr class="odd">
<td align="left"><p>File system</p></td>
<td align="left"><p>For computers that boot natively with UEFI firmware, at least one FAT32 partition for the system drive and one NTFS partition for the operating system drive.</p>
<p>For computers with legacy BIOS firmware, at least two NTFS disk partitions, one for the system drive and one for the operating system drive.</p>
<p>For either firmware, the system drive partition must be at least 350 megabytes (MB) and set as the active partition.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Hardware encrypted drive prerequisites (optional)</p></td>
<td align="left"><p>To use a hardware encrypted drive as the boot drive, the drive must be in the uninitialized state and in the security inactive state. In addition, the system must always boot with native UEFI version 2.3.1 or higher and the CSM (if any) disabled.</p></td>
</tr>
</tbody>
</table>
 
Upon passing the initial configuration, users are required to enter a password for the volume. If the volume does not pass the initial configuration for BitLocker, the user is presented with an error dialog describing the appropriate actions to be taken.
Once a strong password has been created for the volume, a recovery key will be generated. The BitLocker Drive Encryption Wizard will prompt for a location to save this key. A BitLocker recovery key is a special key that you can create when you turn on BitLocker Drive Encryption for the first time on each drive that you encrypt. You can use the recovery key to gain access to your computer if the drive that Windows is installed on (the operating system drive) is encrypted using BitLocker Drive Encryption and BitLocker detects a condition that prevents it from unlocking the drive when the computer is starting up. A recovery key can also be used to gain access to your files and folders on a removable data drive (such as an external hard drive or USB flash drive) that is encrypted using BitLocker To Go, if for some reason you forget the password or your computer cannot access the drive.
You should store the recovery key by printing it, saving it on removable media, or saving it as a file in a network folder or on your OneDrive, or on another drive of your computer that you are not encrypting. You cannot save the recovery key to the root directory of a non-removable drive and cannot be stored on the encrypted volume. You cannot save the recovery key for a removable data drive (such as a USB flash drive) on removable media. Ideally, you should store the recovery key separate from your computer. After you create a recovery key, you can use the BitLocker control panel to make additional copies.
When the recovery key has been properly stored, the BitLocker Drive Encryption Wizard will prompt the user to choose how to encrypt the drive. There are two options:
- Encrypt used disk space only - Encrypts only disk space that contains data
- Encrypt entire drive - Encrypts the entire volume including free space
It is recommended that drives with little to no data utilize the **used disk space only** encryption option and that drives with data or an operating system utilize the **encrypt entire drive** option.
> **Note:**  Deleted files appear as free space to the file system, which is not encrypted by **used disk space only**. Until they are wiped or overwritten, deleted files hold information that could be recovered with common data forensic tools.
 
Selecting an encryption type and choosing **Next** will give the user the option of running a BitLocker system check (selected by default) which will ensure that BitLocker can properly access the recovery and encryption keys before the volume encryption begins. It is recommended to run this system check before starting the encryption process. If the system check is not run and a problem is encountered when the operating system attempts to start, the user will need to provide the recovery key to start Windows.
After completing the system check (if selected), the BitLocker Drive Encryption Wizard will restart the computer to begin encryption. Upon reboot, users are required to enter the password chosen to boot into the operating system volume. Users can check encryption status by checking the system notification area or the BitLocker control panel.
Until encryption is completed, the only available options for managing BitLocker involve manipulation of the password protecting the operating system volume, backing up the recovery key, and turning BitLocker off.
### Data volume
Encrypting data volumes using the BitLocker control panel interface works in a similar fashion to encryption of the operating system volumes. Users select **Turn on BitLocker** within the control panel to begin the BitLocker Drive Encryption wizard.
Unlike for operating system volumes, data volumes are not required to pass any configuration tests for the wizard to proceed. Upon launching the wizard, a choice of authentication methods to unlock the drive appears. The available options are **password** and **smart card** and **automatically unlock this drive on this computer**. Disabled by default, the latter option will unlock the data volume without user input when the operating system volume is unlocked.
After selecting the desired authentication method and choosing **Next**, the wizard presents options for storage of the recovery key. These options are the same as for operating system volumes.
With the recovery key saved, selecting **Next** in the wizard will show available options for encryption. These options are the same as for operating system volumes; **used disk space only** and **full drive encryption**. If the volume being encrypted is new or empty, it is recommended that used space only encryption is selected.
With an encryption method chosen, a final confirmation screen displays before beginning the encryption process. Selecting **Start encrypting** will begin encryption.
Encryption status displays in the notification area or within the BitLocker control panel.
### <a href="" id="-onedrive-option-"></a> OneDrive option
There is a new option for storing the BitLocker recovery key using the OneDrive. This option requires that computers are not members of a domain and that the user is using a Microsoft Account. Local accounts do not give the option to utilize OneDrive. Using the OneDrive option is the default, recommended recovery key storage method for computers that are not joined to a domain.
Users can verify the recovery key was saved properly by checking their OneDrive for the BitLocker folder which is created automatically during the save process. The folder will contain two files, a readme.txt and the recovery key. For users storing more than one recovery password on their OneDrive,
they can identify the required recovery key by looking at the file name. The recovery key ID is appended to the end of the file name.
### Using BitLocker within Windows Explorer
Windows Explorer allows users to launch the BitLocker Drive Encryption wizard by right clicking on a volume and selecting **Turn On BitLocker**. This option is available on client computers by default. On servers, you must first install the BitLocker and Desktop-Experience features for this option to be available. After selecting **Turn on BitLocker**, the wizard works exactly as it does when launched using the BitLocker control panel.
## <a href="" id="bkmk-dep2"></a>Down-level compatibility
The following table shows the compatibility matrix for systems that have been BitLocker enabled then presented to a different version of Windows.
Table 1: Cross compatibility for Windows 10, Windows 8.1, Windows 8, and Windows 7 encrypted volumes
<table>
<colgroup>
<col width="25%" />
<col width="25%" />
<col width="25%" />
<col width="25%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p>Encryption Type</p></td>
<td align="left"><p>Windows 10 and Windows 8.1</p></td>
<td align="left"><p>Windows 8</p></td>
<td align="left"><p>Windows 7</p></td>
</tr>
<tr class="even">
<td align="left"><p>Fully encrypted on Windows 8</p></td>
<td align="left"><p>Presents as fully encrypted</p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p>Presented as fully encrypted</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Used Disk Space Only encrypted on Windows 8</p></td>
<td align="left"><p>Presents as encrypt on write</p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p>Presented as fully encrypted</p></td>
</tr>
<tr class="even">
<td align="left"><p>Fully encrypted volume from Windows 7</p></td>
<td align="left"><p>Presents as fully encrypted</p></td>
<td align="left"><p>Presented as fully encrypted</p></td>
<td align="left"><p>N/A</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Partially encrypted volume from Windows 7</p></td>
<td align="left"><p>Windows 10 and Windows 8.1 will complete encryption regardless of policy</p></td>
<td align="left"><p>Windows 8 will complete encryption regardless of policy</p></td>
<td align="left"><p>N/A</p></td>
</tr>
</tbody>
</table>
 
### Encrypting volumes using the manage-bde command line interface
Manage-bde is a command-line utility that can be used for scripting BitLocker operations. Manage-bde offers additional options not displayed in the BitLocker control panel. For a complete list of the options, see [Manage-bde](http://technet.microsoft.com/library/ff829849.aspx).
Manage-bde offers a multitude of wider options for configuring BitLocker. This means that using the command syntax may require care and possibly later customization by the user. For example, using just the `manage-bde -on` command on a data volume will fully encrypt the volume without any authenticating protectors. A volume encrypted in this manner still requires user interaction to turn on BitLocker protection, even though the command successfully completed because an authentication method needs to be added to the volume for it to be fully protected.
Command line users need to determine the appropriate syntax for a given situation. The following section covers general encryption for operating system volumes and data volumes.
### Operating system volume
Listed below are examples of basic valid commands for operating system volumes. In general, using only the `manage-bde -on <drive letter>` command will encrypt the operating system volume with a TPM-only protector and no recovery key. However, many environments require more secure protectors such as passwords or PIN and expect to be able to recover information with a recovery key.
**Determining volume status**
A good practice when using manage-bde is to determine the volume status on the target system. Use the following command to determine volume status:
`manage-bde -status`
This command returns the volumes on the target, current encryption status and volume type (operating system or data) for each volume. Using this information, users can determine the best encryption method for their environment.
**Enabling BitLocker without a TPM**
For example, suppose that you want to enable BitLocker on a computer without a TPM chip. To properly enable BitLocker for the operating system volume, you will need to use a USB flash drive as a startup key to boot (in this example, the drive letter E). You would first create the startup key needed for BitLocker using the –protectors option and save it to the USB drive on E: and then begin the encryption process. You will need to reboot the computer when prompted to complete the encryption process.
``` syntax
manage-bde –protectors -add C: -startupkey E:
manage-bde -on C:
```
**Enabling BitLocker with a TPM only**
It is possible to encrypt the operating system volume without any defined protectors using manage-bde. The command to do this is:
`manage-bde -on C:`
This will encrypt the drive using the TPM as the protector. If a user is unsure of the protector for a volume, they can use the -protectors option in manage-bde to list this information with the command:
`manage-bde -protectors -get <volume>`
**Provisioning BitLocker with two protectors**
Another example is a user on non-TPM hardware who wishes to add a password and SID-based protector to the operating system volume. In this instance, the user adds the protectors first. This is done with the command:
`manage-bde -protectors -add C: -pw -sid <user or group>`
This command will require the user to enter and then confirm the password protector before adding them to the volume. With the protectors enabled on the volume, the user just needs to turn BitLocker on.
### Data volume
Data volumes use the same syntax for encryption as operating system volumes but they do not require protectors for the operation to complete. Encrypting data volumes can be done using the base command: `manage-bde -on <drive letter>` or users can choose to add protectors to the volume. It is recommended that at least one primary protector and a recovery protector be added to a data volume.
**Enabling BitLocker with a password**
A common protector for a data volume is the password protector. In the example below, we add a password protector to the volume and turn BitLocker on.
``` syntax
manage-bde -protectors -add -pw C:
manage-bde -on C:
```
## <a href="" id="bkmk-dep3"></a>Using manage-bde to encrypt volumes with BitLocker
### Encrypting volumes using the BitLocker Windows PowerShell cmdlets
Windows PowerShell cmdlets provide an alternative way to work with BitLocker. Using Windows PowerShell's scripting capabilities, administrators can integrate BitLocker options into existing scripts with ease. The list below displays the available BitLocker cmdlets.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><strong>Name</strong></p></td>
<td align="left"><p><strong>Parameters</strong></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Add-BitLockerKeyProtector</strong></p></td>
<td align="left"><p>-ADAccountOrGroup</p>
<p>-ADAccountOrGroupProtector</p>
<p>-Confirm</p>
<p>-MountPoint</p>
<p>-Password</p>
<p>-PasswordProtector</p>
<p>-Pin</p>
<p>-RecoveryKeyPath</p>
<p>-RecoveryKeyProtector</p>
<p>-RecoveryPassword</p>
<p>-RecoveryPasswordProtector</p>
<p>-Service</p>
<p>-StartupKeyPath</p>
<p>-StartupKeyProtector</p>
<p>-TpmAndPinAndStartupKeyProtector</p>
<p>-TpmAndPinProtector</p>
<p>-TpmAndStartupKeyProtector</p>
<p>-TpmProtector</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Backup-BitLockerKeyProtector</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-KeyProtectorId</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Disable-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Disable-BitLockerAutoUnlock</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Enable-BitLocker</strong></p></td>
<td align="left"><p>-AdAccountOrGroup</p>
<p>-AdAccountOrGroupProtector</p>
<p>-Confirm</p>
<p>-EncryptionMethod</p>
<p>-HardwareEncryption</p>
<p>-Password</p>
<p>-PasswordProtector</p>
<p>-Pin</p>
<p>-RecoveryKeyPath</p>
<p>-RecoveryKeyProtector</p>
<p>-RecoveryPassword</p>
<p>-RecoveryPasswordProtector</p>
<p>-Service</p>
<p>-SkipHardwareTest</p>
<p>-StartupKeyPath</p>
<p>-StartupKeyProtector</p>
<p>-TpmAndPinAndStartupKeyProtector</p>
<p>-TpmAndPinProtector</p>
<p>-TpmAndStartupKeyProtector</p>
<p>-TpmProtector</p>
<p>-UsedSpaceOnly</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Enable-BitLockerAutoUnlock</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Get-BitLockerVolume</strong></p></td>
<td align="left"><p>-MountPoint</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Lock-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-ForceDismount</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Remove-BitLockerKeyProtector</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-KeyProtectorId</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Resume-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Suspend-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-RebootCount</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Unlock-BitLocker</strong></p></td>
<td align="left"><p>-AdAccountOrGroup</p>
<p>-Confirm</p>
<p>-MountPoint</p>
<p>-Password</p>
<p>-RecoveryKeyPath</p>
<p>-RecoveryPassword</p>
<p>-RecoveryPassword</p>
<p>-WhatIf</p></td>
</tr>
</tbody>
</table>
 
Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting prior to running Windows PowerShell cmdlets.
A good initial step is to determine the current state of the volume(s) on the computer. You can do this using the `Get-BitLocker` volume cmdlet. The output from this cmdlet displays information on the volume type, protectors, protection status, and other useful information.
Occasionally, all protectors may not be shown when using **Get-BitLockerVolume** due to lack of space in the output display. If you do not see all of the protectors for a volume, you can use the Windows PowerShell pipe command (|) to format a listing of the protectors.
> **Note:**  In the event that there are more than four protectors for a volume, the pipe command may run out of display space. For volumes with more than four protectors, use the method described in the section below to generate a listing of all protectors with protector ID.
 
`Get-BitLockerVolume C: | fl`
If you wanted to remove the existing protectors prior to provisioning BitLocker on the volume, you can utilize the `Remove-BitLockerKeyProtector` cmdlet. Accomplishing this requires the GUID associated with the protector to be removed.
A simple script can pipe the values of each **Get-BitLockerVolume** return out to another variable as seen below:
``` syntax
$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector
```
Using this, we can display the information in the **$keyprotectors** variable to determine the GUID for each protector.
Using this information, we can then remove the key protector for a specific volume using the command:
``` syntax
Remove-BitLockerKeyProtector <volume>: -KeyProtectorID "{GUID}"
```
> **Note:**  The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure the entire GUID, with braces, is included in the command.
 
### Operating system volume
Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the desired protector as part command for encrypting the volume. Below are examples of common user scenarios and steps to accomplish them using the BitLocker cmdlets for Windows PowerShell.
To enable BitLocker with just the TPM protector. This can be done using the command:
``` syntax
Enable-BitLocker C:
```
The example below adds one additional protector, the StartupKey protectors, and chooses to skip the BitLocker hardware test. In this example, encryption starts immediately without the need for a reboot.
``` syntax
Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath <path> -SkipHardwareTest
```
### Data volume
Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add the desired protectors prior to encrypting the volume. The following example adds a password protector to the E: volume using the variable $pw as the password. The $pw variable is held as a SecureString value to store the user defined password. Last, encryption begins.
``` syntax
$pw = Read-Host -AsSecureString
<user inputs password>
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw
```
### Using a SID based protector in Windows PowerShell
The ADAccountOrGroup protector is an Active Directory SID-based protector. This protector can be added to both operating system and data volumes, although it does not unlock operating system volumes in the pre-boot environment. The protector requires the SID for the domain account or group to link with the protector. BitLocker can protect a cluster-aware disk by adding a SID-based protector for the Cluster Name Object (CNO) that lets the disk properly failover and be unlocked to any member computer of the cluster.
>**Warning:**  The SID-based protector requires the use of an additional protector (such as TPM, PIN, recovery key, etc.) when used on operating system volumes.
 
To add an ADAccountOrGroup protector to a volume requires either the actual domain SID or the group name preceded by the domain and a backslash. In the example below, the CONTOSO\\Administrator account is added as a protector to the data volume G.
``` syntax
Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator
```
For users who wish to use the SID for the account or group, the first step is to determine the SID associated with the account. To get the specific SID for a user account in Windows PowerShell, use the following command:
``` syntax
get-aduser -filter {samaccountname -eq "administrator"}
```
> **Note:**  Use of this command requires the RSAT-AD-PowerShell feature.
 
> **Tip:**  In addition to the Windows PowerShell command above, information about the locally logged on user and group membership can be found using: WHOAMI /ALL. This does not require the use of additional features.
 
In the example below, the user wishes to add a domain SID based protector to the previously encrypted operating system volume. The user knows the SID for the user account or group they wish to add and uses the following command:
``` syntax
Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup "<SID>"
```
> **Note:**  Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.
 
## <a href="" id="bkmk-dep4"></a>Using PowerShell to encrypt volumes with BitLocker
### Checking BitLocker status
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the BitLocker control panel applet, Windows Explorer, manage-bde command line tool, or Windows PowerShell cmdlets. Each option offers different levels of detail and ease of use. We will look at each of the available methods in the following section.
### Checking BitLocker status with the control panel
Checking BitLocker status with the control panel is the most common method used by most users. Once opened, the status for each volume will display next to the volume description and drive letter. Available status return values with the control panel include:
| Status | Description |
| - | - |
| **On**|BitLocker is enabled for the volume |
| **Off**| BitLocker is not enabled for the volume |
| **Suspended** | BitLocker is suspended and not actively protecting the volume |
| **Waiting for Activation**| BitLocker is enabled with a clear protector key and requires further action to be fully protected|
 
If a drive is pre-provisioned with BitLocker, a status of "Waiting for Activation" displays with a yellow exclamation icon on volume E. This status means that there was only a clear protector used when encrypting the volume. In this case, the volume is not in a protected state and needs to have a secure key added to the volume before the drive is fully protected. Administrators can use the control panel, manage-bde tool, or WMI APIs to add an appropriate key protector. Once complete, the control panel will update to reflect the new status.
Using the control panel, administrators can choose **Turn on BitLocker** to start the BitLocker Drive Encryption wizard and add a protector, like PIN for an operating system volume (or password if no TPM exists), or a password or smart card protector to a data volume.
The drive security window displays prior to changing the volume status. Selecting **Activate BitLocker** will complete the encryption process.
Once BitLocker protector activation is completed, the completion notice is displayed.
### Checking BitLocker status with manage-bde
Administrators who prefer a command line interface can utilize manage-bde to check volume status. Manage-bde is capable of returning more information about the volume than the graphical user interface tools in the control panel. For example, manage-bde can display the BitLocker version in use, the encryption type, and the protectors associated with a volume.
To check the status of a volume using manage-bde, use the following command:
``` syntax
manage-bde -status <volume>
```
> **Note:**  If no volume letter is associated with the -status command, all volumes on the computer display their status.
 
### Checking BitLocker status with Windows PowerShell
Windows PowerShell commands offer another way to query BitLocker status for volumes. Like manage-bde, Windows PowerShell includes the advantage of being able to check the status of a volume on a remote computer.
Using the Get-BitLockerVolume cmdlet, each volume on the system will display its current BitLocker status. To get information that is more detailed on a specific volume, use the following command:
``` syntax
Get-BitLockerVolume <volume> -Verbose | fl
```
This command will display information about the encryption method, volume type, key protectors, etc.
### Provisioning BitLocker during operating system deployment
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation Environment. This is done with a randomly generated clear key protector applied to the formatted volume and encrypting the volume prior to running the Windows setup process. If the encryption uses the Used Disk Space Only option described later in this document, this step takes only a few seconds and incorporates well into regular deployment processes.
### Decrypting BitLocker volumes
Decrypting volumes removes BitLocker and any associated protectors from the volumes. Decryption should occur when protection is no longer required. BitLocker decryption should not occur as a troubleshooting step. BitLocker can be removed from a volume using the BitLocker control panel applet, manage-bde, or Windows PowerShell cmdlets. We will discuss each method further below.
### Decrypting volumes using the BitLocker control panel applet
BitLocker decryption using the control panel is done using a Wizard. The control panel can be called from Windows Explorer or by opening the directly. After opening the BitLocker control panel, users will select the Turn off BitLocker option to begin the process.
Once selected, the user chooses to continue by clicking the confirmation dialog. With Turn off BitLocker confirmed, the drive decryption process will begin and report status to the control panel.
The control panel does not report decryption progress but displays it in the notification area of the task bar. Selecting the notification area icon will open a modal dialog with progress.
Once decryption is complete, the drive will update its status in the control panel and is available for encryption.
### Decrypting volumes using the manage-bde command line interface
Decrypting volumes using manage-bde is very straightforward. Decryption with manage-bde offers the advantage of not requiring user confirmation to start the process. Manage-bde uses the -off command to start the decryption process. A sample command for decryption is:
``` syntax
manage-bde -off C:
```
This command disables protectors while it decrypts the volume and removes all protectors when decryption is complete. If a user wishes to check the status of the decryption, they can use the following command:
``` syntax
manage-bde -status C:
```
### Decrypting volumes using the BitLocker Windows PowerShell cmdlets
Decryption with Windows PowerShell cmdlets is straightforward, similar to manage-bde. The additional advantage Windows PowerShell offers is the ability to decrypt multiple drives in one pass. In the example below, the user has three encrypted volumes, which they wish to decrypt.
Using the Disable-BitLocker command, they can remove all protectors and encryption at the same time without the need for additional commands. An example of this command is:
``` syntax
Disable-BitLocker
```
If a user did not want to input each mount point individually, using the `-MountPoint` parameter in an array can sequence the same command into one line without requiring additional user input. An example command is:
``` syntax
Disable-BitLocker -MountPoint E:,F:,G:
```
## See also
- [Prepare your organization for BitLocker: Planning and p\\olicies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
- [BitLocker recovery guide](bitlocker-recovery-guide-plan.md)
- [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
- [BitLocker overview](bitlocker-overview.md)
 
 

143
windows/security/information-protection/bitlocker/bitlocker-countermeasures.md Normal file
View File

@ -0,0 +1,143 @@
---
title: BitLocker Countermeasures (Windows 10)
description: Windows uses technologies including TPM, Secure Boot, Trusted Boot, and Early Launch Antimalware (ELAM) to protect against attacks on the BitLocker encryption key.
ms.assetid: ebdb0637-2597-4da1-bb18-8127964686ea
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 10/27/2017
---
# BitLocker Countermeasures
**Applies to**
- Windows 10
Windows uses technologies including TPM, Secure Boot, Trusted Boot, and Early Launch Antimalware (ELAM) to protect against attacks on the BitLocker encryption key.
BitLocker is part of a strategic approach to securing mobile data through encryption technology. Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software attack tool against it or by transferring the computer’s hard disk to a different computer. Today, BitLocker helps mitigate unauthorized data access on lost or stolen computers before the operating system is started by:
- **Encrypting the hard drives on your computer.** For example, you can turn on BitLocker for your operating system drive, a fixed data drive, or a removable data drive (such as a USB flash drive). Turning on BitLocker for your operating system drive encrypts all system files on the operating system drive, including the swap files and hibernation files.
- **Ensuring the integrity of early boot components and boot configuration data.** On devices that have a TPM version 1.2 or higher, BitLocker uses the enhanced security capabilities of the TPM to help ensure that your data is accessible only if the computer’s boot components appear unaltered and the encrypted disk is located in the original computer.
The sections that follow provide more detailed information about the different technologies that Windows uses to protect against attacks on the BitLocker encryption key in four different boot phases: before startup, during pre-boot, during startup, and finally after startup.
### Protection before startup
Before Windows starts, you must rely on security features implemented as part of the device hardware, including TPM and Secure Boot. Fortunately, many modern computers feature TPM.
#### Trusted Platform Module
Software alone isn’t sufficient to protect a system. After an attacker has compromised software, the software might be unable to detect the compromise. Therefore, a single successful software compromise results in an untrusted system that might never be detected. Hardware, however, is much more difficult to modify.
A TPM is a microchip designed to provide basic security-related functions, primarily involving encryption keys. The TPM is usually installed on the motherboard of a computer and communicates with the rest of the system through a hardware bus. Physically, TPMs are designed to be tamper-proof. If an attacker tries to physically retrieve data directly from the chip, they’ll probably destroy the chip in the process.
By binding the BitLocker encryption key with the TPM and properly configuring the device, it’s nearly impossible for an attacker to gain access to the BitLocker-encrypted data without obtaining an authorized user’s credentials. Therefore, computers with a TPM can provide a high level of protection against attacks that attempt to directly retrieve the BitLocker encryption key.
For more info about TPM, see [Trusted Platform Module](/windows/device-security/tpm/trusted-platform-module-overview).
#### UEFI and Secure Boot
No operating system can protect a device when the operating system is offline. For that reason, Microsoft worked closely with hardware vendors to require firmware-level protection against boot and rootkits that might compromise an encryption solution’s encryption keys.
The UEFI is a programmable boot environment introduced as a replacement for BIOS, which has for the most part remained unchanged for the past 30 years. Like BIOS, PCs start UEFI before any other software; it initializes devices, and UEFI then starts the operating system’s bootloader. As part of its introduction into the pre–operating system environment, UEFI serves a number of purposes, but one of the key benefits is to protect newer devices against a sophisticated type of malware called a bootkit through the use of its Secure Boot feature.
Recent implementations of UEFI (starting with version 2.3.1) can verify the digital signatures of the device’s firmware before running it. Because only the PC’s hardware manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI can prevent firmware-based bootkits. Thus, UEFI is the first link in the chain of trust.
Secure Boot is the foundation of platform and firmware security and was created to enhance security in the pre-boot environment regardless of device architecture. Using signatures to validate the integrity of firmware images before they are allowed to execute, Secure Boot helps reduce the risk of bootloader attacks. The purpose of Secure Boot is to block untrusted firmware and bootloaders (signed or unsigned) from being able to start on the system.
With the legacy BIOS boot process, the pre–operating system environment is vulnerable to attacks by redirecting bootloader handoff to possible malicious loaders. These loaders could remain undetected to operating system and antimalware software. The diagram in Figure 1 contrasts the BIOS and UEFI startup processes.
![the bios and uefi startup processes](images/bitlockerprebootprotection-bios-uefi-startup.jpg)
**Figure 1.** The BIOS and UEFI startup processes
With Secure Boot enabled, UEFI, in coordination with the TPM, can examine the bootloader and determine whether it’s trustworthy. To determine whether the bootloader is trustworthy, UEFI examines the bootloader’s digital signature.
Using the digital signature, UEFI verifies that the bootloader was signed using a trusted certificate.
If the bootloader passes these two tests, UEFI knows that the bootloader isn’t a bootkit and starts it. At this point, Trusted Boot takes over, and the Windows bootloader, using the same cryptographic technologies that UEFI used to verify the bootloader, then verifies that the Windows system files haven’t been changed.
Starting with Windows 8, certified devices must meet several requirements related to UEFI-based Secure Boot:
- They must have Secure Boot enabled by default.
- They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).
- They must allow the user to configure Secure Boot to trust other signed bootloaders.
- Except for Windows RT devices, they must allow the user to completely disable Secure Boot.
These requirements help protect you from rootkits while allowing you to run any operating system you want. You have three options for running non-Microsoft operating systems:
- **Use an operating system with a certified bootloader.** Microsoft can analyze and sign non-Microsoft bootloaders so that they can be trusted. The Linux community is using this process to enable Linux to take advantage of
Secure Boot on Windows-certified devices.
- **Configure UEFI to trust your custom bootloader.** Your device can trust a signed, non-certified bootloader that you specify in the UEFI database, allowing you to run any operating system, including homemade operating systems.
- **Turn off Secure Boot.** You can turn off Secure Boot. This does not help protect you from bootkits, however.
To prevent malware from abusing these options, the user has to manually configure the UEFI firmware to trust a non-certified bootloader or to turn off Secure Boot. Software cannot change the Secure Boot settings.
Any device that doesn’t require Secure Boot or a similar bootloader-verification technology, regardless of the architecture or operating system, is vulnerable to bootkits, which can be used to compromise the encryption solution.
UEFI is secure by design, but it’s critical to protect the Secure Boot configuration by using password protection. In addition, although several well-publicized attacks against UEFI have occurred, they were exploiting faulty UEFI implementations. Those attacks are ineffective when UEFI is implemented properly.
For more information about Secure Boot, refer to [Securing the Windows 8.1 Boot Process](http://technet.microsoft.com/windows/dn168167.aspx).
### Protection during pre-boot: Pre-boot authentication
Pre-boot authentication with BitLocker is a process that requires the use of either a Trusted Platform Module (TPM), user input, such as a PIN, or both, depending on hardware and operating system configuration, to authenticate prior to making the contents of the system drive accessible. In the case of BitLocker, BitLocker encrypts the entire drive, including all system files. BitLocker accesses and stores the encryption key in memory only after a pre-boot authentication is completed using one or more of the following options: Trusted Platform Module (TPM), user provides a specific PIN, USB startup key.
If Windows can’t access the encryption key, the device can’t read or edit the files on the system drive. Even if an attacker takes the disk out of the PC or steals the entire PC, they won’t be able to read or edit the files without the encryption key. The only option for bypassing pre-boot authentication is entering the highly complex, 48-digit recovery key.
The BitLocker pre-boot authentication capability is not specifically designed to prevent the operating system from starting: That’s merely a side effect of how BitLocker protects data confidentiality and system integrity. Pre-boot authentication is designed to prevent the encryption key from being loaded to system memory on devices that are vulnerable to certain types of cold boot attacks. Many modern devices prevent an attacker from easily removing the memory, and Microsoft expects those devices to become even more common in the future.
On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in four ways:
- **TPM-only.** Using TPM-only validation does not require any interaction with the user to decrypt and provide access to the drive. If the TPM validation succeeds, the user logon experience is the same as a standard logon. If the TPM is missing or changed or if the TPM detects changes to critical operating system startup files, BitLocker enters its recovery mode, and the user must enter a recovery password to regain access to the data.
- **TPM with startup key.** In addition to the protection that the TPM provides, part of the encryption key is stored on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed without the startup key.
- **TPM with PIN.** In addition to the protection that the TPM provides, BitLocker requires that the user enter a PIN. Data on the encrypted volume cannot be accessed without entering the PIN.
- **TPM with startup key and PIN.** In addition to the core component protection that the TPM provides, part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM. This configuration provides multifactor authentication so that if the USB key is lost or stolen, it cannot be used for access to the drive, because the correct PIN is also required.
For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the mitigations described in this document cannot be implemented. These mitigations may be inherent to the device or may come by way of configurations that IT can provision to devices and Windows itself.
Although effective, pre-boot authentication is inconvenient to users. In addition, if a user forgets their PIN or loses their startup key, they’re denied access to their data until they can contact their organization’s support team to obtain a recovery key. Today, most new PCs running Windows 10, Windows 8.1, or Windows 8 provide sufficient protection against DMA attacks without requiring pre-boot authentication. For example, most modern PCs include USB port options (which are not vulnerable to DMA attacks) but do not include FireWire or Thunderbolt ports (which are vulnerable to DMA attacks).
BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports, should be configured with pre-boot authentication if they are running Windows 10, Windows 7, Windows 8, or Windows 8.1 and disabling the ports using policy or firmware configuration is not an option. Windows 8.1 and later Modern Standby devices do not need pre-boot authentication to defend against DMA-based port attacks, as the ports will not be present on certified devices. A non-Modern Standby Windows 8.1 and later device requires pre-boot authentication if DMA ports are enabled on the device and additional mitigations described in this document are not implemented. Many customers find that the DMA ports on their devices are never used, and they choose to eliminate the possibility of an attack by disabling the DMA ports themselves, either at the hardware level or through Group Policy.
Many new mobile devices have the system memory soldered to the motherboard, which helps prevent the cold boot–style attack, where the system memory is frozen, removed, and then placed into another device. Those devices, and most PCs, can still be vulnerable when booting to a malicious operating system, however.
You can mitigate the risk of booting to a malicious operating system:
- **Windows 10 (without Secure Boot), Windows 8.1 (without Secure Boot), Windows 8 (without UEFI-based Secure Boot), or Windows 7 (with or without a TPM).** Disable booting from external media, and require a firmware password to prevent the attacker from changing that option.
- **Windows 10, Windows 8.1, or Windows 8 (certified or with Secure Boot).** Password protect the firmware, and do not disable Secure Boot.
### Protection During Startup
During the startup process, Windows 10 uses Trusted Boot and Early Launch Antimalware (ELAM) to examine the integrity of every component. The sections that follow describe these technologies in more detail.
**Trusted Boot**
Trusted Boot takes over where UEFI-based Secure Boot leaves off—during the operating system initialization phase. The bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM driver. If a file has been modified or is not properly signed with a Microsoft signature, Windows detects the problem and refuses to load the corrupted component. Often, Windows can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.
Windows 10 uses Trusted Boot on any hardware platform: It requires neither UEFI nor a TPM. However, without Secure Boot, it’s possible for malware to compromise the startup process prior to Windows starting, at which point Trusted Boot protections could be bypassed or potentially disabled.
**Early Launch Antimalware**
Because UEFI-based Secure Boot has protected the bootloader and Trusted Boot has protected the Windows kernel or other Windows startup components, the next opportunity for malware to start is by infecting a non-Microsoft boot-related driver. Traditional antimalware apps don’t start until after the boot-related drivers have been loaded, giving a rootkit disguised as a driver the opportunity to work.
Early Launch Antimalware (ELAM) is designed to enable the antimalware solution to start before all non-Microsoft drivers and apps. ELAM checks the integrity of non-Microsoft drivers to determine whether the drivers are trustworthy. Because Windows needs to start as fast as possible, ELAM cannot be a complicated process of checking the driver files against known malware signatures. Instead, ELAM has the simple task of examining every boot driver and determining whether it is on the list of trusted drivers. If malware modifies a boot-related driver, ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based rootkits. ELAM also allows the registered antimalware provider to scan drivers that are loaded after the boot process is complete.
Windows Defender in Windows 10 supports ELAM, as do Microsoft System Center 2012 Endpoint Protection and non-Microsoft antimalware apps.
To do this, ELAM loads an antimalware driver before drivers that are flagged as boot-start can be executed. This approach provides the ability for an antimalware driver to register as a trusted boot-critical driver. It is launched during the Trusted Boot process, and with that, Windows ensures that it is loaded before any other non-Microsoft software.
With this solution in place, boot drivers are initialized based on the classification that the ELAM driver returns according to an initialization policy. IT pros have the ability to change this policy through Group Policy.
ELAM classifies drivers as follows:
- **Good.** The driver has been signed and has not been tampered with.
- **Bad.** The driver has been identified as malware. It is recommended that you not allow known bad drivers to be initialized.
- **Bad but required for boot.** The driver has been identified as malware, but the computer cannot successfully boot without loading this driver.
- **Unknown.** This driver has not been attested to by your malware-detection application or classified by the ELAM boot-start driver.
While the features listed above protect the Windows boot process from malware threats that could compromise BitLocker security, it is important to note that DMA ports may be enabled during the window of time between when BitLocker unlocks the drive and Windows boots to the point that Windows can set any port related policies that have been configured. This period of time where the encryption key could be exposed to a DMA attack could be less than a minute on recent devices or longer depending on system performance. The use of pre-boot authentication with a PIN can be used to successfully mitigate against an attack.
### Protection After Startup: eliminate DMA availability
Windows Modern Standby–certified devices do not have DMA ports, eliminating the risk of DMA attacks. On other devices, you can disable FireWire, Thunderbolt, or other ports that support DMA.
## See also
- [Types of Attacks for Volume Encryption Keys](types-of-attacks-for-volume-encryption-keys.md)
- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
- [BitLocker overview](bitlocker-overview.md)

137
windows/security/information-protection/bitlocker/bitlocker-device-encryption-overview-windows-10.md Normal file
View File

@ -0,0 +1,137 @@
---
title: Overview of BitLocker Device Encryption in Windows 10
description: This topic provides an overview of how BitLocker Device Encryption can help protect data on devices running Windows 10.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: Justinha
ms.date: 10/27/2017
---
# Overview of BitLocker Device Encryption in Windows 10
**Applies to**
- Windows 10
This topic explains how BitLocker Device Encryption can help protect data on devices running Windows 10.
For an architectural overview about how BitLocker Device Encryption works with Secure Boot, see [Secure boot and BitLocker Device Encryption overview](https://docs.microsoft.com/windows-hardware/drivers/bringup/secure-boot-and-device-encryption-overview).
For a general overview and list of topics about BitLocker, see [BitLocker](bitlocker-overview.md).
When users travel, their organization’s confidential data goes with them. Wherever confidential data is stored, it must be protected against unauthorized access. Windows has a long history of providing at-rest data-protection solutions that guard against nefarious attackers, beginning with the Encrypting File System in the Windows 2000 operating system. More recently, BitLocker has provided encryption for full drives and portable drives; in Windows 10, BitLocker will even protect individual files, with data loss prevention capabilities. Windows consistently improves data protection by improving existing options and by providing new strategies.
Table 2 lists specific data-protection concerns and how they are addressed in Windows 10 and Windows 7.
**Table 2. Data Protection in Windows 10 and Windows 7**
| Windows 7 | Windows 10 |
|---|---|
| When BitLocker is used with a PIN to protect startup, PCs such as kiosks cannot be restarted remotely. | Modern Windows devices are increasingly protected with BitLocker Device Encryption out of the box and support SSO to seamlessly protect the BitLocker encryption keys from cold boot attacks.<br><br>Network Unlock allows PCs to start automatically when connected to the internal network. |
| Users must contact the IT department to change their BitLocker PIN or password. | Modern Windows devices no longer require a PIN in the pre-boot environment to protect BitLocker encryption keys from cold boot attacks.<br><br>Users who have standard privileges can change their BitLocker PIN or password on legacy devices that require a PIN. |
| When BitLocker is enabled, the provisioning process can take several hours. | BitLocker pre-provisioning, encrypting hard drives, and Used Space Only encryption allow administrators to enable BitLocker quickly on new computers. |
| There is no support for using BitLocker with self-encrypting drives (SEDs). | BitLocker supports offloading encryption to encrypted hard drives. |
| Administrators have to use separate tools to manage encrypted hard drives. | BitLocker supports encrypted hard drives with onboard encryption hardware built in, which allows administrators to use the familiar BitLocker administrative tools to manage them. |
| Encrypting a new flash drive can take more than 20 minutes. | Used Space Only encryption in BitLocker To Go allows users to encrypt drives in seconds. |
| BitLocker could require users to enter a recovery key when system configuration changes occur. | BitLocker requires the user to enter a recovery key only when disk corruption occurs or when he or she loses the PIN or password. |
| Users need to enter a PIN to start the PC, and then their password to sign in to Windows. | Modern Windows devices are increasingly protected with BitLocker Device Encryption out of the box and support SSO to help protect the BitLocker encryption keys from cold boot attacks. |
The sections that follow describe these improvements in more detail. Also see:
- Additional description of improvements in BitLocker: see the [BitLocker](https://technet.microsoft.com/itpro/windows/whats-new/whats-new-windows-10-version-1507-and-1511#bitlocker) section in "What's new in Windows 10, versions 1507 and 1511."
- Introduction and requirements for BitLocker: see [BitLocker](bitlocker-overview.md).
## Prepare for drive and file encryption
The best type of security measures are transparent to the user during implementation and use. Every time there is a possible delay or difficulty because of a security feature, there is strong likelihood that users will try to bypass security. This situation is especially true for data protection, and that’s a scenario that organizations need to avoid.
Whether you’re planning to encrypt entire volumes, removable devices, or individual files, Windows 10 meets your needs by providing streamlined, usable solutions. In fact, you can take several steps in advance to prepare for data encryption and make the deployment quick and smooth.
### TPM pre-provisioning
In Windows 7, preparing the TPM for use offered a couple of challenges:
* You can turn on the TPM in the BIOS, which requires someone to either go into the BIOS settings to turn it on or to install a driver to turn it on from within Windows.
* When you enable the TPM, it may require one or more restarts.
Basically, it was a big hassle. If IT staff were provisioning new PCs, they could handle all of this, but if you wanted to add BitLocker to devices that were already in users’ hands, those users would have struggled with the technical challenges and would either call IT for support or simply leave BitLocker disabled.
Microsoft includes instrumentation in Windows 10 that enables the operating system to fully manage the TPM. There is no need to go into the BIOS, and all scenarios that required a restart have been eliminated.
## Deploy hard drive encryption
BitLocker is capable of encrypting entire hard drives, including both system and data drives. BitLocker pre-provisioning can drastically reduce the time required to provision new PCs with BitLocker enabled. With Windows 10, administrators can turn on BitLocker and the TPM from within the Windows Preinstallation Environment before they install Windows or as part of an automated deployment task sequence without any user interaction. Combined with Used Disk Space Only encryption and a mostly empty drive (because Windows is not yet installed), it takes only a few seconds to enable BitLocker.
With earlier versions of Windows, administrators had to enable BitLocker after Windows had been installed. Although this process could be automated, BitLocker would need to encrypt the entire drive, a process that could take anywhere from several hours to more than a day depending on drive size and performance, which significantly delayed deployment. Microsoft has improved this process through multiple features in Windows 10.
## BitLocker Device Encryption
Beginning in Windows 8.1, Windows automatically enables BitLocker Device Encryption on devices that support Modern Standby. With Windows 10, Microsoft offers BitLocker Device Encryption support on a much broader range of devices, including those that are Modern Standby. Microsoft expects that most devices in the future will pass the testing requirements, which makes BitLocker Device Encryption pervasive across modern Windows devices. BitLocker Device Encryption further protects the system by transparently implementing device-wide data encryption.
Unlike a standard BitLocker implementation, BitLocker Device Encryption is enabled automatically so that the device is always protected. The following list outlines how this happens:
* When a clean installation of Windows 10 is completed and the out-of-box experience is finished, the computer is prepared for first use. As part of this preparation, BitLocker Device Encryption is initialized on the operating system drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker suspended state). In this state, the drive is shown with a warning icon in Windows Explorer. The yellow warning icon is removed after the TPM protector is created and the recovery key is backed up, as explained in the following bullet points.
* If the device is not domain joined, a Microsoft account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key by using his or her Microsoft account credentials.
* If the user uses a domain account to sign in, the clear key is not removed until the user joins the device to a domain and the recovery key is successfully backed up to Active Directory Domain Services (AD DS). You must enable the **Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption\\Operating System Drives** Group Policy setting, and select the **Do not enable BitLocker until recovery information is stored in AD DS for operating system drives** option. With this configuration, the recovery password is created automatically when the computer joins the domain, and then the recovery key is backed up to AD DS, the TPM protector is created, and the clear key is removed.
* Similar to signing in with a domain account, the clear key is removed when the user logs on to an Azure AD account on the device. As described in the bullet point above, the recovery password is created automatically when the user authenticates to Azure AD. Then, the recovery key is backed up to Azure AD, the TPM protector is created, and the clear key is removed.
Microsoft recommends that BitLocker Device Encryption be enabled on any systems that support it, but the automatic BitLocker Device Encryption process can be prevented by changing the following registry setting:
- **Subkey**: HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\BitLocker
- **Value**: PreventDeviceEncryption equal to True (1)
- **Type**: REG\_DWORD
Administrators can manage domain-joined devices that have BitLocker Device Encryption enabled through Microsoft BitLocker Administration and Monitoring (MBAM). In this case, BitLocker Device Encryption automatically makes additional BitLocker options available. No conversion or encryption is required, and MBAM can manage the full BitLocker policy set if any configuration changes are required.
## Used Disk Space Only encryption
BitLocker in earlier Windows versions could take a long time to encrypt a drive, because it encrypted every byte on the volume (including parts that did not have data). That is still the most secure way to encrypt a drive, especially if a drive has previously contained confidential data that has since been moved or deleted, in which case traces of the confidential data could remain on portions of the drive marked as unused.
But why encrypt a new drive when you can simply encrypt the data as it is being written? To reduce encryption time, BitLocker in Windows 10 lets users choose to encrypt just their data. Depending on the amount of data on the drive, this option can reduce encryption time by more than 99 percent.
Exercise caution when encrypting only used space on an existing volume on which confidential data may have already been stored in an unencrypted state, however, because those sectors can be recovered through disk-recovery tools until they are overwritten by new encrypted data. In contrast, encrypting only used space on a brand-new volume can significantly decrease deployment time without the security risk because all new data will be encrypted as it is written to the disk.
## Encrypted hard drive support
SEDs have been available for years, but Microsoft couldn’t support their use with some earlier versions of Windows because the drives lacked important key management features. Microsoft worked with storage vendors to improve the hardware capabilities, and now BitLocker supports the next generation of SEDs, which are called encrypted hard drives.
Encrypted hard drives provide onboard cryptographic capabilities to encrypt data on drives, which improves both drive and system performance by offloading cryptographic calculations from the PC’s processor to the drive itself and rapidly encrypting the drive by using dedicated, purpose-built hardware. If you plan to use whole-drive encryption with Windows 10, Microsoft recommends that you investigate hard drive manufacturers and models to determine whether any of their encrypted hard drives meet your security and budget requirements.
For more information about encrypted hard drives, see [Encrypted Hard Drive](../encrypted-hard-drive.md).
## Preboot information protection
An effective implementation of information protection, like most security controls, considers usability as well as security. Users typically prefer a simple security experience. In fact, the more transparent a security solution becomes, the more likely users are to conform to it.
It is crucial that organizations protect information on their PCs regardless of the state of the computer or the intent of users. This protection should not be cumbersome to users. One undesirable and previously commonplace situation is when the user is prompted for input during preboot, and then again during Windows logon. Challenging users for input more than once should be avoided.
Windows 10 can enable a true SSO experience from the preboot environment on modern devices and in some cases even on older devices when robust information protection configurations are in place. The TPM in isolation is able to securely protect the BitLocker encryption key while it is at rest, and it can securely unlock the operating system drive. When the key is in use and thus in memory, a combination of hardware and Windows capabilities can secure the key and prevent unauthorized access through cold-boot attacks. Although other countermeasures like PIN-based unlock are available, they are not as user-friendly; depending on the devices’ configuration they may not offer additional security when it comes to key protection. For more information, see [BitLocker Countermeasures](bitlocker-countermeasures.md) and [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md).
## Manage passwords and PINs
When BitLocker is enabled on a system drive and the PC has a TPM, you can choose to require that users type a PIN before BitLocker will unlock the drive. Such a PIN requirement can prevent an attacker who has physical access to a PC from even getting to the Windows logon, which makes it virtually impossible for the attacker to access or modify user data and system files.
Requiring a PIN at startup is a useful security feature because it acts as a second authentication factor (a second “something you know”). This configuration comes with some costs, however. One of the most significant is the need to change the PIN regularly. In enterprises that used BitLocker with Windows 7 and the Windows Vista operating system, users had to contact systems administrators to update their BitLocker PIN or password. This requirement not only increased management costs but made users less willing to change their BitLocker PIN or password on a regular basis.
Windows 10 users can update their BitLocker PINs and passwords themselves, without administrator credentials. Not only will this feature reduce support costs, but it could improve security, too, because it encourages users to change their PINs and passwords more often. In addition, Modern Standby devices do not require a PIN for startup: They are designed to start infrequently and have other mitigations in place that further reduce the attack surface of the system.
For more information about how startup security works and the countermeasures that Windows 10 provides, see [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md).
## Configure Network Unlock
Some organizations have location-specific data security requirements. This is most common in environments where high-value data is stored on PCs. The network environment may provide crucial data protection and enforce mandatory authentication; therefore, policy states that those PCs should not leave the building or be disconnected from the corporate network. Safeguards like physical security locks and geofencing may help enforce this policy as reactive controls. Beyond these, a proactive security control that grants data access only when the PC is connected to the corporate network is necessary.
Network Unlock enables BitLocker-protected PCs to start automatically when connected to a wired corporate network on which Windows Deployment Services runs. Anytime the PC is not connected to the corporate network, a user must type a PIN to unlock the drive (if PIN-based unlock is enabled).
Network Unlock requires the following infrastructure:
* Client PCs that have Unified Extensible Firmware Interface (UEFI) firmware version 2.3.1 or later, which supports Dynamic Host Configuration Protocol (DHCP)
* A server running at least Windows Server 2012 with the Windows Deployment Services role
* A server with the DHCP server role installed
For more information about how to configure Network Unlock, see [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md).
## Microsoft BitLocker Administration and Monitoring
Part of the Microsoft Desktop Optimization Pack, MBAM makes it easier to manage and support BitLocker and BitLocker To Go. MBAM 2.5 with Service Pack 1, the latest version, has the following key features:
* Enables administrators to automate the process of encrypting volumes on client computers across the enterprise.
* Enables security officers to quickly determine the compliance state of individual computers or even of the enterprise itself.
* Provides centralized reporting and hardware management with Microsoft System Center Configuration Manager.
* Reduces the workload on the help desk to assist end users with BitLocker recovery requests.
* Enables end users to recover encrypted devices independently by using the Self-Service Portal.
* Enables security officers to easily audit access to recovery key information.
* Empowers Windows Enterprise users to continue working anywhere with the assurance that their corporate data is protected.
* Enforces the BitLocker encryption policy options that you set for your enterprise.
* Integrates with existing management tools, such as System Center Configuration Manager.
* Offers an IT-customizable recovery user experience.
* Supports Windows 10.
For more information about MBAM, including how to obtain it, see [Microsoft BitLocker Administration and Monitoring](https://technet.microsoft.com/windows/hh826072.aspx) on the MDOP TechCenter.

427
windows/security/information-protection/bitlocker/bitlocker-frequently-asked-questions.md Normal file
View File

@ -0,0 +1,427 @@
---
title: BitLocker frequently asked questions (FAQ) (Windows 10)
description: This topic for the IT professional answers frequently asked questions concerning the requirements to use, upgrade, deploy and administer, and key management policies for BitLocker.
ms.assetid: c40f87ac-17d3-47b2-afc6-6c641f72ecee
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
localizationpriority: high
author: brianlic-msft
ms.date: 10/16/2017
---
# BitLocker frequently asked questions (FAQ)
**Applies to**
- Windows 10
This topic for the IT professional answers frequently asked questions concerning the requirements to use, upgrade, deploy and administer, and key management policies for BitLocker.
BitLocker is a data protection feature that encrypts the hard drives on your computer to provide enhanced protection against data theft or exposure on computers and removable drives that are lost or stolen, and more secure data deletion when BitLocker-protected computers are decommissioned as it is much more difficult to recover deleted data from an encrypted drive than from a non-encrypted drive.
- [Overview and requirements](#bkmk-overview)
- [Upgrading](#bkmk-upgrading)
- [Deployment and administration](#bkmk-deploy)
- [Key management](#bkmk-keymanagement)
- [BitLocker To Go](#bkmk-btgsect)
- [Active Directory Domain Services (AD DS)](#bkmk-adds)
- [Security](#bkmk-security)
- [BitLocker Network Unlock](#bkmk-bnusect)
- [Other questions](#bkmk-other)
## <a href="" id="bkmk-overview"></a>Overview and requirements
### <a href="" id="bkmk-whatisbitlocker"></a>How does BitLocker work?
**How BitLocker works with operating system drives**
You can use BitLocker to mitigate unauthorized data access on lost or stolen computers by encrypting all user files and system files on the operating system drive, including the swap files and hibernation files, and checking the integrity of early boot components and boot configuration data.
**How BitLocker works with fixed and removable data drives**
You can use BitLocker to encrypt the entire contents of a data drive. You can use Group Policy to require that BitLocker be enabled on a drive before the computer can write data to the drive. BitLocker can be configured with a variety of unlock methods for data drives, and a data drive supports multiple unlock methods.
### <a href="" id="bkmk-multifactorsupport"></a>Does BitLocker support multifactor authentication?
Yes, BitLocker supports multifactor authentication for operating system drives. If you enable BitLocker on a computer that has a TPM version 1.2 or later, you can use additional forms of authentication with the TPM protection.
### <a href="" id="bkmk-hsrequirements"></a>What are the BitLocker hardware and software requirements?
For requirements, see [System requirements](https://technet.microsoft.com/itpro/windows/keep-secure/bitlocker-overview#system-requirements).
> **Note:**  Dynamic disks are not supported by BitLocker. Dynamic data volumes will not be displayed in the Control Panel. Although the operating system volume will always be displayed in the Control Panel, regardless of whether it is a Dynamic disk, if it is a dynamic disk it is cannot be protected by BitLocker.
 
### <a href="" id="bkmk-partitions"></a>Why are two partitions required? Why does the system drive have to be so large?
Two partitions are required to run BitLocker because pre-startup authentication and system integrity verification must occur on a separate partition from the encrypted operating system drive. This configuration helps protect the operating system and the information in the encrypted drive.
### <a href="" id="bkmk-tpmchipsupport"></a>Which Trusted Platform Modules (TPMs) does BitLocker support?
BitLocker supports TPM version 1.2 or higher.
### <a href="" id="bkmk-havetpm"></a>How can I tell if a TPM is on my computer?
Open the TPM MMC console (tpm.msc) and look under the **Status** heading.
### <a href="" id="bkmk-notpm"></a>Can I use BitLocker on an operating system drive without a TPM?
Yes, you can enable BitLocker on an operating system drive without a TPM version 1.2 or higher, if the BIOS or UEFI firmware has the ability to read from a USB flash drive in the boot environment. This is because BitLocker will not unlock the protected drive until BitLocker's own volume master key is first released by either the computer's TPM or by a USB flash drive containing the BitLocker startup key for that computer. However, computers without TPMs will not be able to use the system integrity verification that BitLocker can also provide.
To help determine whether a computer can read from a USB device during the boot process, use the BitLocker system check as part of the BitLocker setup process. This system check performs tests to confirm that the computer can properly read from the USB devices at the appropriate time and that the computer meets other BitLocker requirements.
### <a href="" id="bkmk-biossupport"></a>How do I obtain BIOS support for the TPM on my computer?
Contact the computer manufacturer to request a Trusted Computing Group (TCG)-compliant BIOS or UEFI boot firmware that meets the following requirements:
- It is compliant with the TCG standards for a client computer.
- It has a secure update mechanism to help prevent a malicious BIOS or boot firmware from being installed on the computer.
### <a href="" id="bkmk-privs"></a>What credentials are required to use BitLocker?
To turn on, turn off, or change configurations of BitLocker on operating system and fixed data drives, membership in the local **Administrators** group is required. Standard users can turn on, turn off, or change configurations of BitLocker on removable data drives.
### <a href="" id="bkmk-bootorder"></a>What is the recommended boot order for computers that are going to be BitLocker-protected?
You should configure the startup options of your computer to have the hard disk drive first in the boot order, before any other drives such ach as CD/DVD drives or USB drives. If the hard disk is not first and you typically boot from hard disk, then a boot order change may be detected or assumed when removable media is found during boot. The boot order typically affects the system measurement that is verified by BitLocker and a change in boot order will cause you to be prompted for your BitLocker recovery key. For the same reason, if you have a laptop with a docking station, ensure that the hard disk drive is first in the boot order both when docked and undocked. 
## <a href="" id="bkmk-upgrading"></a>Upgrading
### <a href="" id="bkmk-upgradev27"></a>Can I upgrade to Windows 10 with BitLocker enabled?
Yes.
### <a href="" id="bkmk-disabledecrypt"></a>What is the difference between suspending and decrypting BitLocker?
**Decrypt** completely removes BitLocker protection and fully decrypts the drive.
**Suspend** keeps the data encrypted but encrypts the BitLocker volume master key with a clear key. The clear key is a cryptographic key stored unencrypted and unprotected on the disk drive. By storing this key unencrypted, the **Suspend** option allows for changes or upgrades to the computer without the time and cost of decrypting and re-encrypting the entire drive. After the changes are made and BitLocker is again enabled, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade, the volume master key is changed, the protectors are updated to match and the clear key is erased.
### <a href="" id="bkmk-decryptfirst"></a>Do I have to decrypt my BitLocker-protected drive to download and install system updates and upgrades?
No user action is required for BitLocker in order to apply updates from Microsoft, including [Windows quality updates and feature updates](https://technet.microsoft.com/itpro/windows/manage/waas-quick-start).
Users need to suspend BitLocker for Non-Microsoft software updates, such as:
- Computer manufacturer firmware updates
- TPM firmware updates
- Non-Microsoft application updates that modify boot components
> **Note:**  If you have suspended BitLocker, you can resume BitLocker protection after you have installed the upgrade or update. Upon resuming protection, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade or update. If these types of upgrades or updates are applied without suspending BitLocker, your computer will enter recovery mode when restarting and will require a recovery key or password to access the computer.
 
## <a href="" id="bkmk-deploy"></a>Deployment and administration
### <a href="" id="bkmk-automate"></a>Can BitLocker deployment be automated in an enterprise environment?
Yes, you can automate the deployment and configuration of BitLocker and the TPM using either WMI or Windows PowerShell scripts. How you choose to implement the scripts depends on your environment. You can also use Manage-bde.exe to locally or remotely configure BitLocker. For more info about writing scripts that use the BitLocker WMI providers, see [BitLocker Drive Encryption Provider](https://go.microsoft.com/fwlink/p/?LinkId=80600). For more info about using Windows PowerShell cmdlets with BitLocker Drive Encryption, see [BitLocker Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj649829.aspx).
### <a href="" id="bkmk-os"></a>Can BitLocker encrypt more than just the operating system drive?
Yes.
### <a href="" id="bkmk-performance"></a>Is there a noticeable performance impact when BitLocker is enabled on a computer?
Generally it imposes a single-digit percentage performance overhead.
### <a href="" id="bkmk-longencrypt"></a>How long will initial encryption take when BitLocker is turned on?
Although BitLocker encryption occurs in the background while you continue to work, and the system remains usable, encryption times vary depending on the type of drive that is being encrypted, the size of the drive, and the speed of the drive. If you are encrypting very large drives, you may want to set encryption to occur during times when you will not be using the drive.
You can also choose whether or not BitLocker should encrypt the entire drive or just the used space on the drive when you turn on BitLocker. On a new hard drive, encrypting just the used spaced can be considerably faster than encrypting the entire drive. When this encryption option is selected, BitLocker automatically encrypts data as it is saved, ensuring that no data is stored unencrypted.
### <a href="" id="bkmk-turnoff"></a>What happens if the computer is turned off during encryption or decryption?
If the computer is turned off or goes into hibernation, the BitLocker encryption and decryption process will resume where it stopped the next time Windows starts. This is true even if the power is suddenly unavailable.
### <a href="" id="bkmk-entiredisk"></a>Does BitLocker encrypt and decrypt the entire drive all at once when reading and writing data?
No, BitLocker does not encrypt and decrypt the entire drive when reading and writing data. The encrypted sectors in the BitLocker-protected drive are decrypted only as they are requested from system read operations. Blocks that are written to the drive are encrypted before the system writes them to the physical disk. No unencrypted data is ever stored on a BitLocker-protected drive.
### <a href="" id="bkmk-dataunencryptpart"></a>How can I prevent users on a network from storing data on an unencrypted drive?
You can can Group Policy settings to require that data drives be BitLocker-protected before a BitLocker-protected computer can write data to them. For more info, see [BitLocker Group Policy settings](bitlocker-group-policy-settings.md).
When these policy settings are enabled, the BitLocker-protected operating system will mount any data drives that are not protected by BitLocker as read-only.
### <a href="" id="bkmk-integrityfail"></a>What system changes would cause the integrity check on my operating system drive to fail?
The following types of system changes can cause an integrity check failure and prevent the TPM from releasing the BitLocker key to decrypt the protected operating system drive:
- Moving the BitLocker-protected drive into a new computer.
- Installing a new motherboard with a new TPM.
- Turning off, disabling, or clearing the TPM.
- Changing any boot configuration settings.
- Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot configuration data.
### <a href="" id="bkmk-examplesosrec"></a>What causes BitLocker to start into recovery mode when attempting to start the operating system drive?
Because BitLocker is designed to protect your computer from numerous attacks, there are numerous reasons why BitLocker could start in recovery mode.
For example:
- Changing the BIOS boot order to boot another drive in advance of the hard drive.
- Adding or removing hardware, such as inserting a new card in the computer, including some PCMIA wireless cards.
- Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
In BitLocker, recovery consists of decrypting a copy of the volume master key using either a recovery key stored on a USB flash drive or a cryptographic key derived from a recovery password.
The TPM is not involved in any recovery scenarios, so recovery is still possible if the TPM fails boot component validation, malfunctions, or is removed.
### <a href="" id="bkmk-driveswap"></a>Can I swap hard disks on the same computer if BitLocker is enabled on the operating system drive?
Yes, you can swap multiple hard disks on the same computer if BitLocker is enabled, but only if the hard disks were BitLocker-protected on the same computer. The BitLocker keys are unique to the TPM and operating system drive, so if you want to prepare a backup operating system or data drive for use in case of disk failure, you need to make sure that they were matched with the correct TPM. You can also configure different hard drives for different operating systems and then enable BitLocker on each one with different authentication methods (such as one with TPM-only and one with TPM+PIN) without any conflicts.
### <a href="" id="bkmk-altpc"></a>Can I access my BitLocker-protected drive if I insert the hard disk into a different computer?
Yes, if the drive is a data drive, you can unlock it from the **BitLocker Drive Encryption** Control Panel item just as you would any other data drive by using a password or smart card. If the data drive was configured for automatic unlock only, you will have to unlock it by using the recovery key. The encrypted hard disk can be unlocked by a data recovery agent (if one was configured) or it can be unlocked by using the recovery key.
### <a href="" id="bkmk-noturnon"></a>Why is "Turn BitLocker on" not available when I right-click a drive?
Some drives cannot be encrypted with BitLocker. Reasons a drive cannot be encrypted include insufficient disk size, an incompatible file system, if the drive is a dynamic disk, or a drive is designated as the system partition. By default, the system drive (or system partition) is hidden from display. However, if it is not created as a hidden drive when the operating system was installed due to a custom installation process, that drive might be displayed but cannot be encrypted.
### <a href="" id="bkmk-r2disks"></a>What type of disk configurations are supported by BitLocker?
Any number of internal, fixed data drives can be protected with BitLocker. On some versions ATA and SATA-based, direct-attached storage devices are also supported.
## <a href="" id="bkmk-keymanagement"></a>Key management
### <a href="" id="bkmk-key"></a>What is the difference between a recovery password, recovery key, PIN, enhanced PIN, and startup key?
For tables that list and describe elements such as a recovery password, recovery key, and PIN, see [BitLocker key protectors](prepare-your-organization-for-bitlocker-planning-and-policies.md#bitlocker-key-protectors) and [BitLocker authentication methods](prepare-your-organization-for-bitlocker-planning-and-policies.md#bitlocker-authentication-methods).
### <a href="" id="bkmk-recoverypass"></a>How can the recovery password and recovery key be stored?
The recovery password and recovery key for an operating system drive or a fixed data drive can be saved to a folder, saved to one or more USB devices, saved to your Microsoft Account, or printed.
For removable data drives, the recovery password and recovery key can be saved to a folder, saved to your Microsoft Account, or printed. By default, you cannot store a recovery key for a removable drive on a removable drive.
A domain administrator can additionally configure Group Policy to automatically generate recovery passwords and store them in Active Directory Domain Services (AD DS) for any BitLocker-protected drive.
### <a href="" id="bkmk-enableauthwodecrypt"></a>Is it possible to add an additional method of authentication without decrypting the drive if I only have the TPM authentication method enabled?
You can use the Manage-bde.exe command-line tool to replace your TPM-only authentication mode with a multifactor authentication mode. For example, if BitLocker is enabled with TPM authentication only and you want to add PIN authentication, use the following commands from an elevated command prompt, replacing *&lt;4-20 digit numeric PIN&gt;* with the numeric PIN you want to use:
`manage-bde –protectors –delete %systemdrive% -type tpm`
`manage-bde –protectors –add %systemdrive% -tpmandpin <4-20 digit numeric PIN>`
### <a href="" id="bkmk-add-auth"></a> When should an additional method of authentication be considered?
New hardware that meets [Windows Hardware Compatibility Program](https://docs.microsoft.com/windows-hardware/design/compatibility/) requirements make a PIN less critical as a mitigation, and having a TPM-only protector is likely sufficient when combined with policies like device lockout. For example, Surface Pro and Surface Book do not have external DMA ports to attack.
For older hardware, where a PIN may be needed, it’s recommended to enable [enhanced PINs](bitlocker-group-policy-settings.md#bkmk-unlockpol2) that allow non-numeric characters such as letters and punctuation marks, and to set the PIN length based on your risk tolerance and the hardware anti-hammering capabilities available to the TPMs in your computers.
### <a href="" id="bkmk-recoveryinfo"></a>If I lose my recovery information, will the BitLocker-protected data be unrecoverable?
BitLocker is designed to make the encrypted drive unrecoverable without the required authentication. When in recovery mode, the user needs the recovery password or recovery key to unlock the encrypted drive.
>**Important:**  Store the recovery information in AD DS, along with your Microsoft Account, or another safe location.
 
### <a href="" id="bkmk-usbdrive"></a>Can the USB flash drive that is used as the startup key also be used to store the recovery key?
While this is technically possible, it is not a best practice to use one USB flash drive to store both keys. If the USB flash drive that contains your startup key is lost or stolen, you also lose access to your recovery key. In addition, inserting this key would cause your computer to automatically boot from the recovery key even if TPM-measured files have changed, which circumvents the TPM's system integrity check.
### <a href="" id="bkmk-startupkey"></a>Can I save the startup key on multiple USB flash drives?
Yes, you can save a computer's startup key on multiple USB flash drives. Right-clicking a BitLocker-protected drive and selecting **Manage BitLocker** will provide you the options to duplicate the recovery keys as needed.
### <a href="" id="bkmk-multikeyoneusb"></a>Can I save multiple (different) startup keys on the same USB flash drive?
Yes, you can save BitLocker startup keys for different computers on the same USB flash drive.
### <a href="" id="bkmk-multikey"></a>Can I generate multiple (different) startup keys for the same computer?
You can generate different startup keys for the same computer through scripting. However, for computers that have a TPM, creating different startup keys prevents BitLocker from using the TPM's system integrity check.
### <a href="" id="bkmk-multipin"></a>Can I generate multiple PIN combinations?
You cannot generate multiple PIN combinations.
### <a href="" id="bkmk-encryptkeys"></a>What encryption keys are used in BitLocker? How do they work together?
Raw data is encrypted with the full volume encryption key, which is then encrypted with the volume master key. The volume master key is in turn encrypted by one of several possible methods depending on your authentication (that is, key protectors or TPM) and recovery scenarios.
### <a href="" id="bkmk-keystorage"></a>Where are the encryption keys stored?
The full volume encryption key is encrypted by the volume master key and stored in the encrypted drive. The volume master key is encrypted by the appropriate key protector and stored in the encrypted drive. If BitLocker has been suspended, the clear key that is used to encrypt the volume master key is also stored in the encrypted drive, along with the encrypted volume master key.
This storage process ensures that the volume master key is never stored unencrypted and is protected unless you disable BitLocker. The keys are also saved to two additional locations on the drive for redundancy. The keys can be read and processed by the boot manager.
### <a href="" id="bkmk-funckey"></a>Why do I have to use the function keys to enter the PIN or the 48-character recovery password?
The F1 through F10 keys are universally mapped scan codes available in the pre-boot environment on all computers and in all languages. The numeric keys 0 through 9 are not usable in the pre-boot environment on all keyboards.
When using an enhanced PIN, users should run the optional system check during the BitLocker setup process to ensure that the PIN can be entered correctly in the pre-boot environment.
### <a href="" id="bkmk-youbrute"></a>How does BitLocker help prevent an attacker from discovering the PIN that unlocks my operating system drive?
It is possible that a personal identification number (PIN) can be discovered by an attacker performing a brute force attack. A brute force attack occurs when an attacker uses an automated tool to try different PIN combinations until the correct one is discovered. For BitLocker-protected computers, this type of attack, also known as a dictionary attack, requires that the attacker have physical access to the computer.
The TPM has the built-in ability to detect and react to these types of attacks. Because different manufacturers' TPMs may support different PIN and attack mitigations, contact your TPM's manufacturer to determine how your computer's TPM mitigates PIN brute force attacks.
After you have determined your TPM's manufacturer, contact the manufacturer to gather the TPM's vendor-specific information. Most manufacturers use the PIN authentication failure count to exponentially increase lockout time to the PIN interface. However, each manufacturer has different policies regarding when and how the failure counter is decreased or reset.
### <a href="" id="bkmk-tpmprov"></a>How can I determine the manufacturer of my TPM?
You can determine your TPM manufacturer in the TPM MMC console (tpm.msc) under the **TPM Manufacturer Information** heading.
### <a href="" id="bkmk-tpmdam"></a>How can I evaluate a TPM's dictionary attack mitigation mechanism?
The following questions can assist you when asking a TPM manufacturer about the design of a dictionary attack mitigation mechanism:
- How many failed authorization attempts can occur before lockout?
- What is the algorithm for determining the duration of a lockout based on the number of failed attempts and any other relevant parameters?
- What actions can cause the failure count and lockout duration to be decreased or reset?
### <a href="" id="bkmk-pinlength"></a>Can PIN length and complexity be managed with Group Policy?
Yes and No. You can configure the minimum personal identification number (PIN) length by using the **Configure minimum PIN length for startup** Group Policy setting and allow the use of alphanumeric PINs by enabling the **Allow enhanced PINs for startup** Group Policy setting. However, you cannot require PIN complexity by Group Policy.
For more info, see [BitLocker Group Policy settings](bitlocker-group-policy-settings.md).
## <a href="" id="bkmk-btgsect"></a>BitLocker To Go
BitLocker To Go is BitLocker Drive Encryption on removable data drives. This includes the encryption of USB flash drives, SD cards, external hard disk drives, and other drives formatted by using the NTFS, FAT16, FAT32, or exFAT file systems.
## <a href="" id="bkmk-adds"></a>Active Directory Domain Services (AD DS)
### What if BitLocker is enabled on a computer before the computer has joined the domain?
If BitLocker is enabled on a drive before Group Policy has been applied to enforce backup, the recovery information will not be automatically backed up to AD DS when the computer joins the domain or when Group Policy is subsequently applied. However, you can use the **Choose how BitLocker-protected operating system drives can be recovered**, **Choose how BitLocker-protected fixed drives can be recovered** and **Choose how BitLocker-protected removable drives can be recovered** Group Policy settings to require that the computer be connected to a domain before BitLocker can be enabled to help ensure that recovery information for BitLocker-protected drives in your organization is backed up to AD DS.
For more info, see [BitLocker Group Policy settings](bitlocker-group-policy-settings.md).
The BitLocker Windows Management Instrumentation (WMI) interface does allow administrators to write a script to back up or synchronize an online client's existing recovery information; however, BitLocker does not automatically manage this process. The manage-bde command-line tool can also be used to manually back up recovery information to AD DS. For example, to back up all of the recovery information for the C: drive to AD DS, you would use the following command from an elevated command prompt: **manage-bde -protectors -adbackup C:**.
>**Important:**  Joining a computer to the domain should be the first step for new computers within an organization. After computers are joined to a domain, storing the BitLocker recovery key to AD DS is automatic (when enabled in Group Policy).
 
### <a href="" id="bkmk-addseventlog"></a>Is there an event log entry recorded on the client computer to indicate the success or failure of the Active Directory backup?
Yes, an event log entry that indicates the success or failure of an Active Directory backup is recorded on the client computer. However, even if an event log entry says "Success," the information could have been subsequently removed from AD DS, or BitLocker could have been reconfigured in such a way that the Active Directory information can no longer unlock the drive (such as by removing the recovery password key protector). In addition, it is also possible that the log entry could be spoofed.
Ultimately, determining whether a legitimate backup exists in AD DS requires querying AD DS with domain administrator credentials by using the BitLocker password viewer tool.
### <a href="" id="bkmk-refresh"></a>If I change the BitLocker recovery password on my computer and store the new password in AD DS, will AD DS overwrite the old password?
No. By design, BitLocker recovery password entries do not get deleted from AD DS; therefore, you might see multiple passwords for each drive. To identify the latest password, check the date on the object.
### <a href="" id="bkmk-adbackupfails"></a>What happens if the backup initially fails? Will BitLocker retry the backup?
If the backup initially fails, such as when a domain controller is unreachable at the time when the BitLocker setup wizard is run, BitLocker does not try again to back up the recovery information to AD DS.
When an administrator selects the **Require BitLocker backup to AD DS** check box of the **Store BitLocker recovery information in Active Directory Domain Service (Windows 2008 and Windows Vista)** policy setting, or the equivalent **Do not enable BitLocker until recovery information is stored in AD DS for (operating system | fixed data | removable data) drives** check box in any of the **Choose how BitLocker-protected operating system drives can be recovered**, **Choose how BitLocker-protected fixed data drives can be recovered**, **Choose how BitLocker-protected removable data drives can be recovered** policy settings, this prevents users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. With these settings configured if the backup fails, BitLocker cannot be enabled, ensuring that administrators will be able to recover BitLocker-protected drives in the organization.
For more info, see [BitLocker Group Policy settings](bitlocker-group-policy-settings.md).
When an administrator clears these check boxes, the administrator is allowing a drive to be BitLocker-protected without having the recovery information successfully backed up to AD DS; however, BitLocker will not automatically retry the backup if it fails. Instead, administrators can create a script for the backup, as described earlier in [What if BitLocker is enabled on a computer before the computer has joined the domain?](#what-if-bitlocker-is-enabled-on-a-computer-before-the-computer-has-joined-the-domain) to capture the information after connectivity is restored.
## <a href="" id="bkmk-security"></a>Security
### <a href="" id="bkmk-form"></a>What form of encryption does BitLocker use? Is it configurable?
BitLocker uses Advanced Encryption Standard (AES) as its encryption algorithm with configurable key lengths of 128 or 256 bits. The default encryption setting is AES-128, but the options are configurable by using Group Policy.
### <a href="" id="bkmk-config"></a>What is the best practice for using BitLocker on an operating system drive?
The recommended practice for BitLocker configuration on an operating system drive is to implement BitLocker on a computer with a TPM version 1.2 or higher and a Trusted Computing Group (TCG)-compliant BIOS or UEFI firmware implementation, plus a PIN. By requiring a PIN that was set by the user in addition to the TPM validation, a malicious user that has physical access to the computer cannot simply start the computer.
### <a href="" id="bkmk-sleep"></a>What are the implications of using the sleep or hibernate power management options?
BitLocker on operating system drives in its basic configuration (with a TPM but without advanced authentication) provides additional security for the hibernate mode. However, BitLocker provides greater security when it is configured to use an advanced authentication mode (TPM+PIN, TPM+USB, or TPM+PIN+USB) with the hibernate mode. This method is more secure because returning from hibernation requires BitLocker authentication. As a best practice, we recommend that sleep mode be disabled and that you use TPM+PIN for the authentication method.
### <a href="" id="bkmk-root"></a>What are the advantages of a TPM?
Most operating systems use a shared memory space and rely on the operating system to manage physical memory. A TPM is a hardware component that uses its own internal firmware and logic circuits for processing instructions, thus shielding it from external software vulnerabilities. Attacking the TPM requires physical access to the computer. Additionally, the tools and skills necessary to attack hardware are often more expensive, and usually are not as available as the ones used to attack software. And because each TPM is unique to the computer that contains it, attacking multiple TPM computers would be difficult and time-consuming.
>**Note:**  Configuring BitLocker with an additional factor of authentication provides even more protection against TPM hardware attacks.
 
## <a href="" id="bkmk-bnusect"></a>BitLocker Network Unlock
BitLocker Network Unlock enables easier management for BitLocker-enabled desktops and servers that use the TPM+PIN protection method in a domain environment. When a computer that is connected to a wired corporate network is rebooted, Network Unlock allows the PIN entry prompt to be bypassed. It automatically unlocks BitLocker-protected operating system volumes by using a trusted key that is provided by the Windows Deployment Services server as its secondary authentication method.
To use Network Unlock you must also have a PIN configured for your computer. When your computer is not connected to the network you will need to provide the PIN to unlock it.
BitLocker Network Unlock has software and hardware requirements for both client computers, Windows Deployment services, and domain controllers that must be met before you can use it.
Network Unlock uses two protectors, the TPM protector and the one provided by the network or by your PIN, whereas automatic unlock uses a single protector, the one stored in the TPM. If the computer is joined to a network without the key protector it will prompt you to enter your PIN. If the PIN is
not available you will need to use the recovery key to unlock the computer if it can ot be connected to the network.
For more info, see [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md).
## <a href="" id="bkmk-other"></a>Other questions
### <a href="" id="bkmk-kernel"></a>Can I run a kernel debugger with BitLocker?
Yes. However, the debugger should be turned on before enabling BitLocker. Turning on the debugger ensures that the correct measurements are calculated when sealing to the TPM, allowing the computer to start properly. If you need to turn debugging on or off when using BitLocker, be sure to suspend BitLocker first to avoid putting your computer into recovery mode.
### <a href="" id="bkmk-errorreports"></a>How does BitLocker handle memory dumps?
BitLocker has a storage driver stack that ensures memory dumps are encrypted when BitLocker is enabled.
### <a href="" id="bkmk-smart"></a>Can BitLocker support smart cards for pre-boot authentication?
BitLocker does not support smart cards for pre-boot authentication. There is no single industry standard for smart card support in the firmware, and most computers either do not implement firmware support for smart cards, or only support specific smart cards and readers. This lack of standardization makes supporting them very difficult.
### <a href="" id="bkmk-driver"></a>Can I use a non-Microsoft TPM driver?
Microsoft does not support non-Microsoft TPM drivers and strongly recommends against using them with BitLocker. Attempting to use a non-Microsoft TPM driver with BitLocker may cause BitLocker to report that a TPM is not present on the computer and not allow the TPM to be used with BitLocker.
### <a href="" id="bkmk-mbr"></a>Can other tools that manage or modify the master boot record work with BitLocker?
We do not recommend modifying the master boot record on computers whose operating system drives are BitLocker-protected for a number of security, reliability, and product support reasons. Changes to the master boot record (MBR) could change the security environment and prevent the computer from starting normally, as well as complicate any efforts to recover from a corrupted MBR. Changes made to the MBR by anything other than Windows might force the computer into recovery mode or prevent it from booting entirely.
### <a href="" id="bkmk-syschkfail"></a>Why is the system check failing when I am encrypting my operating system drive?
The system check is designed to ensure your computer's BIOS or UEFI firmware is compatible with BitLocker and that the TPM is working correctly. The system check can fail for several reasons:
- The computer's BIOS or UEFI firmware cannot read USB flash drives.
- The computer's BIOS, uEFI firmware, or boot menu does not have reading USB flash drives enabled.
- There are multiple USB flash drives inserted into the computer.
- The PIN was not entered correctly.
- The computer's BIOS or UEFI firmware only supports using the function keys (F1–F10) to enter numerals in the pre-boot environment.
- The startup key was removed before the computer finished rebooting.
- The TPM has malfunctioned and fails to unseal the keys.
### <a href="" id="bkmk-usbkeyfail"></a>What can I do if the recovery key on my USB flash drive cannot be read?
Some computers cannot read USB flash drives in the pre-boot environment. First, check your BIOS or UEFI firmware and boot settings to ensure that the use of USB drives is enabled. If it is not enabled, enable the use of USB drives in the BIOS or UEFI firmware and boot settings and then try to read the recovery key from the USB flash drive again. If it still cannot be read, you will have to mount the hard drive as a data drive on another computer so that there is an operating system to attempt to read the recovery key from the USB flash drive. If the USB flash drive has been corrupted or damaged, you may need to supply a recovery password or use the recovery information that was backed up to AD DS. Also, if you are using the recovery key in the pre-boot environment, ensure that the drive is formatted by using the NTFS, FAT16, or FAT32 file system.
### <a href="" id="bkmk-usbkeynosave"></a>Why am I unable to save my recovery key to my USB flash drive?
The **Save to USB** option is not shown by default for removable drives. If the option is unavailable, it means that a system administrator has disallowed the use of recovery keys.
### <a href="" id="bkmk-noautounlock"></a>Why am I unable to automatically unlock my drive?
Automatic unlocking for fixed data drives requires that the operating system drive also be protected by BitLocker. If you are using a computer that does not have a BitLocker-protected operating system drive, the drive cannot be automatically unlocked. For removable data drives, you can add automatic unlocking by right-clicking the drive in Windows Explorer and clicking **Manage BitLocker**. You will still be able to use the password or smart card credentials you supplied when you turned on BitLocker to unlock the removable drive on other computers.
### <a href="" id="bkmk-blsafemode"></a>Can I use BitLocker in Safe Mode?
Limited BitLocker functionality is available in Safe Mode. BitLocker-protected drives can be unlocked and decrypted by using the **BitLocker Drive Encryption** Control Panel item. Right-clicking to access BitLocker options from Windows Explorer is not available in Safe Mode.
### <a href="" id="bkmk-lockdata"></a>How do I "lock" a data drive?
Both fixed and removable data drives can be locked by using the Manage-bde command-line tool and the –lock command.
>**Note:**  Ensure all data is saved to the drive before locking it. Once locked, the drive will become inaccessible.
 
The syntax of this command is:
`manage-bde <driveletter> -lock`
Outside of using this command, data drives will be locked on shutdown and restart of the operating system. A removable data drive will also be locked automatically when the drive is removed from the computer.
### <a href="" id="bkmk-shadowcopy"></a>Can I use BitLocker with the Volume Shadow Copy Service?
Yes. However, shadow copies made prior to enabling BitLocker will be automatically deleted when BitLocker is enabled on software-encrypted drives. If you are using a hardware encrypted drive, the shadow copies are retained.
### <a href="" id="bkmk-vhd"></a>Does BitLocker support virtual hard disks (VHDs)?
BitLocker is not supported on bootable VHDs, but BitLocker is supported on data volume VHDs, such as those used by clusters, if you are running Windows 10, Windows 8.1, Windows 8, Windows Server 2012, or Windows Server 2012 R2.
### <a href="" id="bkmk-VM"></a> Can I use BitLocker with virtual machines (VMs)?
Yes. Password protectors and virtual TPMs can be used with BitLocker to protect virtual machines. VMs can be domain joined, Azure AD-joined, or workplace-joined (in **Settings** under **Accounts** > **Access work or school** > **Connect to work or school** to receive policy. You can enable encryption either while creating the VM or by using other existing management tools such as the BitLocker CSP, or even by using a startup script or logon script delivered by Group Policy. Windows Server 2016 also supports [Shielded VMs and guarded fabric](https://docs.microsoft.com/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node) to protect VMs from malicious administrators.
## More information
- [Prepare your organization for BitLocker: Planning and Policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
- [BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
- [BCD settings and BitLocker](bcd-settings-and-bitlocker.md)
- [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
- [BitLocker: How to deploy on Windows Server 2012](bitlocker-how-to-deploy-on-windows-server.md)
- [BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md)
- [BitLocker: Use BitLocker Recovery Password Viewer](bitlocker-use-bitlocker-recovery-password-viewer.md)
- [BitLocker Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/6f49f904-e04d-4b90-afbc-84bc45d4d30d)

2481
windows/security/information-protection/bitlocker/bitlocker-group-policy-settings.md Normal file
View File

File diff suppressed because it is too large Load Diff

116
windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server.md Normal file
View File

@ -0,0 +1,116 @@
---
title: BitLocker How to deploy on Windows Server 2012 and later (Windows 10)
description: This topic for the IT professional explains how to deploy BitLocker and Windows Server 2012 and later.
ms.assetid: 91c18e9e-6ab4-4607-8c75-d983bbe2542f
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 04/19/2017
---
# BitLocker: How to deploy on Windows Server 2012 and later
**Applies to**
- Windows 10
This topic for the IT professional explains how to deploy BitLocker on Windows Server 2012 and later.
For all Windows Server editions, BitLocker must be installed using Server Manager. However, you can still provision BitLocker before the server operating system is installed as part of your deployment.
## <a href="" id="installing-bitlocker-"></a>Installing BitLocker
BitLocker requires administrator privileges on the server to install. You can install BitLocker either by using Server Manager or Windows PowerShell cmdlets.
- To install BitLocker using Server Manager
- To install BitLocker using Windows PowerShell
### <a href="" id="bkmk-blinstallsrvmgr"></a>To install BitLocker using Server Manager
1. Open Server Manager by selecting the Server Manager icon or running servermanager.exe.
2. Select **Manage** from the **Server Manager Navigation** bar and select **Add Roles and Features** to start the **Add Roles and Features Wizard.**
3. With the **Add Roles and Features Wizard** open, select **Next** at the **Before you begin** pane (if shown).
4. Select **Role-based or feature-based installation** on the **Installation type** pane of the **Add Roles and Features Wizard** pane and select **Next** to continue.
5. Select the **Select a server from the server pool option** in the **Server Selection** pane and confirm the server for the BitLocker feature install.
6. Server roles and features install using the same wizard in Server Manager. Select **Next** on the **Server Roles** pane of the **Add Roles and Features** wizard to proceed to the **Features** pane.
7. Select the check box next to **BitLocker Drive Encryption** within the **Features** pane of the **Add Roles and Features Wizard**. The wizard will show the additional management features available for BitLocker. If you do not want to install these features, deselect the **Include management tools option** and select **Add Features**. Once optional features selection is complete, select **Next** to proceed in the wizard.
> **Note:**   The **Enhanced Storage** feature is a required feature for enabling BitLocker. This feature enables support for Encrypted Hard Drives on capable systems.
 
8. Select **Install** on the **Confirmation** pane of the **Add Roles and Features Wizard** to begin BitLocker feature installation. The BitLocker feature requires a restart to complete. Selecting the **Restart the destination server automatically if required** option in the **Confirmation** pane will force a restart of the computer after installation is complete.
9. If the **Restart the destination server automatically if required** check box is not selected, the **Results pane** of the **Add Roles and Features Wizard** will display the success or failure of the BitLocker feature installation. If required, a notification of additional action necessary to complete the feature installation, such as the restart of the computer, will be displayed in the results text.
### <a href="" id="bkmk-blinstallwps"></a>To install BitLocker using Windows PowerShell
Windows PowerShell offers administrators another option for BitLocker feature installation. Windows PowerShell installs features using the `servermanager` or `dism` module; however, the `servermanager` and `dism` modules do not always share feature name parity. Because of this, it is advisable to confirm the feature or role name prior to installation.
>**Note:**  You must restart the server to complete the installation of BitLocker.
 
### Using the servermanager module to install BitLocker
The `servermanager` Windows PowerShell module can use either the `Install-WindowsFeature` or `Add-WindowsFeature` to install the BitLocker feature. The `Add-WindowsFeature` cmdlet is merely a stub to the `Install-WindowsFeature`. This example uses the `Install-WindowsFeature` cmdlet. The feature name for BitLocker in the `servermanager` module is `BitLocker`. This can be determined using the `Get-WindowsFeature` cmdlet with a query such as:
``` syntax
Get-WindowsFeature Bit
```
The results of this command displays a table of all of the feature names beginning with “Bit” as their prefix. This allows you to confirm that the feature name is `BitLocker` for the BitLocker feature.
By default, installation of features in Windows PowerShell does not include optional sub-features or management tools as part of the install process. This can be seen using the `-WhatIf` option in Windows PowerShell.
``` syntax
Install-WindowsFeature BitLocker -WhatIf
```
The results of this command show that only the BitLocker Drive Encryption feature installs using this command.
To see what would be installed with the BitLocker feature including all available management tools and sub-features, use the following command:
``` syntax
Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -WhatIf | fl
```
The result of this command displays the following list of all the administration tools for BitLocker that would be installed along with the feature, including tools for use with Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS).
- BitLocker Drive Encryption
- BitLocker Drive Encryption Tools
- BitLocker Drive Encryption Administration Utilities
- BitLocker Recovery Password Viewer
- AD DS Snap-Ins and Command-Line Tools
- AD DS Tools
- AD DS and AD LDS Tools
The command to complete a full installation of the BitLocker feature with all available features and then rebooting the server at completion is:
``` syntax
Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart
```
>**Important:**  Installing the BitLocker feature using Windows PowerShell does not install the Enhanced Storage feature. Administrators wishing to support Encrypted Hard Drives in their environment will need to install the Enhanced Storage feature separately.
 
### Using the dism module to install BitLocker
The `dism` Windows PowerShell module uses the `Enable-WindowsOptionalFeature` cmdlet to install features. The BitLocker feature name for BitLocker is `BitLocker`. The `dism` module does not support wildcards when searching for feature names. To list feature names for the `dism` module, use the `Get-WindowsOptionalFeatures` cmdlet. The following command will list all of the optional features in an online (running) operating system.
``` syntax
Get-WindowsOptionalFeature -Online | ft
```
From this output, we can see that there are three BitLocker related optional feature names: BitLocker, BitLocker-Utilities and BitLocker-NetworkUnlock. To install the BitLocker feature, the BitLocker and BitLocker-Utilities features are the only required items.
To install BitLocker using the `dism` module, use the following command:
``` syntax
Enable-WindowsOptionalFeature -Online -FeatureName BitLocker -All
```
This command will prompt the user for a reboot. The Enable-WindowsOptionalFeature cmdlet does not offer support for forcing a reboot of the computer. This command does not include installation of the management tools for BitLocker. For a complete installation of BitLocker and all available management tools, use the following command:
``` syntax
Enable-WindowsOptionalFeature -Online -FeatureName BitLocker, BitLocker-Utilities -All
```
## More information
- [BitLocker overview](bitlocker-overview.md)
- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
- [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)

372
windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md Normal file
View File

@ -0,0 +1,372 @@
---
title: BitLocker How to enable Network Unlock (Windows 10)
description: This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it.
ms.assetid: be45bc28-47db-4931-bfec-3c348151d2e9
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 04/19/2017
---
# BitLocker: How to enable Network Unlock
**Applies to**
- Windows 10
This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it.
Network Unlock was introduced in Windows 8 and Windows Server 2012 as a BitLocker protector option for operating system volumes. Network Unlock enables easier management for BitLocker enabled desktops and servers in a domain environment by providing automatic unlock of operating system volumes at system reboot when connected to a wired corporate network. This feature requires the client hardware to have a DHCP driver implemented in its UEFI firmware.
Without Network Unlock, operating system volumes protected by TPM+PIN protectors require a PIN to be entered when a computer reboots or resumes from hibernation (for example, by Wake on LAN). This can make it difficult to enterprises to roll out software patches to unattended desktops and remotely administered servers.
Network Unlock allows BitLocker-enabled systems with TPM+PIN and that meet the hardware requirements to boot into Windows without user intervention. Network Unlock works in a similar fashion to the TPM+StartupKey at boot. Rather than needing to read the StartupKey from USB media, however, the key for Network Unlock is composed from a key stored in the TPM and an encrypted network key that is sent to the server, decrypted and returned to the client in a secure session.
This topic contains:
- [Network Unlock core requirements](#bkmk-nunlockcorereqs)
- [Network Unlock sequence](#bkmk-networkunlockseq)
- [Configure Network Unlock](#bkmk-configuringnetworkunlock)
- [Create the certificate template for Network Unlock](#bkmk-createcerttmpl)
- [Turning off Network Unlock](#bkmk-turnoffnetworkunlock)
- [Update Network Unlock certificates](#bkmk-updatecerts)
- [Troubleshoot Network Unlock](#bkmk-troubleshoot)
- [Configure Network Unlock on unsupported systems](#bkmk-unsupportedsystems)
## <a href="" id="bkmk-nunlockcorereqs"></a>Network Unlock core requirements
Network Unlock must meet mandatory hardware and software requirements before the feature can automatically unlock domain joined systems. These requirements include:
- You must be running at least Windows 8 or Windows Server 2012.
- Any supported operating system with UEFI DHCP drivers can be Network Unlock clients.
- A server running the Windows Deployment Services (WDS) role on any supported server operating system.
- BitLocker Network Unlock optional feature installed on any supported server operating system.
- A DHCP server, separate from the WDS server.
- Properly configured public/private key pairing.
- Network Unlock Group Policy settings configured.
The network stack must be enabled to use the Network Unlock feature. Equipment manufacturers deliver their products in various states and with different BIOS menus, so you need to confirm that the network stack has been enabled in the BIOS before starting the computer.
>**Note:**  To properly support DHCP within UEFI, the UEFI-based system should be in native mode without a compatibility support module (CSM) enabled.
For Network Unlock to work reliably on computers running Windows 8 and later, the first network adapter on the computer, usually the onboard adapter, must be configured to support DHCP and used for Network Unlock. This is especially worth noting when you have multiple adapters, and you wish to configure one without DHCP, such as for a lights-out management protocol. This configuration is necessary because Network Unlock will stop enumerating adapters when it reaches one with a DHCP port failure for any reason. Thus, if the first enumerated adapter does not support DHCP, is not plugged into the network, or fails to report availability of the DHCP port for any reason, then Network Unlock will fail.
 
The Network Unlock server component installs on supported versions of Windows Server 2012 and later as a Windows feature using Server Manager or Windows PowerShell cmdlets. The feature name is BitLocker Network Unlock in Server Manager and BitLocker-NetworkUnlock in Windows PowerShell. This feature is a core requirement.
Network Unlock requires Windows Deployment Services (WDS) in the environment where the feature will be utilized. Configuration of the WDS installation is not required; however, the WDS service needs to be running on the server.
The network key is stored on the system drive along with an AES 256 session key, and encrypted with the 2048-bit RSA public key of the unlock server's certificate. The network key is decrypted with the help of a provider on a supported version of Windows Server running WDS, and returned encrypted with its corresponding session key.
## <a href="" id="bkmk-networkunlockseq"></a>Network Unlock sequence
The unlock sequence starts on the client side, when the Windows boot manager detects the existence of Network Unlock protector. It leverages the DHCP driver in UEFI to obtain an IP address for IPv4 and then broadcasts a vendor-specific DHCP request that contains the network key and a session key for the reply, all encrypted by the server's Network Unlock certificate, as described above. The Network Unlock provider on the supported WDS server recognizes the vendor-specific request, decrypts it with the RSA private key, and returns the network key encrypted with the session key via its own vendor-specific DHCP reply.
On the server side, the WDS server role has an optional plugin component, like a PXE provider, which is what handles the incoming Network Unlock requests. The provider can also be configured with subnet restrictions, which would require that the IP address provided by the client in the Network Unlock request belong to a permitted subnet in order to release the network key to the client. In instances where the Network Unlock provider is unavailable, BitLocker fails over to the next available protector to unlock the drive. In a typical configuration, this means the standard TPM+PIN unlock screen is presented to unlock the drive.
The server side configuration to enable Network Unlock also requires provisioning a 2048-bit RSA public/private key pair in the form of an X.509 certificate, and for the public key certificate to be distributed to the clients. This certificate must be managed and deployed through the Group Policy editor directly on a domain controller with at least a Domain Functional Level of Windows Server 2012. This certificate is the public key that encrypts the intermediate network key (which is one of the two secrets required to unlock the drive; the other secret is stored in the TPM).
![bitlocker network unlock sequence](images/bitlockernetworkunlocksequence.png)
**Phases in the Network Unlock process**
1. The Windows boot manager detects that a Network Unlock protector exists in the BitLocker configuration.
2. The client computer uses its DHCP driver in the UEFI to obtain a valid IPv4 IP address.
3. The client computer broadcasts a vendor-specific DHCP request that contains the Network Key (a 256-bit intermediate key) and an AES-256 session key for the reply. Both of these keys are encrypted using the 2048-bit RSA Public Key of the Network Unlock certificate from the WDS server.
4. The Network Unlock provider on the WDS server recognizes the vendor-specific request.
5. The provider decrypts it with the WDS server’s BitLocker Network Unlock certificate RSA private key.
6. The WDS provider then returns the network key encrypted with the session key using its own vendor-specific DHCP reply to the client computer. This forms an intermediate key.
7. The returned intermediate key is then combined with another local 256-bit intermediate key that can only be decrypted by the TPM.
8. This combined key is used to create an AES-256 key that unlocks the volume.
9. Windows continues the boot sequence.
## <a href="" id="bkmk-configuringnetworkunlock"></a>Configure Network Unlock
The following steps allow an administrator to configure Network Unlock in a domain where the Domain Functional Level is at least Windows Server 2012.
### <a href="" id="bkmk-stepone"></a>Step One: Install the WDS Server role
The BitLocker Network Unlock feature will install the WDS role if it is not already installed. If you want to install it separately before you install BitLocker Network Unlock you can use Server Manager or Windows PowerShell. To install the role using Server Manager, select the **Windows Deployment Services** role in Server Manager.
To install the role using Windows PowerShell, use the following command:
``` syntax
Install-WindowsFeature WDS-Deployment
```
You must configure the WDS server so that it can communicate with DHCP (and optionally Active Directory Doman Services) and the client computer. You can do using the WDS management tool, wdsmgmt.msc, which starts the Windows Deployment Services Configuration Wizard.
### <a href="" id="bkmk-steptwo"></a>Step Two: Confirm the WDS Service is running
To confirm the WDS service is running, use the Services Management Console or Windows PowerShell. To confirm the service is running in Services Management Console, open the console using **services.msc** and check the status of the Windows Deployment Services service.
To confirm the service is running using Windows PowerShell, use the following command:
``` syntax
Get-Service WDSServer
```
### <a href="" id="bkmk-stepthree"></a>Step Three: Install the Network Unlock feature
To install the Network Unlock feature, use Server Manager or Windows PowerShell. To install the feature using Server Manager, select the **BitLocker Network Unlock** feature in the Server Manager console.
To install the feature using Windows PowerShell, use the following command:
``` syntax
Install-WindowsFeature BitLocker-NetworkUnlock
```
### <a href="" id="bkmk-stepfour"></a>Step Four: Create the Network Unlock certificate
Network Unlock can use imported certificates from an existing PKI infrastructure, or you can use a self-signed certificate.
To enroll a certificate from an existing certification authority (CA), do the following:
1. Open Certificate Manager on the WDS server using **certmgr.msc**
2. Under the Certificates - Current User item, right-click Personal
3. Select All Tasks, then **Request New Certificate**
4. Select **Next** when the Certificate Enrollment wizard opens
5. Select Active Directory Enrollment Policy
6. Choose the certificate template created for Network Unlock on the Domain controller and select **Enroll**. When prompted for more information, add the following attribute to the certificate:
- Select the **Subject Name** pane and provide a friendly name value. It is suggested that this friendly name include information for the domain or organizational unit for the certificate. For example "BitLocker Network Unlock Certificate for Contoso domain"
7. Create the certificate. Ensure the certificate appears in the Personal folder.
8. Export the public key certificate for Network Unlock
1. Create a .cer file by right-clicking the previously created certificate, choosing **All Tasks**, then **Export**.
2. Select **No, do not export the private key**.
3. Select **DER encoded binary X.509** and complete exporting the certificate to a file.
4. Give the file a name such as BitLocker-NetworkUnlock.cer.
9. Export the public key with a private key for Network Unlock
1. Create a .pfx file by right-clicking the previously created certificate, choosing **All Tasks**, then **Export**.
2. Select **Yes, export the private key**.
3. Complete the wizard to create the .pfx file.
To create a self-signed certificate, you can either use the New-SelfSignedCertificate cmdlet in Windows PowerShell or use Certreq.
Windows PowerShell example:
```syntax
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN=BitLocker Network Unlock certificate" -Provider "Microsoft Software Key Storage Provider" -KeyUsage KeyEncipherment -KeyUsageProperty Decrypt,Sign -KeyLength 2048 -HashAlgorithm sha512 -TextExtension @("1.3.6.1.4.1.311.21.10={text}OID=1.3.6.1.4.1.311.67.1.1","2.5.29.37={text}1.3.6.1.4.1.311.67.1.1")
```
Certreq example:
1. Create a text file with an .inf extension. For example, notepad.exe BitLocker-NetworkUnlock.inf.
2. Add the following contents to the previously created file:
``` syntax
[NewRequest]
Subject="CN=BitLocker Network Unlock certificate"
ProviderType=0
MachineKeySet=True
Exportable=true
RequestType=Cert
KeyUsage="CERT_KEY_ENCIPHERMENT_KEY_USAGE"
KeyUsageProperty="NCRYPT_ALLOW_DECRYPT_FLAG | NCRYPT_ALLOW_SIGNING_FLAG"
KeyLength=2048
SMIME=FALSE
HashAlgorithm=sha512
[Extensions]
1.3.6.1.4.1.311.21.10 = "{text}"
_continue_ = "OID=1.3.6.1.4.1.311.67.1.1"
2.5.29.37 = "{text}"
_continue_ = "1.3.6.1.4.1.311.67.1.1"
```
3. Open an elevated command prompt and use the certreq tool to create a new certificate using the following command, specifying the full path to the file created previously, along with the file name:
``` syntax
certreq -new BitLocker-NetworkUnlock.inf BitLocker-NetworkUnlock.cer
```
4. Verify the previous command properly created the certificate by confirming the .cer file exists.
5. Launch Certificates - Local Machine by running **certlm.msc**.
6. Create a .pfx file by opening the **Certificates – Local Computer\\Personal\\Certificates** path in the navigation pane, right-clicking the previously imported certificate, selecting **All Tasks**, then **Export**. Follow through the wizard to create the .pfx file.
### <a href="" id="bkmk-stepfive"></a>Step Five: Deploy the private key and certificate to the WDS server
With the certificate and key created, deploy them to the infrastructure to properly unlock systems. To deploy the certificates, do the following:
1. On the WDS server, open a new MMC and add the certificates snap-in. Select the computer account and local computer when given the options.
2. Right-click the Certificates (Local Computer) - BitLocker Drive Encryption Network Unlock item, choose All Tasks, then **Import**.
3. In the **File to Import** dialog, choose the .pfx file created previously.
4. Enter the password used to create the .pfx and complete the wizard.
### <a href="" id="bkmk-stepsix"></a>Step Six: Configure Group Policy settings for Network Unlock
With certificate and key deployed to the WDS server for Network Unlock, the final step is to use Group Policy settings to deploy the public key certificate to computers that you want to be able to unlock using the Network Unlock key. Group Policy settings for BitLocker can be found under **\\Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption** using the Local Group Policy Editor or the Microsoft Management Console.
The following steps describe how to enable the Group Policy setting that is a requirement for configuring Network Unlock.
1. Open Group Policy Management Console (gpmc.msc).
2. Enable the policy **Require additional authentication at startup** and select the **Require startup PIN with TPM** option.
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers.
The following steps describe how to deploy the required Group Policy setting:
>**Note:**  The Group Policy settings **Allow network unlock at startup** and **Add Network Unlock Certificate** were introduced in Windows Server 2012.
 
1. Copy the .cer file created for Network Unlock to the domain controller.
2. On the domain controller, launch Group Policy Management Console (gpmc.msc).
3. Create a new Group Policy Object or modify an existing object to enable the **Allow network unlock at startup** setting.
4. Deploy the public certificate to clients:
1. Within Group Policy Management Console, navigate to the following location: **Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Public Key Policies\\BitLocker Drive Encryption Network Unlock Certificate**.
2. Right-click the folder and choose **Add Network Unlock Certificate**.
3. Follow the wizard steps and import the .cer file that was copied earlier.
>**Note:**  Only one network unlock certificate can be available at a time. If a new certificate is required, delete the current certificate before deploying a new one. The Network Unlock certificate is located in the **HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\FVE\_NKP** key on the client computer.
 
### <a href="" id="bkmk-stepseven"></a>Step Seven: Require TPM+PIN protectors at startup
An additional step is for enterprises to use TPM+PIN protectors for an extra level of security. To require TPM+PIN protectors in an environment, do the following:
1. Open Group Policy Management Console (gpmc.msc).
2. Enable the policy **Require additional authentication at startup** and select the **Require startup PIN with TPM** option.
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers.
### <a href="" id="bkmk-createcerttmpl"></a>Create the certificate template for Network Unlock
The following steps detail how to create a certificate template for use with BitLocker Network Unlock. A properly configured Active Directory Services Certification Authority can use this certificate to create and issue Network Unlock certificates.
1. Open the Certificates Template snap-in (certtmpl.msc).
2. Locate the User template. Right-click the template name and select **Duplicate Template**.
3. On the **Compatibility** tab, change the **Certification Authority** and **Certificate recipient** fields to Windows Server 2012 and Windows 8 respectively. Ensure the **Show resulting changes** dialog box is selected.
4. Select the **General** tab of the template. The **Template display name** and **Template name** should clearly identify that the template will be used for Network Unlock. Clear the checkbox for the **Publish certificate in Active Directory** option.
5. Select the **Request Handling** tab. Select **Encryption** from the **Purpose** drop down menu. Ensure the **Allow private key to be exported** option is selected.
6. Select the **Cryptography** tab. Set the **Minimum key size** to 2048. (Any Microsoft cryptographic provider that supports RSA can be used for this template, but for simplicity and forward compatibility we recommend using the **Microsoft Software Key Storage Provider**.)
7. Select the **Requests must use one of the following providers** option and clear all options except for the cryptography provider you selected, such as the **Microsoft Software Key Storage Provider**.
8. Select the **Subject Name** tab. Select **Supply in the request**. Select **OK** if the certificate templates pop-up dialog appears.
9. Select the **Issuance Requirements** tab. Select both **CA certificate manager approval** and **Valid existing certificate** options.
10. Select the **Extensions** tab. Select **Application Policies** and choose **Edit…**.
11. In the **Edit Application Policies Extension** options dialog box, select **Client Authentication**, **Encrypting File System**, **and Secure Email** and choose **Remove**.
12. On the **Edit Application Policies Extension** dialog box, select **Add**.
13. On the **Add Application Policy** dialog box, select **New**. In the **New Application Policy** dialog box enter the following information in the space provided and then click **OK** to create the BitLocker Network Unlock application policy:
- **Name:** **BitLocker Network Unlock**
- **Object Identifier:** **1.3.6.1.4.1.311.67.1.1**
14. Select the newly created **BitLocker Network Unlock** application policy and select **OK**.
15. With the **Extensions** tab still open, select the **Edit Key Usage Extension** dialog, select the **Allow key exchange only with key encryption (key encipherment)** option. Select the **Make this extension critical** option.
16. Select the **Security** tab. Confirm that the **Domain Admins** group has been granted **Enroll** permission.
17. Select **OK** to complete configuration of the template.
To add the Network Unlock template to the Certification Authority, open the Certification Authority snap-in (certsrv.msc). Right-click the **Certificate Templates** item and choose **New, Certificate Template to issue**. Select the previously created BitLocker Network Unlock certificate.
After adding the Network Unlock template to the Certification Authority, this certificate can be used to configure BitLocker Network Unlock.
### Subnet policy configuration files on WDS Server (Optional)
By default, all clients with the correct Network Unlock Certificate and valid Network Unlock protectors that have wired access to a Network Unlock-enabled WDS server via DHCP are unlocked by the server. A subnet policy configuration file on the WDS server can be created to limit which subnet(s) Network Unlock clients can use to unlock.
The configuration file, called bde-network-unlock.ini, must be located in the same directory as the Network Unlock provider DLL (%windir%\System32\Nkpprov.dll) and it applies to both IPv6 and IPv4 DHCP implementations. If the subnet configuration policy becomes corrupted, the provider will fail and stop responding to requests.
The subnet policy configuration file must use a “\[SUBNETS\]” section to identify the specific subnets. The named subnets may then be used to specify restrictions in certificate subsections. Subnets are defined as simple name-value pairs, in the common INI format, where each subnet has its own line, with the name on the left of the equals sign, and the subnet identified on the right of the equal sign as a Classless Inter-Domain Routing (CIDR) address or range. The key word “ENABLED” is disallowed for subnet names.
[SUBNETS]
SUBNET1=10.185.250.0/24 ; comment about this subrange could be here, after the semi-colon
SUBNET2=10.185.252.200/28
SUBNET3= 2001:4898:a:2::/64 ; an IPv6 subnet
SUBNET4=2001:4898:a:3::/64; in production, the admin would likely give more useful names, like BUILDING9-EXCEPT-RECEP.
```
Following the \[SUBNETS\] section, there can be sections for each Network Unlock certificate, identified by the certificate thumbprint formatted without any spaces, which define subnets clients can be unlocked from with that certificate.
>**Note:**  When specifying the certificate thumbprint, do not include any spaces. If spaces are included in the thumbprint the subnet configuration will fail because the thumbprint will not be recognized as valid.
 
Subnet restrictions are defined within each certificate section by denoting the allowed list of permitted subnets. If any subnet is listed in a certificate section, then only those subnets listed are permitted for that certificate. If no subnet is listed in a certificate section, then all subnets are permitted for that certificate. If a certificate does not have a section in the subnet policy configuration file, then no subnet restrictions are applied for unlocking with that certificate. This means for restrictions to apply to every certificate, there must be a certificate section for every Network Unlock certificate on the server, and an explicit allowed list set for each certificate section.
Subnet lists are created by putting the name of a subnet from the \[SUBNETS\] section on its own line below the certificate section header. Then, the server will only unlock clients with this certificate on the subnet(s) specified as in the list. For troubleshooting, a subnet can be quickly excluded without deleting it from the section by simply commenting it out with a prepended semi-colon.
[‎2158a767e1c14e88e27a4c0aee111d2de2eafe60]
;Comments could be added here to indicate when the cert was issued, which Group Policy should get it, and so on.
;This list shows this cert is only allowed to unlock clients on SUBNET1 and SUBNET3 subnets. In this example, SUBNET2 is commented out.
SUBNET1
;SUBNET2
SUBNET3
To disallow the use of a certificate altogether, its subnet list may contain the line “DISABLED".
### <a href="" id="bkmk-turnoffnetworkunlock"></a>Turning off Network Unlock
To turn off the unlock server, the PXE provider can be unregistered from the WDS server or uninstalled altogether. However, to stop clients from creating Network Unlock protectors the **Allow Network Unlock at startup** Group Policy setting should be disabled. When this policy setting is updated to disabled on client computers any Network Unlock key protectors on the computer will be deleted. Alternatively, the BitLocker Network Unlock certificate policy can be deleted on the domain controller to accomplish the same task for an entire domain.
>**Note:**  Removing the FVENKP certificate store that contains the Network Unlock certificate and key on the WDS server will also effectively disable the server’s ability to respond to unlock requests for that certificate. However, this is seen as an error condition and is not a supported or recommended method for turning off the Network Unlock server.
 
### <a href="" id="bkmk-updatecerts"></a>Update Network Unlock certificates
To update the certificates used by Network Unlock, administrators need to import or generate the new certificate for the server and then update the Network Unlock certificate Group Policy setting on the domain controller.
## <a href="" id="bkmk-troubleshoot"></a>Troubleshoot Network Unlock
Troubleshooting Network Unlock issues begins by verifying the environment. Many times, a small configuration issue will be the root cause of the failure. Items to verify include:
- Verify client hardware is UEFI-based and is on firmware version is 2.3.1 and that the UEFI firmware is in native mode without a Compatibility Support Module (CSM) for BIOS mode enabled. Do this by checking that the firmware does not have an option enabled such as "Legacy mode" or "Compatibility mode" or that the firmware does not appear to be in a BIOS-like mode.
- All required roles and services are installed and started
- Public and private certificates have been published and are in the proper certificate containers. The presence of the Network Unlock certificate can be verified in the Microsoft Management Console (MMC.exe) on the WDS server with the certificate snap-ins for the local computer enabled. The client certificate can be verified by checking the registry key **HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\FVE\_NKP** on the client computer.
- Group policy for Network Unlock is enabled and linked to the appropriate domains
- Verify group policy is reaching the clients properly. This can be done using the GPRESULT.exe or RSOP.msc utilities.
- Verify the **Network (Certificate Based)** protector is listed on the client. This can be done using either manage-bde or Windows PowerShell cmdlets. For example the following command will list the key protectors currently configured on the C: drive of the lcoal computer:
``` syntax
Manage-bde –protectors –get C:
```
>**Note:**  Use the output of manage-bde along with the WDS debug log to determine if the proper certificate thumbprint is being used for Network Unlock
 
Files to gather when troubleshooting BitLocker Network Unlock include:
1. The Windows event logs. Specifically the BitLocker event logs and the Microsoft-Windows-Deployment-Services-Diagnostics-Debug log
Debug logging is turned off by default for the WDS server role, so you will need to enable it first. You can use either of the following two methods to turn on WDS debug logging.
1. Start an elevated command prompt and run the following command:
``` syntax
wevtutil sl Microsoft-Windows-Deployment-Services-Diagnostics/Debug /e:true
```
2. Open Event Viewer on the WDS server.
In the left pane, click **Applications and Services Logs**, click **Microsoft**, click **Windows**, click **Deployment-Services-Diagnostics**, and then click **Debug**.
In the right pane, click **Enable Log**.
2. The DHCP subnet configuration file (if one exists).
3. The output of the BitLocker status on the volume, this can be gathered into a text file using **manage-bde -status** or **Get-BitLockerVolume** in Windows PowerShell.
4. Network Monitor capture on the server hosting the WDS role, filtered by client IP address.
## <a href="" id="bkmk-unsupportedsystems"></a>Configure Network Unlock Group Policy settings on earlier versions
Network Unlock and the accompanying Group Policy settings were introduced in Windows Server 2012 but can be deployed using operating systems running Windows Server 2008 R2 and Windows Server 2008.
**Requirements**
- The server hosting WDS must be running any of the server operating systems designated in the **Applies To** list at the beginning of this topic.
- Client computers must be running any of the client operating systems designated in the **Applies To** list at the beginning of this topic.
The following steps can be used to configure Network Unlock on these older systems.
1. [Step One: Install the WDS Server role](#bkmk-stepone)
2. [Step Two: Confirm the WDS Service is running](#bkmk-steptwo)
3. [Step Three: Install the Network Unlock feature](#bkmk-stepthree)
4. [Step Four: Create the Network Unlock certificate](#bkmk-stepfour)
5. [Step Five: Deploy the private key and certificate to the WDS server](#bkmk-stepfive)
6. [Step Six: Configure registry settings for Network Unlock](#bkmk-stepsix)
Apply the registry settings by running the following certutil script on each computer running any of the client operating systems designated in the **Applies To** list at the beginning of this topic.
certutil -f -grouppolicy -addstore FVE_NKP BitLocker-NetworkUnlock.cer
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v OSManageNKP /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseAdvancedStartup /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UsePIN /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMPIN /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPM /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKey /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKeyPIN /t REG_DWORD /d 2 /f
7. [Create the Network Unlock certificate](#bkmk-stepfour)
8. [Deploy the private key and certificate to the WDS server](#bkmk-stepfive)
9. [Create the certificate template for Network Unlock](#bkmk-createcerttmpl)
10. [Require TPM+PIN protectors at startup](#bkmk-stepseven)
## See also
- [BitLocker overview](bitlocker-overview.md)
- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)

186
windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md Normal file
View File

@ -0,0 +1,186 @@
---
title: BitLocker Management Recommendations for Enterprises (Windows 10)
description: This topic explains recommendations for managing BitLocker.
ms.assetid: 40526fcc-3e0d-4d75-90e0-c7d0615f33b2
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
localizationpriority: high
author: brianlic-msft
ms.date: 10/27/2017
---
# BitLocker Management Recommendations for Enterprises
This topic explains recommendations for managing BitLocker, both on-premises using older hardware and cloud-based management of modern devices.
## Forward-looking recommendations for managing BitLocker
The ideal for modern BitLocker management is to eliminate the need for IT admins to set management policies using tools or other mechanisms by having Windows perform tasks that it is more practical to automate. This vision leverages modern hardware developments. The growth of TPM 2.0, Secure Boot, and other hardware improvements, for example, has helped to alleviate the support burden on the helpdesk, and we are seeing a consequent decrease in support call volumes, yielding improved user satisfaction.
Therefore, we recommend that you upgrade your hardware so that your devices comply with Modern Standby or [Hardware Security Test Interface (HSTI)](https://msdn.microsoft.com/library/windows/hardware/mt712332.aspx) specifications to take advantage of their automated features, for example, when using Azure Active Directory (Azure AD).
Though much Windows BitLocker [documentation](bitlocker-overview.md) has been published, customers frequently ask for recommendations and pointers to specific, task-oriented documentation that is both easy to digest and focused on how to deploy and manage BitLocker. This article links to relevant documentation, products, and services to help answer this and other related frequently-asked questions, and also provides BitLocker recommendations for:
- [Domain-joined computers](#dom_join)
- [Devices joined to Azure Active Directory (Azure AD)](#azure_ad)
- [Workplace-joined PCs and Phones](#work_join)
- [Servers](#servers)
- [Scripts](#powershell)
<br />
## BitLocker management at a glance
| | PC – Old Hardware | PC – New* Hardware |[Servers](#servers)/[VMs](#VMs) | Phone
|---|---|----|---|---|
|On-premises Domain-joined |[MBAM](#MBAM25)| [MBAM](#MBAM25) | [Scripts](#powershell) |N/A|
|Cloud-managed|[MDM](#MDM) |Auto-encryption|[Scripts](#powershell)|[MDM](#MDM)/EAS|
<br />
*PC hardware that supports Modern Standby or HSTI
<br />
<br />
<a id="dom_join"></a>
## Recommendations for domain-joined computers
Windows continues to be the focus for new features and improvements for built-in encryption management, for example, automatically enabling encryption on devices that support Modern Standby beginning with Windows 8.1. For more information, see [Overview of BitLocker Device Encryption in Windows 10](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption).
Companies that image their own computers using Microsoft System Center 2012 Configuration Manager SP1 (SCCM) or later can use an existing task sequence to [pre-provision BitLocker](https://technet.microsoft.com/library/hh846237.aspx#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE) and can then [enable protection](https://technet.microsoft.com/library/hh846237.aspx#BKMK_EnableBitLocker). This can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, a company could also decide to use SCCM to pre-set any desired [BitLocker Group Policy](https://technet.microsoft.com/library/ee706521(v=ws.10).aspx).
For older client computers with BitLocker that are domain joined on-premises, Microsoft BitLocker Administration and Management<sup>[1]</sup> (MBAM) remains the best way to manage BitLocker. MBAM continues to be maintained and receives security patches. Using MBAM provides the following functionality:
- Encrypts device with BitLocker using MBAM
- Stores BitLocker Recovery keys in MBAM Server
- Provides Recovery key access to end-user, helpdesk and advanced helpdesk
- Provides Reporting on Compliance and Recovery key access audit
<a id="MBAM25"></a>
<sup>[1]</sup>The latest MBAM version is [MBAM 2.5](https://technet.microsoft.com/windows/hh826072.aspx) with Service Pack 1 (SP1).
<br />
<a id="azure_ad"></a>
## Recommendations for devices joined to Azure Active Directory
<a id="MDM"></a>
Devices joined to Azure Active Directory (Azure AD) are managed using Mobile Device Management (MDM) policy such as [Microsoft Intune](https://www.microsoft.com/cloud-platform/microsoft-intune). BitLocker Device Encryption status can be queried from managed machines via the [Policy Configuration Settings Provider](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider) (CSP), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access) to services like Exchange Online and SharePoint Online.
Starting with Windows 10 version 1703 (also known as the Windows Creators Update), the enablement of BitLocker can be triggered over MDM either by the [Policy CSP](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider) or the [BitLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp). The BitLocker CSP adds policy options that go beyond ensuring that encryption has occurred, and is available on computers that run Windows 10 Business or Enterprise editions and on Windows Phones.
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, BitLocker Device Encryption is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if required. For older devices that are not yet encrypted, beginning with Windows 10 version 1703 (the Windows 10 Creators Update), admins can use the [BitLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp) to trigger encryption and store the recovery key in Azure AD.
<a id="work_join"></a>
## Workplace-joined PCs and phones
For Windows PCs and Windows Phones that enroll using **Connect to work or school account**, BitLocker Device Encryption is managed over MDM, and similarly for Azure AD domain join.
<a id="servers"></a>
## Recommendations for servers
Servers are often installed, configured, and deployed using PowerShell, so the recommendation is to also use [PowerShell to enable BitLocker on a server](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md#a-href-idbkmk-blcmdletsabitlocker-cmdlets-for-windows-powershell), ideally as part of the initial setup. BitLocker is an Optional Component (OC) in Windows Server, so follow the directions in [BitLocker: How to deploy on Windows Server 2012 and later](bitlocker-how-to-deploy-on-windows-server.md) to add the BitLocker OC.
The Minimal Server Interface is a prerequisite for some of the BitLocker administration tools. On a [Server Core](https://docs.microsoft.com/windows-server/get-started/getting-started-with-server-core) installation, you must add the necessary GUI components first. The steps to add shell components to Server Core are described in [Using Features on Demand with Updated Systems and Patched Images](https://blogs.technet.microsoft.com/server_core/2012/11/05/using-features-on-demand-with-updated-systems-and-patched-images/) and [How to update local source media to add roles and features](https://blogs.technet.microsoft.com/joscon/2012/11/14/how-to-update-local-source-media-to-add-roles-and-features/).
If you are installing a server manually, such as a stand-alone server, then choosing [Server with Desktop Experience](https://docs.microsoft.com/windows-server/get-started/getting-started-with-server-with-desktop-experience) is the easiest path because you can avoid performing the steps to add a GUI to Server Core.
Additionally, lights out data centers can take advantage of the enhanced security of a second factor while avoiding the need for user intervention during reboots by optionally using a combination of BitLocker (TPM+PIN) and BitLocker Network Unlock. BitLocker Network Unlock brings together the best of hardware protection, location dependence, and automatic unlock, while in the trusted location. For the configuration steps, see [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md).
For more information, see the Bitlocker FAQs article and other useful links in [Related Articles](#articles).
 
<a id ="powershell"></a>
## PowerShell examples
For Azure AD-joined computers, including virtual machines, the recovery password should be stored in Azure Active Directory.
*Example: Use PowerShell to add a recovery password and back it up to Azure AD before enabling BitLocker*
```
PS C:\>Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
PS C:\>$BLV = Get-BitLockerVolume -MountPoint "C:”
PS C:\>BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[0].KeyProtectorId
```
For domain-joined computers, including servers, the recovery password should be stored in Active Directory Domain Services (AD DS).
*Example: Use PowerShell to add a recovery password and back it up to AD DS before enabling BitLocker*
```
PS C:\>Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
PS C:\>$BLV = Get-BitLockerVolume -MountPoint "C:”
PS C:\>Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[0].KeyProtectorId
```
Subsequently, you can use PowerShell to enable BitLocker.
*Example: Use PowerShell to enable BitLocker with a TPM protector*
```
PS C:\>Enable-BitLocker -MountPoint "D:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector
```
*Example: Use PowerShell to enable BitLocker with a TPM+PIN protector, in this case with a PIN set to 123456*
```
PS C:\>$SecureString = ConvertTo-SecureString "123456" -AsPlainText -Force
PS C:\> Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $SecureString -TPMandPinProtector
```
<a id = "articles"></a>
## Related Articles
[BitLocker: FAQs](bitlocker-frequently-asked-questions.md)
[Microsoft BitLocker Administration and Management (MBAM)](https://technet.microsoft.com/windows/hh826072.aspx)
[Overview of BitLocker Device Encryption in Windows 10](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption)
[System Center 2012 Configuration Manager SP1](https://technet.microsoft.com/library/hh846237.aspx#BKMK_PreProvisionBitLocker) *(Pre-provision BitLocker task sequence)*
[Enable BitLocker task sequence](https://technet.microsoft.com/library/hh846237.aspx#BKMK_EnableBitLocker)
[BitLocker Group Policy Reference](https://technet.microsoft.com/library/ee706521(v=ws.10).aspx)
[Microsoft Intune](https://www.microsoft.com/cloud-platform/microsoft-intune)
*(Overview)*
[Configuration Settings Providers](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider)
*(Policy CSP: See [Security-RequireDeviceEncryption](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-security#security-policies))*
[BitLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp)
<br />
**Windows Server setup tools**
[Windows Server Installation Options](https://technet.microsoft.com/library/hh831786(v=ws.11).aspx)
[How to update local source media to add roles and features](https://blogs.technet.microsoft.com/joscon/2012/11/14/how-to-update-local-source-media-to-add-roles-and-features/)
[How to add or remove optional components on Server Core](https://blogs.technet.microsoft.com/server_core/2012/11/05/using-features-on-demand-with-updated-systems-and-patched-images/) *(Features on Demand)*
[BitLocker: How to deploy on Windows Server 2012 and newer](bitlocker-how-to-deploy-on-windows-server.md)
[BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
[Shielded VMs and Guarded Fabric](https://blogs.technet.microsoft.com/windowsserver/2016/05/10/a-closer-look-at-shielded-vms-in-windows-server-2016/)
<br />
<a id="powershell"></a>
**Powershell**
[BitLocker cmdlets for Windows PowerShell](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md#a-href-idbkmk-blcmdletsabitlocker-cmdlets-for-windows-powershell)
[Surface Pro Specifications](https://www.microsoft.com/surface/support/surface-pro-specs)

86
windows/security/information-protection/bitlocker/bitlocker-overview.md Normal file
View File

@ -0,0 +1,86 @@
---
title: BitLocker (Windows 10)
description: This topic provides a high-level overview of BitLocker, including a list of system requirements, practical applications, and deprecated features.
ms.assetid: 40526fcc-3e0d-4d75-90e0-c7d0615f33b2
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/16/2017
---
# BitLocker
**Applies to**
- Windows 10
This topic provides a high-level overview of BitLocker, including a list of system requirements, practical applications, and deprecated features.
## <a href="" id="bkmk-over"></a>
BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.
BitLocker provides the most protection when used with a Trusted Platform Module (TPM) version 1.2 or later. The TPM is a hardware component installed in many newer computers by the computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not been
tampered with while the system was offline.
On computers that do not have a TPM version 1.2 or later, you can still use BitLocker to encrypt the Windows operating system drive. However, this implementation will require the user to insert a USB startup key to start the computer or resume from hibernation. Starting with Windows 8, you can use an operating system volume password to protect the operating system volume on a computer without TPM. Both options do not provide the pre-startup system integrity verification offered by BitLocker with a TPM.
In addition to the TPM, BitLocker offers the option to lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable device, such as a USB flash drive, that contains a startup key. These additional security measures provide multifactor authentication and assurance that the computer will not start or resume from hibernation until the correct PIN or startup key is presented.
## <a href="" id="bkmk-app"></a>Practical applications
Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software-attack tool against it or by transferring the computer's hard disk to a different computer. BitLocker helps mitigate unauthorized data access by enhancing file and system protections. BitLocker also helps render data inaccessible when BitLocker-protected computers are decommissioned or recycled.
There are two additional tools in the Remote Server Administration Tools, which you can use to manage BitLocker.
- **BitLocker Recovery Password Viewer**. The BitLocker Recovery Password Viewer enables you to locate and view BitLocker Drive Encryption recovery passwords that have been backed up to Active Directory Domain Services (AD DS). You can use this tool to help recover data that is stored on a drive that has been encrypted by using BitLocker. The BitLocker Recovery Password Viewer tool is an extension for the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in.
By using this tool, you can examine a computer object's **Properties** dialog box to view the corresponding BitLocker recovery passwords. Additionally, you can right-click a domain container and then search for a BitLocker recovery password across all the domains in the Active Directory forest. To view recovery passwords, you must be a domain administrator, or you must have been delegated permissions by a domain administrator.
- **BitLocker Drive Encryption Tools**. BitLocker Drive Encryption Tools include the command-line tools, manage-bde and repair-bde, and the BitLocker cmdlets for Windows PowerShell. Both manage-bde and the BitLocker cmdlets can be used to perform any task that can be accomplished through the
BitLocker control panel, and they are appropriate to use for automated deployments and other scripting scenarios. Repair-bde is provided for disaster recovery scenarios in which a BitLocker protected drive cannot be unlocked normally or by using the recovery console.
## <a href="" id="bkmk-new"></a>New and changed functionality
To find out what's new in BitLocker for Windows 10, such as support for the XTS-AES encryption algorithm, see the [BitLocker](https://technet.microsoft.com/itpro/windows/whats-new/whats-new-windows-10-version-1507-and-1511#bitlocker) section in "What's new in Windows 10, versions 1507 and 1511."
 
## System requirements
BitLocker has the following hardware requirements:
For BitLocker to use the system integrity check provided by a Trusted Platform Module (TPM), the computer must have TPM 1.2 or later. If your computer does not have a TPM, enabling BitLocker requires that you save a startup key on a removable device, such as a USB flash drive.
A computer with a TPM must also have a Trusted Computing Group (TCG)-compliant BIOS or UEFI firmware. The BIOS or UEFI firmware establishes a chain of trust for the pre-operating system startup, and it must include support for TCG-specified Static Root of Trust Measurement. A computer without a TPM does not require TCG-compliant firmware.
The system BIOS or UEFI firmware (for TPM and non-TPM computers) must support the USB mass storage device class, including reading small files on a USB flash drive in the pre-operating system environment.
The hard disk must be partitioned with at least two drives:
- The operating system drive (or boot drive) contains the operating system and its support files. It must be formatted with the NTFS file system.
- The system drive contains the files that are needed to load Windows after the firmware has prepared the system hardware. BitLocker is not enabled on this drive. For BitLocker to work, the system drive must not be encrypted, must differ from the operating system drive, and must be formatted with the FAT32 file system on computers that use UEFI-based firmware or with the NTFS file system on computers that use BIOS firmware. We recommend that system drive be approximately 350 MB in size. After BitLocker is turned on it should have approximately 250 MB of free space.
When installed on a new computer, Windows will automatically create the partitions that are required for BitLocker.
When installing the BitLocker optional component on a server you will also need to install the Enhanced Storage feature, which is used to support hardware encrypted drives.
## In this section
| Topic | Description |
| - | - |
| [Overview of BitLocker Device Encryption in Windows 10](bitlocker-device-encryption-overview-windows-10.md) | This topic for the IT professional provides an overview of the ways that BitLocker Device Encryption can help protect data on devices running Windows 10. |
| [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md) | This topic for the IT professional answers frequently asked questions concerning the requirements to use, upgrade, deploy and administer, and key management policies for BitLocker.|
| [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)| This topic for the IT professional explains how can you plan your BitLocker deployment. |
| [BitLocker basic deployment](bitlocker-basic-deployment.md) | This topic for the IT professional explains how BitLocker features can be used to protect your data through drive encryption. |
| [BitLocker: How to deploy on Windows Server 2012 and later](bitlocker-how-to-deploy-on-windows-server.md)| This topic for the IT professional explains how to deploy BitLocker and Windows Server 2012 and later.|
| [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md) | This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it. |
| [BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md)| This topic for the IT professional describes how to use tools to manage BitLocker.|
| [BitLocker: Use BitLocker Recovery Password Viewer](bitlocker-use-bitlocker-recovery-password-viewer.md) | This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer. |
| [BitLocker Group Policy settings](bitlocker-group-policy-settings.md) | This topic for IT professionals describes the function, location, and effect of each Group Policy setting that is used to manage BitLocker. |
| [BCD settings and BitLocker](bcd-settings-and-bitlocker.md) | This topic for IT professionals describes the BCD settings that are used by BitLocker.|
| [BitLocker Recovery Guide](bitlocker-recovery-guide-plan.md)| This topic for IT professionals describes how to recover BitLocker keys from AD DS. |
| [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)| This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration. |
| [Protecting cluster shared volumes and storage area networks with BitLocker](protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md)| This topic for IT pros describes how to protect CSVs and SANs with BitLocker.|
| [Enabling Secure Boot and BitLocker Device Encryption on Windows 10 IoT Core](https://developer.microsoft.com/windows/iot/docs/securebootandbitlocker) | This topic covers how to use BitLocker with Windows 10 IoT Core |

738
windows/security/information-protection/bitlocker/bitlocker-recovery-guide-plan.md Normal file
View File

@ -0,0 +1,738 @@
---
title: BitLocker recovery guide (Windows 10)
description: This topic for IT professionals describes how to recover BitLocker keys from AD DS.
ms.assetid: d0f722e9-1773-40bf-8456-63ee7a95ea14
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 08/17/2017
---
# BitLocker recovery guide
**Applies to**
- Windows 10
This topic for IT professionals describes how to recover BitLocker keys from AD DS.
Organizations can use BitLocker recovery information saved in Active Directory Domain Services (AD DS) to access BitLocker-protected data. Creating a recovery model for BitLocker while you are planning your BitLocker deployment is recommended.
This article assumes that you understand how to set up AD DS to back up BitLocker recovery information automatically, and what types of recovery information are saved to AD DS.
This article does not detail how to configure AD DS to store the BitLocker recovery information.
This article contains the following topics:
- [What Is BitLocker Recovery?](#bkmk-whatisrecovery)
- [Testing Recovery](#bkmk-testingrecovery)
- [Planning Your Recovery Process](#bkmk-planningrecovery)
- [Using Additional Recovery Information](#bkmk-usingaddrecovery)
- [Resetting Recovery Passwords](#bkmk-appendixb)
- [Retrieving the BitLocker Key Package](#bkmk-appendixc)
## <a href="" id="bkmk-whatisrecovery"></a>What is BitLocker recovery?
BitLocker recovery is the process by which you can restore access to a BitLocker-protected drive in the event that you cannot unlock the drive normally. In a recovery scenario you have the following options to restore access to the drive:
- The user can supply the recovery password. If your organization allows users to print or store recovery passwords, the user can type in the 48-digit recovery password that they printed or stored on a USB drive or with your Microsoft Account online. (Saving a recovery password with your Microsoft Account online is only allowed when BitLocker is used on a PC that is not a member of a domain).
- A data recovery agent can use their credentials to unlock the drive. If the drive is an operating system drive, the drive must be mounted as a data drive on another computer for the data recovery agent to unlock it.
- A domain administrator can obtain the recovery password from AD DS and use it to unlock the drive. Storing recovery passwords in AD DS is recommended to provide a way for IT professionals to be able to obtain recovery passwords for drives in their organization if needed. This method requires that you have enabled this recovery method in the BitLocker Group Policy setting **Choose how BitLocker-protected operating system drives can be recovered** located at **Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption\\Operating System Drives** in the Local Group Policy Editor. For more information, see [BitLocker Group Policy settings](bitlocker-group-policy-settings.md).
### What causes BitLocker recovery?
The following list provides examples of specific events that will cause BitLocker to enter recovery mode when attempting to start the operating system drive:
- On PCs that use BitLocker, or on devices such as tablets or phones that use Device Encryption only, when an attack is detected, the device will immediately reboot and enter into BitLocker recovery mode. To take advantage of this functionality Administrators can set the **Interactive logon: Machine account lockout threshold** Group Policy setting located in **\\Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options** in the Local Group Policy Editor, or use the **MaxFailedPasswordAttempts** policy of [Exchange ActiveSync](http://technet.microsoft.com/library/aa998357.aspx) (also configurable through [Windows Intune](http://technet.microsoft.com/library/jj733621.aspx)), to limit the number of failed password attempts before the device goes into Device Lockout.
- On devices with TPM 1.2, changing the BIOS or firmware boot device order causes BitLocker recovery. However, devices with TPM 2.0 do not start BitLocker recovery in this case. TPM 2.0 does not consider a firmware change of boot device order as a security threat because the OS Boot Loader is not compromised.
- Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD or DVD.
- Failing to boot from a network drive before booting from the hard drive.
- Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and the BIOS), the docking condition of the portable computer is part of the system measurement and must be consistent to validate the system status and unlock BitLocker. This means that if a portable computer is connected to its docking station when BitLocker is turned on, then it might also need to be connected to the docking station when it is unlocked. Conversely, if a portable computer is not connected to its docking station when BitLocker is turned on, then it might need to be disconnected from the docking station when it is unlocked.
- Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
- Entering the personal identification number (PIN) incorrectly too many times so that the anti-hammering logic of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has passed.
- Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI firmware if you are using USB-based keys instead of a TPM.
- Turning off, disabling, deactivating, or clearing the TPM.
- Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related boot measurements to change.
- Forgetting the PIN when PIN authentication has been enabled.
- Updating option ROM firmware.
- Upgrading TPM firmware.
- Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA wireless cards.
- Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
- Changes to the master boot record on the disk.
- Changes to the boot manager on the disk.
- Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM does not respond to commands from any software.
- Using a different keyboard that does not correctly enter the PIN or whose keyboard map does not match the keyboard map assumed by the pre-boot environment. This can prevent the entry of enhanced PINs.
- Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example, including **PCR\[1\]** would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to enter recovery mode even when non-boot critical BIOS settings change.
>**Note:**  Some computers have BIOS settings that skip measurements to certain PCRs, such as **PCR\[2\]**. Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR measurement will be different.
 
- Moving the BitLocker-protected drive into a new computer.
- Upgrading the motherboard to a new one with a new TPM.
- Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
- Failing the TPM self-test.
- Having a BIOS, UEFI firmware, or an option ROM component that is not compliant with the relevant Trusted Computing Group standards for a client computer. For example, a non-compliant implementation may record volatile data (such as time) in the TPM measurements, causing different measurements on each startup and causing BitLocker to start in recovery mode.
- Changing the usage authorization for the storage root key of the TPM to a non-zero value.
>**Note:**  The BitLocker TPM initialization process sets the usage authorization value to zero, so another user or process must explicitly have changed this value.
 
- Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
- Pressing the F8 or F10 key during the boot process.
- Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.
- Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive.
>**Note:**  Before you begin recovery, we recommend that you determine what caused recovery. This might help prevent the problem from occurring again in the future. For instance, if you determine that an attacker has modified your computer by obtaining physical access, you can create new security policies for tracking who has physical presence. After the recovery password has been used to recover access to the PC, BitLocker will reseal the encryption key to the current values of the measured components.
 
For planned scenarios, such as a known hardware or firmware upgrades, you can avoid initiating recovery by temporarily suspending BitLocker protection. Because suspending BitLocker leaves the drive fully encrypted, the administrator can quickly resume BitLocker protection after the planned task has been completed. Using suspend and resume also reseals the encryption key without requiring the entry of the recovery key.
>**Note:**  If suspended BitLocker will automatically resume protection when the PC is rebooted, unless a reboot count is specified using the manage-bde command line tool.
If software maintenance requires the computer be restarted and you are using two-factor authentication, you can enable BitLocker Network Unlock to provide the secondary authentication factor when the computers do not have an on-premise user to provide the additional authentication method.
 
Recovery has been described within the context of unplanned or undesired behavior, but you can also cause recovery as an intended production scenario, in order to manage access control. For example, when you redeploy desktop or laptop computers to other departments or employees in your enterprise, you can force BitLocker into recovery before the computer is given to a new user.
## <a href="" id="bkmk-testingrecovery"></a>Testing recovery
Before you create a thorough BitLocker recovery process, we recommend that you test how the recovery process works for both end users (people who call your helpdesk for the recovery password) and administrators (people who help the end user get the recovery password). The –forcerecovery command of manage-bde is an easy way for you to step through the recovery process before your users encounter a recovery situation.
**To force a recovery for the local computer**
1. Click the **Start** button, type **cmd** in the **Start Search** box, right-click **cmd.exe**, and then click **Run as administrator**.
2. At the command prompt, type the following command and then press ENTER:
`manage-bde -forcerecovery <Volume>`
**To force recovery for a remote computer**
1. On the Start screen, type **cmd.exe**, and then click **Run as administrator**.
2. At the command prompt, type the following command and then press ENTER:
`manage-bde. -ComputerName <ComputerName> -forcerecovery <Volume>`
> **Note:**  *ComputerName* represents the name of the remote computer. *Volume* represents the volume on the remote computer that is protected with BitLocker.
 
## <a href="" id="bkmk-planningrecovery"></a>Planning your recovery process
When planning the BitLocker recovery process, first consult your organization's current best practices for recovering sensitive information. For example: How does your enterprise handle lost Windows passwords? How does your organization perform smart card PIN resets? You can use these best practices and related resources (people and tools) to help formulate a BitLocker recovery model.
Organizations that rely on BitLocker Drive Encryption and BitLocker To Go to protect data on a large number of computers and removable drives running the Windows 10, Windows 8, or Windows 7 operating systems and Windows to Go should consider using the Microsoft BitLocker Administration and Monitoring (MBAM) Tool version 2.0, which is included in the Microsoft Desktop Optimization Pack (MDOP) for Microsoft Software Assurance. MBAM makes BitLocker implementations easier to deploy and manage and allows administrators to provision and monitor encryption for operating system and fixed drives. MBAM prompts the user before encrypting fixed drives. MBAM also manages recovery keys for fixed and removable drives, making recovery easier to manage. MBAM can be used as part of a Microsoft System Center deployment or as a stand-alone solution. For more info, see [Microsoft BitLocker
Administration and Monitoring](http://technet.microsoft.com/windows/hh826072.aspx).
After a BitLocker recovery has been initiated, users can use a recovery password to unlock access to encrypted data. You must consider both self-recovery and recovery password retrieval methods for your organization.
When you determine your recovery process, you should:
- Become familiar with how you can retrieve the recovery password. See:
- [Self-recovery](#bkmk-selfrecovery)
- [Recovery password retrieval](#bkmk-recoveryretrieval)
- Determine a series of steps for post-recovery, including analyzing why the recovery occurred and resetting the recovery password. See:
- [Post-recovery analysis](#bkmk-planningpostrecovery)
### <a href="" id="bkmk-selfrecovery"></a>Self-recovery
In some cases, users might have the recovery password in a printout or a USB flash drive and can perform self-recovery. We recommend that your organization create a policy for self-recovery. If self-recovery includes using a password or recovery key stored on a USB flash drive, the users should be warned not to store the USB flash drive in the same place as the PC, especially during travel, for example if both the PC and the recovery items are in the same bag it would be very easy for access to be gained to the PC by an unauthorized user. Another policy to consider is having users contact the Helpdesk before or after performing self-recovery so that the root cause can be identified.
### <a href="" id="bkmk-recoveryretrieval"></a>Recovery password retrieval
If the user does not have a recovery password in a printout or on a USB flash drive, the user will need to be able to retrieve the recovery password from an online source. If the PC is a member of a domain the recovery password can be backed up to AD DS. However, this does not happen by default, you must have configured the appropriate Group Policy settings before BitLocker was enabled on the PC. BitLocker Group Policy settings can be found in the Local Group Policy Editor or the Group Policy Management Console (GPMC) under **Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption**. The following policy settings define the recovery methods that can be used to restore access to a BitLocker-protected drive if an authentication method fails or is unable to be used.
- **Choose how BitLocker-protected operating system drives can be recovered**
- **Choose how BitLocker-protected fixed drives can be recovered**
- **Choose how BitLocker-protected removable drives can be recovered**
In each of these policies, select **Save BitLocker recovery information to Active Directory Domain Services** and then choose which BitLocker recovery information to store in Active Directory Domain Services (AD DS). Select the **Do not enable BitLocker until recovery information is stored in AD
DS** check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information for the drive to AD DS succeeds.
>**Note:**  If the PCs are part of a workgroup, users should be advised to save their BitLocker recovery password with their Microsoft Account online. Having an online copy of your BitLocker recovery password is recommended to help ensure that you do not lose access to your data in the event that recovery is required.
 
The BitLocker Recovery Password Viewer for Active Directory Users and Computers tool allows domain administrators to view BitLocker recovery passwords for specific computer objects in Active Directory.
You can use the following list as a template for creating your own recovery process for recovery password retrieval. This sample process uses the BitLocker Recovery Password Viewer for Active Directory Users and Computers tool.
- [Record the name of the user's computer](#bkmk-recordcomputername)
- [Verify the user's identity](#bkmk-verifyidentity)
- [Locate the recovery password in AD DS](#bkmk-locatepassword)
- [Gather information to determine why recovery occurred](#bkmk-gatherinfo)
- [Give the user the recovery password](#bkmk-givepassword)
### <a href="" id="bkmk-recordcomputername"></a>Record the name of the user's computer
You can use the name of the user's computer to locate the recovery password in AD DS. If the user does not know the name of the computer, ask the user to read the first word of the **Drive Label** in the **BitLocker Drive Encryption Password Entry** user interface. This is the computer name when BitLocker was enabled and is probably the current name of the computer.
### <a href="" id="bkmk-verifyidentity"></a>Verify the user's identity
You should verify that the person that is asking for the recovery password is truly the authorized user of that computer. You may also wish to verify that the computer with the name the user provided belongs to the user.
### <a href="" id="bkmk-locatepassword"></a>Locate the recovery password in AD DS
Locate the Computer object with the matching name in AD DS. Because Computer object names are listed in the AD DS global catalog, you should be able to locate the object even if you have a multi-domain forest.
### Multiple recovery passwords
If multiple recovery passwords are stored under a computer object in AD DS, the name of the BitLocker recovery information object includes the date that the password was created.
If at any time you are unsure what password to provide, or if you think you might be providing the incorrect password, ask the user to read the eight character password ID that is displayed in the recovery console.
Since the password ID is a unique value that is associated with each recovery password stored in AD DS, running a query using this ID will find the correct password to unlock the encrypted volume.
### <a href="" id="bkmk-gatherinfo"></a>Gather information to determine why recovery occurred
Before you give the user the recovery password, you should gather any information that will help determine why the recovery was needed, in order to analyze the root cause during the post-recovery analysis. For more info about post-recovery analysis, see [Post-recovery analysis](#bkmk-planningpostrecovery).
### <a href="" id="bkmk-givepassword"></a>Give the user the recovery password
Because the recovery password is 48 digits long the user may need to record the password by writing it down or typing it on a different computer. If you are using MBAM, the recovery password will be regenerated after it is recovered from the MBAM database to avoid the security risks associated with an uncontrolled password.
>**Note:**  Because the 48-digit recovery password is long and contains a combination of digits, the user might mishear or mistype the password. The boot-time recovery console uses built-in checksum numbers to detect input errors in each 6-digit block of the 48-digit recovery password, and offers the user the opportunity to correct such errors.
 
### <a href="" id="bkmk-planningpostrecovery"></a>Post-recovery analysis
When a volume is unlocked using a recovery password, an event is written to the event log and the platform validation measurements are reset in the TPM to match the current configuration. Unlocking the volume means that the encryption key has been released and is ready for on-the-fly encryption
when data is written to the volume, and on-the-fly decryption when data is read from the volume. After the volume is unlocked, BitLocker behaves the same way, regardless of how the access was granted.
If you notice that a computer is having repeated recovery password unlocks, you might want to have an administrator can perform post-recovery analysis to determine the root cause of the recovery and refresh BitLocker platform validation so that the user no longer needs to enter a recovery password each time that the computer starts up. See:
- [Determine the root cause of the recovery](#bkmk-determinecause)
- [Refresh BitLocker protection](#bkmk-refreshprotection)
### <a href="" id="bkmk-determinecause"></a>Determine the root cause of the recovery
If a user needed to recover the drive, it is important to determine the root cause that initiated the recovery as soon as possible. Properly analyzing the state of the computer and detecting tampering may reveal threats that have broader implications for enterprise security.
While an administrator can remotely investigate the cause of recovery in some cases, the end user might need to bring the computer that contains the recovered drive on site to analyze the root cause further.
Review and answer the following questions for your organization:
1. What BitLocker protection mode is in effect (TPM, TPM + PIN, TPM + startup key, startup key only)? Which PCR profile is in use on the PC?
2. Did the user merely forget the PIN or lose the startup key? If a token was lost, where might the token be?
3. If TPM mode was in effect, was recovery caused by a boot file change?
4. If recovery was caused by a boot file change, is this due to an intended user action (for example, BIOS upgrade), or to malicious software?
5. When was the user last able to start the computer successfully, and what might have happened to the computer since then?
6. Might the user have encountered malicious software or left the computer unattended since the last successful startup?
To help you answer these questions, use the BitLocker command-line tool to view the current configuration and protection mode (for example, **manage-bde -status**). Scan the event log to find events that help indicate why recovery was initiated (for example, if boot file change occurred). Both of these capabilities can be performed remotely.
### <a href="" id="bkmk-refreshprotection"></a>Resolve the root cause
After you have identified what caused recovery, you can reset BitLocker protection and avoid recovery on every startup.
The details of this reset can vary according to the root cause of the recovery. If you cannot determine the root cause, or if malicious software or a rootkit might have infected the computer, Helpdesk should apply best-practice virus policies to react appropriately.
>**Note:**  You can perform a BitLocker validation profile reset by suspending and resuming BitLocker.
 
- [Unknown PIN](#bkmk-unknownpin)
- [Lost startup key](#bkmk-loststartup)
- [Changes to boot files](#bkmk-changebootknown)
### <a href="" id="bkmk-unknownpin"></a>Unknown PIN
If a user has forgotten the PIN, you must reset the PIN while you are logged on to the computer in order to prevent BitLocker from initiating recovery each time the computer is restarted.
**To prevent continued recovery due to an unknown PIN**
1. Unlock the computer using the recovery password.
2. Reset the PIN:
1. Right-click the drive and then click **Change PIN**
2. In the BitLocker Drive Encryption dialog, click **Reset a forgotten PIN**. If you are not logged in with an administrator account you must provide administrative credentials at this time.
3. In the PIN reset dialog, provide and confirm the new PIN to use and then click **Finish**.
3. You will use the new PIN the next time you unlock the drive.
### <a href="" id="bkmk-loststartup"></a>Lost startup key
If you have lost the USB flash drive that contains the startup key, then you must unlock the drive by using the recovery key and then create a new startup key.
**To prevent continued recovery due to a lost startup key**
1. Log on as an administrator to the computer that has the lost startup key.
2. Open Manage BitLocker.
3. Click **Duplicate start up key**, insert the clean USB drive on which you are going to write the key and then click **Save**.
### <a href="" id="bkmk-changebootknown"></a>Changes to boot files
This error might occur if you updated the firmware. As a best practice you should suspend BitLocker before making changes the firmware and then resume protection after the update has completed. This prevents the computer from going into recovery mode. However if changes were made when BitLocker protection was on you can simply log on to the computer using the recovery password and the platform validation profile will be updated so that recovery will not occur the next time.
## Windows RE and BitLocker Device Encryption
Windows Recovery Environment (RE) can be used to recover access to a drive protected by BitLocker Device Encryption. If a PC is unable to boot after two failures, Startup Repair will automatically start. When Startup Repair is launched automatically due to boot failures, it will only execute operating system and driver file repairs, provided that the boot logs or any available crash dump point to a specific corrupted file. In Windows 8.1 and later, devices that include firmware to support specific TPM measurements for PCR\[7\] the TPM can validate that Windows RE is a trusted operating environment and will unlock any BitLocker-protected drives if Windows RE has not been modified. If the Windows RE environment has been modified, for example the TPM has been disabled, the drives will stay locked until the BitLocker recovery key is provided. If Startup Repair is not able to be run automatically from the PC and instead Windows RE is manually started from a repair disk, the BitLocker recovery key must be provided to unlock the BitLocker–protected drives.
## <a href="" id="bkmk-usingaddrecovery"></a>Using additional recovery information
Besides the 48-digit BitLocker recovery password, other types of recovery information are stored in Active Directory. This section describes how this additional information can be used.
### BitLocker key package
If the recovery methods discussed earlier in this document do not unlock the volume, you can use the BitLocker Repair tool to decrypt the volume at the block level. The tool uses the BitLocker key package to help recover encrypted data from severely damaged drives. You can then use this recovered data to salvage encrypted data, even after the correct recovery password has failed to unlock the damaged volume. We recommend that you still save the recovery password. A key package cannot be used without the corresponding recovery password.
>**Note:**  You must use the BitLocker Repair tool **repair-bde** to use the BitLocker key package.
 
The BitLocker key package is not saved by default. To save the package along with the recovery password in AD DS you must select the **Backup recovery password and key package** option in the Group Policy settings that control the recovery method. You can also export the key package from a working volume. For more details on how to export key packages, see [Retrieving the BitLocker Key Package](#bkmk-appendixc).
## <a href="" id="bkmk-appendixb"></a>Resetting recovery passwords
You should invalidate a recovery password after it has been provided and used. It should also be done when you intentionally want to invalidate an existing recovery password for any reason.
You can reset the recovery password in two ways:
- **Use manage-bde** You can use manage-bde to remove the old recovery password and add a new recovery password. The procedure identifies the command and the syntax for this method.
- **Run a script** You can run a script to reset the password without decrypting the volume. The sample script in the procedure illustrates this functionality. The sample script creates a new recovery password and invalidates all other passwords.
**To reset a recovery password using manage-bde**
1. Remove the previous recovery password
``` syntax
Manage-bde –protectors –delete C: –type RecoveryPassword
```
2. Add the new recovery password
``` syntax
Manage-bde –protectors –add C: -RecoveryPassword
```
3. Get the ID of the new recovery password. From the screen copy the ID of the recovery password.
``` syntax
Manage-bde –protectors –get C: -Type RecoveryPassword
```
4. Backup the new recovery password to AD DS
``` syntax
Manage-bde –protectors –adbackup C: -id {EXAMPLE6-5507-4924-AA9E-AFB2EB003692}
```
>**Warning:**  You must include the braces in the ID string.
 
**To run the sample recovery password script**
1. Save the following sample script in a VBScript file. For example: ResetPassword.vbs.
2. At the command prompt, type a command similar to the following:
**cscript ResetPassword.vbs**
>**Important:**  This sample script is configured to work only for the C volume. You must customize the script to match the volume where you want to test password reset.
 
> **Note:**  To manage a remote computer, you can specify the remote computer name rather than the local computer name.
 
You can use the following sample script to create a VBScript file to reset the recovery passwords.
``` syntax
' Target drive letter
strDriveLetter = "c:"
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
& "\root\cimv2\Security\MicrosoftVolumeEncryption"
On Error Resume Next 'handle permission errors
Set objWMIService = GetObject(strConnectionStr)
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
On Error GoTo 0
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " & strComputerName & "."
WScript.Quit -1
End If
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
' objVolume is now our found BitLocker-capable disk volume
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
' Add a new recovery password, keeping the ID around so it doesn't get deleted later
' ----------------------------------------------------------------------------------
nRC = objVolume.ProtectKeyWithNumericalPassword("Recovery Password Refreshed By Script", , sNewKeyProtectorID)
If nRC <> 0 Then
WScript.Echo "FAILURE: ProtectKeyWithNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Removes the other, "stale", recovery passwords
' ----------------------------------------------------------------------------------
nKeyProtectorTypeIn = 3 ' type associated with "Numerical Password" protector
nRC = objVolume.GetKeyProtectors(nKeyProtectorTypeIn, aKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Delete those key protectors other than the one we just added.
For Each sKeyProtectorID In aKeyProtectorIDs
If sKeyProtectorID <> sNewKeyProtectorID Then
nRC = objVolume.DeleteKeyProtector(sKeyProtectorID)
If nRC <> 0 Then
WScript.Echo "FAILURE: DeleteKeyProtector on ID " & sKeyProtectorID & " failed with return code 0x" & Hex(nRC)
WScript.Quit -1
Else
' no output
'WScript.Echo "SUCCESS: Key protector with ID " & sKeyProtectorID & " deleted"
End If
End If
Next
WScript.Echo "A new recovery password has been added. Old passwords have been removed."
' - some advanced output (hidden)
'WScript.Echo ""
'WScript.Echo "Type ""manage-bde -protectors -get " & strDriveLetter & " -type recoverypassword"" to view existing passwords."
```
## <a href="" id="bkmk-appendixc"></a>Retrieving the BitLocker key package
You can use two methods to retrieve the key package, as described in [Using Additional Recovery Information](#bkmk-usingaddrecovery):
- **Export a previously-saved key package from AD DS.** You must have Read access to BitLocker recovery passwords that are stored in AD DS.
- **Export a new key package from an unlocked, BitLocker-protected volume.** You must have local administrator access to the working volume, before any damage has occurred.
The following sample script exports all previously-saved key packages from AD DS.
**To run the sample key package retrieval script**
1. Save the following sample script in a VBScript file. For example: GetBitLockerKeyPackageADDS.vbs.
2. At the command prompt, type a command similar to the following:
**cscript GetBitLockerKeyPackageADDS.vbs -?**
You can use the following sample script to create a VBScript file to retrieve the BitLocker key package from AD DS.
``` syntax
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackageADDS [Path To Save Key Package] [Optional Computer Name]"
Wscript.Echo "If no computer name is specified, the local computer is assumed."
Wscript.Echo
Wscript.Echo "Example: GetBitLockerKeyPackageADDS E:\bitlocker-ad-key-package mycomputer"
WScript.Quit
End Sub
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
Set args = WScript.Arguments
Select Case args.Count
Case 1
If args(0) = "/?" Or args(0) = "-?" Then
ShowUsage
Else
strFilePath = args(0)
' Get the name of the local computer
Set objNetwork = CreateObject("WScript.Network")
strComputerName = objNetwork.ComputerName
End If
Case 2
If args(0) = "/?" Or args(0) = "-?" Then
ShowUsage
Else
strFilePath = args(0)
strComputerName = args(1)
End If
Case Else
ShowUsage
End Select
' --------------------------------------------------------------------------------
' Get path to Active Directory computer object associated with the computer name
' --------------------------------------------------------------------------------
Function GetStrPathToComputer(strComputerName)
' Uses the global catalog to find the computer in the forest
' Search also includes deleted computers in the tombstone
Set objRootLDAP = GetObject("LDAP://rootDSE")
namingContext = objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com
strBase = "<GC://" & namingContext & ">"
Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOOBject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
strFilter = "(&(objectCategory=Computer)(cn=" & strComputerName & "))"
strQuery = strBase & ";" & strFilter & ";distinguishedName;subtree"
objCommand.CommandText = strQuery
objCommand.Properties("Page Size") = 100
objCommand.Properties("Timeout") = 100
objCommand.Properties("Cache Results") = False
' Enumerate all objects found.
Set objRecordSet = objCommand.Execute
If objRecordSet.EOF Then
WScript.echo "The computer name '" & strComputerName & "' cannot be found."
WScript.Quit 1
End If
' Found object matching name
Do Until objRecordSet.EOF
dnFound = objRecordSet.Fields("distinguishedName")
GetStrPathToComputer = "LDAP://" & dnFound
objRecordSet.MoveNext
Loop
' Clean up.
Set objConnection = Nothing
Set objCommand = Nothing
Set objRecordSet = Nothing
End Function
' --------------------------------------------------------------------------------
' Securely access the Active Directory computer object using Kerberos
' --------------------------------------------------------------------------------
Set objDSO = GetObject("LDAP:")
strPathToComputer = GetStrPathToComputer(strComputerName)
WScript.Echo "Accessing object: " + strPathToComputer
Const ADS_SECURE_AUTHENTICATION = 1
Const ADS_USE_SEALING = 64 '0x40
Const ADS_USE_SIGNING = 128 '0x80
' --------------------------------------------------------------------------------
' Get all BitLocker recovery information from the Active Directory computer object
' --------------------------------------------------------------------------------
' Get all the recovery information child objects of the computer object
Set objFveInfos = objDSO.OpenDSObject(strPathToComputer, vbNullString, vbNullString, _
ADS_SECURE_AUTHENTICATION + ADS_USE_SEALING + ADS_USE_SIGNING)
objFveInfos.Filter = Array("msFVE-RecoveryInformation")
' Iterate through each recovery information object and saves any existing key packages
nCount = 1
strFilePathCurrent = strFilePath & nCount
For Each objFveInfo in objFveInfos
strName = objFveInfo.Get("name")
strRecoveryPassword = objFveInfo.Get("msFVE-RecoveryPassword")
strKeyPackage = objFveInfo.Get("msFVE-KeyPackage")
WScript.echo
WScript.echo "Recovery Object Name: " + strName
WScript.echo "Recovery Password: " + strRecoveryPassword
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists(strFilePathCurrent)) Then
WScript.Echo "The file " & strFilePathCurrent & " already exists. Please use a different path."
WScript.Quit -1
End If
' Save binary data to the file
SaveBinaryDataText strFilePathCurrent, strKeyPackage
WScript.echo "Related key package successfully saved to " + strFilePathCurrent
' Update next file path using base name
nCount = nCount + 1
strFilePathCurrent = strFilePath & nCount
Next
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")
'Create text stream object
Dim TextStream
Set TextStream = FS.CreateTextFile(FileName)
'Convert binary data To text And write them To the file
TextStream.Write BinaryToString(ByteArray)
End Function
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
S = S & Chr(AscB(MidB(Binary, I, 1)))
Next
BinaryToString = S
End Function
WScript.Quit
```
The following sample script exports a new key package from an unlocked, encrypted volume.
**To run the sample key package retrieval script**
1. Save the following sample script in a VBScript file. For example: GetBitLockerKeyPackage.vbs
2. Open an administrator command prompt, type a command similar to the following:
**cscript GetBitLockerKeyPackage.vbs -?**
``` syntax
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackage [VolumeLetter/DriveLetter:] [Path To Save Key Package]"
Wscript.Echo
Wscript.Echo "Example: GetBitLockerKeyPackage C: E:\bitlocker-backup-key-package"
WScript.Quit
End Sub
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
Set args = WScript.Arguments
Select Case args.Count
Case 2
If args(0) = "/?" Or args(0) = "-?" Then
ShowUsage
Else
strDriveLetter = args(0)
strFilePath = args(1)
End If
Case Else
ShowUsage
End Select
' --------------------------------------------------------------------------------
' Other Inputs
' --------------------------------------------------------------------------------
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
' Default key protector ID to use. Specify "" to let the script choose.
strDefaultKeyProtectorID = ""
' strDefaultKeyProtectorID = "{001298E0-870E-4BA0-A2FF-FC74758D5720}" ' sample
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
& "\root\cimv2\Security\MicrosoftVolumeEncryption"
On Error Resume Next 'handle permission errors
Set objWMIService = GetObject(strConnectionStr)
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
On Error GoTo 0
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " & strComputerName & "."
WScript.Quit -1
End If
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
' objVolume is now our found BitLocker-capable disk volume
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
' Collect all possible valid key protector ID's that can be used to get the package
' ----------------------------------------------------------------------------------
nNumericalKeyProtectorType = 3 ' type associated with "Numerical Password" protector
nRC = objVolume.GetKeyProtectors(nNumericalKeyProtectorType, aNumericalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
nExternalKeyProtectorType = 2 ' type associated with "External Key" protector
nRC = objVolume.GetKeyProtectors(nExternalKeyProtectorType, aExternalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Get first key protector of the type "Numerical Password" or "External Key", if any
' ----------------------------------------------------------------------------------
if strDefaultKeyProtectorID = "" Then
' Save first numerical password, if exists
If UBound(aNumericalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aNumericalKeyProtectorIDs(0)
End If
' No numerical passwords exist, save the first external key
If strDefaultKeyProtectorID = "" and UBound(aExternalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aExternalKeyProtectorIDs(0)
End If
' Fail case: no recovery key protectors exist.
If strDefaultKeyProtectorID = "" Then
WScript.Echo "FAILURE: Cannot create backup key package because no recovery passwords or recovery keys exist. Check that BitLocker protection is on for this drive."
WScript.Echo "For help adding recovery passwords or recovery keys, type ""manage-bde -protectors -add -?""."
WScript.Quit -1
End If
End If
' Get some information about the chosen key protector ID
' ----------------------------------------------------------------------------------
' is the type valid?
nRC = objVolume.GetKeyProtectorType(strDefaultKeyProtectorID, nDefaultKeyProtectorType)
If Hex(nRC) = "80070057" Then
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " is not valid."
WScript.Echo "This ID value may have been provided by the script writer."
ElseIf nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorType failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' what's a string that can be used to describe it?
strDefaultKeyProtectorType = ""
Select Case nDefaultKeyProtectorType
Case nNumericalKeyProtectorType
strDefaultKeyProtectorType = "recovery password"
Case nExternalKeyProtectorType
strDefaultKeyProtectorType = "recovery key"
Case Else
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " does not refer to a valid recovery password or recovery key."
WScript.Echo "This ID value may have been provided by the script writer."
End Select
' Save the backup key package using the chosen key protector ID
' ----------------------------------------------------------------------------------
nRC = objVolume.GetKeyPackage(strDefaultKeyProtectorID, oKeyPackage)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyPackage failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists(strFilePath)) Then
WScript.Echo "The file " & strFilePath & " already exists. Please use a different path."
WScript.Quit -1
End If
Dim oKeyPackageByte, bKeyPackage
For Each oKeyPackageByte in oKeyPackage
'WScript.echo "key package byte: " & oKeyPackageByte
bKeyPackage = bKeyPackage & ChrB(oKeyPackageByte)
Next
' Save binary data to the file
SaveBinaryDataText strFilePath, bKeyPackage
' Display helpful information
' ----------------------------------------------------------------------------------
WScript.Echo "The backup key package has been saved to " & strFilePath & "."
WScript.Echo "IMPORTANT: To use this key package, the " & strDefaultKeyProtectorType & " must also be saved."
' Display the recovery password or a note about saving the recovery key file
If nDefaultKeyProtectorType = nNumericalKeyProtectorType Then
nRC = objVolume.GetKeyProtectorNumericalPassword(strDefaultKeyProtectorID, sNumericalPassword)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
WScript.Echo "Save this recovery password: " & sNumericalPassword
ElseIf nDefaultKeyProtectorType = nExternalKeyProtectorType Then
WScript.Echo "The saved key file is named " & strDefaultKeyProtectorID & ".BEK"
WScript.Echo "For help re-saving this external key file, type ""manage-bde -protectors -get -?"""
End If
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")
'Create text stream object
Dim TextStream
Set TextStream = FS.CreateTextFile(FileName)
'Convert binary data To text And write them To the file
TextStream.Write BinaryToString(ByteArray)
End Function
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
S = S & Chr(AscB(MidB(Binary, I, 1)))
Next
BinaryToString = S
End Function
```
## See also
- [BitLocker overview](bitlocker-overview.md)
 
 

330
windows/security/information-protection/bitlocker/bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md Normal file
View File

@ -0,0 +1,330 @@
---
title: BitLocker Use BitLocker Drive Encryption Tools to manage BitLocker (Windows 10)
description: This topic for the IT professional describes how to use tools to manage BitLocker.
ms.assetid: e869db9c-e906-437b-8c70-741dd61b5ea6
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 09/25/2017
---
# BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker
**Applies to**
- Windows 10
This topic for the IT professional describes how to use tools to manage BitLocker.
BitLocker Drive Encryption Tools include the command line tools manage-bde and repair-bde and the BitLocker cmdlets for Windows PowerShell.
Both manage-bde and the BitLocker cmdlets can be used to perform any task that can be accomplished through the BitLocker control panel and are appropriate to use for automated deployments and other scripting scenarios.
Repair-bde is a special circumstance tool that is provided for disaster recovery scenarios in which a BitLocker protected drive cannot be unlocked normally or using the recovery console.
1. [Manage-bde](#bkmk-managebde)
2. [Repair-bde](#bkmk-repairbde)
3. [BitLocker cmdlets for Windows PowerShell](#bkmk-blcmdlets)
## <a href="" id="bkmk-managebde"></a>Manage-bde
Manage-bde is a command-line tool that can be used for scripting BitLocker operations. Manage-bde offers additional options not displayed in the BitLocker control panel. For a complete list of the manage-bde options, see the [Manage-bde](https://technet.microsoft.com/library/ff829849.aspx) command-line reference.
Manage-bde includes less default settings and requires greater customization for configuring BitLocker. For example, using just the `manage-bde -on` command on a data volume will fully encrypt the volume without any authenticating protectors. A volume encrypted in this manner still requires user interaction to turn on BitLocker protection, even though the command successfully completed because an authentication method needs to be added to the volume for it to be fully protected. The following sections provide examples of common usage scenarios for manage-bde.
### Using manage-bde with operating system volumes
Listed below are examples of basic valid commands for operating system volumes. In general, using only the `manage-bde -on <drive letter>` command will encrypt the operating system volume with a TPM-only protector and no recovery key. However, many environments require more secure protectors such as passwords or PIN and expect to be able to recover information with a recovery key. It is recommended that at least one primary protector and a recovery protector be added to an operating system volume.
A good practice when using manage-bde is to determine the volume status on the target system. Use the following command to determine volume status:
``` syntax
manage-bde -status
```
This command returns the volumes on the target, current encryption status, encryption method, and volume type (operating system or data) for each volume:
![Using manage-bde to check encryption status](images/manage-bde-status.png)
The following example illustrates enabling BitLocker on a computer without a TPM chip. Before beginning the encryption process you must create the startup key needed for BitLocker and save it to the USB drive. When BitLocker is enabled for the operating system volume, the BitLocker will need to access the USB flash drive to obtain the encryption key (in this example, the drive letter E represents the USB drive). You will be prompted to reboot to complete the encryption process.
``` syntax
manage-bde –protectors -add C: -startupkey E:
manage-bde -on C:
```
>**Note:**  After the encryption is completed, the USB startup key must be inserted before the operating system can be started.
 
An alternative to the startup key protector on non-TPM hardware is to use a password and an **ADaccountorgroup** protector to protect the operating system volume. In this scenario, you would add the protectors first. This is done with the command:
``` syntax
manage-bde -protectors -add C: -pw -sid <user or group>
```
This command will require you to enter and then confirm the password protector before adding them to the volume. With the protectors enabled on the volume, you can then turn BitLocker on.
On computers with a TPM it is possible to encrypt the operating system volume without any defined protectors using manage-bde. The command to do this is:
``` syntax
manage-bde -on C:
```
This will encrypt the drive using the TPM as the default protector. If you are not sure if a TPM protector is available, to list the protectors available for a volume, run the following command:
``` syntax
manage-bde -protectors -get <volume>
```
### Using manage-bde with data volumes
Data volumes use the same syntax for encryption as operating system volumes but they do not require protectors for the operation to complete. Encrypting data volumes can be done using the base command: `manage-bde -on <drive letter>` or you can choose to add additional protectors to the volume first. It is recommended that at least one primary protector and a recovery protector be added to a data volume.
A common protector for a data volume is the password protector. In the example below, we add a password protector to the volume and turn BitLocker on.
``` syntax
manage-bde -protectors -add -pw C:
manage-bde -on C:
```
## <a href="" id="bkmk-repairbde"></a>Repair-bde
You may experience a problem that damages an area of a hard disk on which BitLocker stores critical information. This kind of problem may be caused by a hard disk failure or if Windows exits unexpectedly.
The BitLocker Repair Tool (Repair-bde) can be used to access encrypted data on a severely damaged hard disk if the drive was encrypted by using BitLocker. Repair-bde can reconstruct critical parts of the drive and salvage recoverable data as long as a valid recovery password or recovery key is used to decrypt the data. If the BitLocker metadata data on the drive has become corrupt, you must be able to supply a backup key package in addition to the recovery password or recovery key. This key package is backed up in Active Directory Domain Services (AD DS) if you used the default setting for AD DS backup. With this key package and either the recovery password or recovery key, you can decrypt portions of a BitLocker-protected drive if the disk is corrupted. Each key package will work only for a drive that has the corresponding drive identifier. You can use the BitLocker Recovery Password Viewer to obtain this key package from AD DS.
>**Tip:**  If you are not backing up recovery information to AD DS or if you want to save key packages alternatively, you can use the command `manage-bde -KeyPackage` to generate a key package for a volume.
 
The Repair-bde command-line tool is intended for use when the operating system does not start or when you cannot start the BitLocker Recovery Console. You should use Repair-bde if the following conditions are true:
1. You have encrypted the drive by using BitLocker Drive Encryption.
2. Windows does not start, or you cannot start the BitLocker recovery console.
3. You do not have a copy of the data that is contained on the encrypted drive.
>**Note:**  Damage to the drive may not be related to BitLocker. Therefore, we recommend that you try other tools to help diagnose and resolve the problem with the drive before you use the BitLocker Repair Tool. The Windows Recovery Environment (Windows RE) provides additional options to repair computers.
 
The following limitations exist for Repair-bde:
- The Repair-bde command-line tool cannot repair a drive that failed during the encryption or decryption process.
- The Repair-bde command-line tool assumes that if the drive has any encryption, then the drive has been fully encrypted.
For more information about using repair-bde, see [Repair-bde](http://technet.microsoft.com/library/ff829851.aspx).
## <a href="" id="bkmk-blcmdlets"></a>BitLocker cmdlets for Windows PowerShell
Windows PowerShell cmdlets provide a new way for administrators to use when working with BitLocker. Using Windows PowerShell's scripting capabilities, administrators can integrate BitLocker options into existing scripts with ease. The list below displays the available BitLocker cmdlets.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><strong>Name</strong></p></td>
<td align="left"><p><strong>Parameters</strong></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Add-BitLockerKeyProtector</strong></p></td>
<td align="left"><p>-ADAccountOrGroup</p>
<p>-ADAccountOrGroupProtector</p>
<p>-Confirm</p>
<p>-MountPoint</p>
<p>-Password</p>
<p>-PasswordProtector</p>
<p>-Pin</p>
<p>-RecoveryKeyPath</p>
<p>-RecoveryKeyProtector</p>
<p>-RecoveryPassword</p>
<p>-RecoveryPasswordProtector</p>
<p>-Service</p>
<p>-StartupKeyPath</p>
<p>-StartupKeyProtector</p>
<p>-TpmAndPinAndStartupKeyProtector</p>
<p>-TpmAndPinProtector</p>
<p>-TpmAndStartupKeyProtector</p>
<p>-TpmProtector</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Backup-BitLockerKeyProtector</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-KeyProtectorId</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Disable-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Disable-BitLockerAutoUnlock</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Enable-BitLocker</strong></p></td>
<td align="left"><p>-AdAccountOrGroup</p>
<p>-AdAccountOrGroupProtector</p>
<p>-Confirm</p>
<p>-EncryptionMethod</p>
<p>-HardwareEncryption</p>
<p>-Password</p>
<p>-PasswordProtector</p>
<p>-Pin</p>
<p>-RecoveryKeyPath</p>
<p>-RecoveryKeyProtector</p>
<p>-RecoveryPassword</p>
<p>-RecoveryPasswordProtector</p>
<p>-Service</p>
<p>-SkipHardwareTest</p>
<p>-StartupKeyPath</p>
<p>-StartupKeyProtector</p>
<p>-TpmAndPinAndStartupKeyProtector</p>
<p>-TpmAndPinProtector</p>
<p>-TpmAndStartupKeyProtector</p>
<p>-TpmProtector</p>
<p>-UsedSpaceOnly</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Enable-BitLockerAutoUnlock</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Get-BitLockerVolume</strong></p></td>
<td align="left"><p>-MountPoint</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Lock-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-ForceDismount</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Remove-BitLockerKeyProtector</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-KeyProtectorId</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Resume-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-WhatIf</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Suspend-BitLocker</strong></p></td>
<td align="left"><p>-Confirm</p>
<p>-MountPoint</p>
<p>-RebootCount</p>
<p>-WhatIf</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Unlock-BitLocker</strong></p></td>
<td align="left"><p>-AdAccountOrGroup</p>
<p>-Confirm</p>
<p>-MountPoint</p>
<p>-Password</p>
<p>-RecoveryKeyPath</p>
<p>-RecoveryPassword</p>
<p>-RecoveryPassword</p>
<p>-WhatIf</p></td>
</tr>
</tbody>
</table>
 
Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting prior to running Windows PowerShell cmdlets.
A good initial step is to determine the current state of the volume(s) on the computer. You can do this using the `Get-BitLockerVolume` cmdlet.
The `Get-BitLockerVolume` cmdlet output gives information on the volume type, protectors, protection status and other details.
>**Tip:**  Occasionally, all protectors may not be shown when using `Get-BitLockerVolume` due to lack of space in the output display. If you do not see all of the protectors for a volume, you can use the Windows PowerShell pipe command (|) to format a full listing of the protectors.
`Get-BitLockerVolume C: | fl`
 
If you want to remove the existing protectors prior to provisioning BitLocker on the volume, you could use the `Remove-BitLockerKeyProtector` cmdlet. Accomplishing this requires the GUID associated with the protector to be removed.
A simple script can pipe the values of each Get-BitLockerVolume return out to another variable as seen below:
``` syntax
$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector
```
Using this, you can display the information in the $keyprotectors variable to determine the GUID for each protector.
Using this information, you can then remove the key protector for a specific volume using the command:
``` syntax
Remove-BitLockerKeyProtector <volume>: -KeyProtectorID "{GUID}"
```
>**Note:**  The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure the entire GUID, with braces, is included in the command.
 
### Using the BitLocker Windows PowerShell cmdlets with operating system volumes
Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the desired protector as part command for encrypting the volume. Below are examples of common user scenarios and steps to accomplish them in BitLocker Windows PowerShell.
The following example shows how to enable BitLocker on an operating system drive using only the TPM protector:
``` syntax
Enable-BitLocker C:
```
In the example below, adds one additional protector, the StartupKey protector and chooses to skip the BitLocker hardware test. In this example, encryption starts immediately without the need for a reboot.
``` syntax
Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath <path> -SkipHardwareTest
```
### Using the BitLocker Windows PowerShell cmdlets with data volumes
Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add the desired protectors prior to encrypting the volume. The following example adds a password protector to the E: volume using the variable $pw as the password. The $pw variable is held as a
SecureString value to store the user defined password.
``` syntax
$pw = Read-Host -AsSecureString
<user inputs password>
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw
```
### Using an AD Account or Group protector in Windows PowerShell
The **ADAccountOrGroup** protector, introduced in Windows 8 and Windows Server 2012, is an Active Directory SID-based protector. This protector can be added to both operating system and data volumes, although it does not unlock operating system volumes in the pre-boot environment. The protector requires the SID for the domain account or group to link with the protector. BitLocker can protect a cluster-aware disk by adding a SID-based protector for the Cluster Name Object (CNO) that lets the disk properly failover to and be unlocked by any member computer of the cluster.
>**Warning:**  The **ADAccountOrGroup** protector requires the use of an additional protector for use (such as TPM, PIN, or recovery key) when used on operating system volumes
 
To add an **ADAccountOrGroup** protector to a volume requires either the actual domain SID or the group name preceded by the domain and a backslash. In the example below, the CONTOSO\\Administrator account is added as a protector to the data volume G.
``` syntax
Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator
```
For users who wish to use the SID for the account or group, the first step is to determine the SID associated with the account. To get the specific SID for a user account in Windows PowerShell, use the following command:
>**Note:**  Use of this command requires the RSAT-AD-PowerShell feature.
 
``` syntax
get-aduser -filter {samaccountname -eq "administrator"}
```
>**Tip:**  In addition to the PowerShell command above, information about the locally logged on user and group membership can be found using: WHOAMI /ALL. This does not require the use of additional features.
 
The following example adds an **ADAccountOrGroup** protector to the previously encrypted operating system volume using the SID of the account:
``` syntax
Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup S-1-5-21-3651336348-8937238915-291003330-500
```
>**Note:**  Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.
 
## More information
- [BitLocker overview](bitlocker-overview.md)
- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
- [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
- [BitLocker: How to deploy on Windows Server 2012](bitlocker-how-to-deploy-on-windows-server.md)

58
windows/security/information-protection/bitlocker/bitlocker-use-bitlocker-recovery-password-viewer.md Normal file
View File

@ -0,0 +1,58 @@
---
title: BitLocker Use BitLocker Recovery Password Viewer (Windows 10)
description: This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer.
ms.assetid: 04c93ac5-5dac-415e-b636-de81435753a2
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 04/19/2017
---
# BitLocker: Use BitLocker Recovery Password Viewer
**Applies to**
- Windows 10
This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer.
The BitLocker Recovery Password Viewer tool is an optional tool included with the Remote Server Administration Tools (RSAT). It lets you locate and view BitLocker recovery passwords that are stored in Active Directory Domain Services (AD DS). You can use this tool to help recover data that is stored on a drive that has been encrypted by using BitLocker. The BitLocker Active Directory Recovery Password Viewer tool is an extension for the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. Using this tool, you can examine a computer object's **Properties** dialog box to view the corresponding BitLocker recovery passwords. Additionally, you can right-click a domain container and then search for a BitLocker recovery password across all the domains in the Active Directory forest. You can also search for a password by password identifier (ID).
## Before you start
To complete the procedures in this scenario:
- You must have domain administrator credentials.
- Your test computers must be joined to the domain.
- On the test computers, BitLocker must have been turned on after joining the domain.
The following procedures describe the most common tasks performed by using the BitLocker Recovery Password Viewer.
**To view the recovery passwords for a computer**
1. In **Active Directory Users and Computers**, locate and then click the container in which the computer is located.
2. Right-click the computer object, and then click **Properties**.
3. In the **Properties** dialog box, click the **BitLocker Recovery** tab to view the BitLocker recovery passwords that are associated with the computer.
**To copy the recovery passwords for a computer**
1. Follow the steps in the previous procedure to view the BitLocker recovery passwords.
2. On the **BitLocker Recovery** tab of the **Properties** dialog box, right-click the BitLocker recovery password that you want to copy, and then click **Copy Details**.
3. Press CTRL+V to paste the copied text to a destination location, such as a text file or spreadsheet.
**To locate a recovery password by using a password ID**
1. In Active Directory Users and Computers, right-click the domain container, and then click **Find BitLocker Recovery Password**.
2. In the **Find BitLocker Recovery Password** dialog box, type the first eight characters of the recovery password in the **Password ID (first 8 characters)** box, and then click **Search**.
By completing the procedures in this scenario, you have viewed and copied the recovery passwords for a computer and used a password ID to locate a recovery password.
## More information
- [BitLocker Overview](bitlocker-overview.md)
- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
- [BitLocker: How to deploy on Windows Server 2012](bitlocker-how-to-deploy-on-windows-server.md)
- [BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md)
 
 

138
windows/security/information-protection/bitlocker/choose-the-right-bitlocker-countermeasure.md Normal file
View File

@ -0,0 +1,138 @@
---
title: Choose the right BitLocker countermeasure (Windows 10)
description: This section outlines the best countermeasures you can use to protect your organization from bootkits and rootkits, brute force sign-in, Direct Memory Access (DMA) attacks, Hyberfil.sys attacks, and memory remanence attacks.
ms.assetid: b0b09508-7885-4030-8c61-d91458afdb14
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 10/27/2017
---
# Choose the right BitLocker countermeasure
**Applies to**
- Windows 10
This section outlines the best countermeasures you can use to protect your organization from bootkits and rootkits, brute force sign-in, Direct Memory Access (DMA) attacks, Hyberfil.sys attacks, and memory remanence attacks.
You can use BitLocker to protect your Windows 10 PCs. Whichever operating system you’re using, Microsoft and Windows-certified devices provide countermeasures to address attacks and improve your data security. In most cases, this protection can be implemented without the need for pre-boot authentication.
Tables 1 and 2 summarize the recommended mitigations for different types of attacks against PCs running recent versions of Windows. The orange blocks indicate that the system requires additional configuration from the default settings.
<table>
<colgroup>
<col width="20%" />
<col width="25%" />
<col width="55%" />
</colgroup>
<tr>
<td></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 8.1<br>without TPM</strong></font></p></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 8.1 Certified<br>(with TPM)</strong></font></p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Bootkits and<br>Rootkits</p></font></td>
<td BGCOLOR="#FED198"><p>Without TPM, boot integrity checking is not available</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default when UEFI-based Secure Boot is enabled and a firmware password is required to change settings</p></td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Brute Force<br>Sign-in</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout Group Policy</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout and device lockout Group Policy settings</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">DMA<br>Attacks</p></font></td>
<td BGCOLOR="#99E4FB"><p>If policy is deployed, secure by default for all lost or stolen devices because new DMA devices are granted access only when an authorized user is signed in</p></td>
<td BGCOLOR="#99E4FB"><p>If policy is deployed, secure by default for all lost or stolen devices because new DMA devices are granted access only when an authorized user is signed in</p></td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Hyberfil.sys<br>Attacks</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Memory<br>Remanence<br>Attacks</p></font></td>
<td BGCOLOR="#FED198"><p>Password protect the firmware and disable booting from external media. If an attack is viable, consider pre-boot authentication</p></td>
<td BGCOLOR="#99E4FB"><p>Password protect the firmware and ensure Secure Boot is enabled. If an attack is viable, consider pre-boot authentication</p></td>
</tr>
</table>
**Table 1.**&nbsp;&nbsp;How to choose the best countermeasures for Windows 8.1<br><br>
<table>
<colgroup>
<col width="20%" />
<col width="25%" />
<col width="55%" />
</colgroup>
<tr>
<td></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 10<br>without TPM</strong></font></p></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 10 Certified<br>(with TPM)</strong></font></p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Bootkits and<br>Rootkits</p></font></td>
<td BGCOLOR="#FED198"><p>Without TPM, boot integrity checking is not available</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default when UEFI-based Secure Boot is enabled and a firmware password is required to change settings</p></td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Brute Force<br>Sign-in</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout Group Policy</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout and device lockout Group Policy settings</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">DMA<br>Attacks</p></font></td>
<td BGCOLOR="#99E4FB"><p>If policy is deployed, secure by default for all lost or stolen devices because new DMA devices are granted access only when an authorized user is signed in</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; certified devices do not expose vulnerable DMA busses.<br>Can be additionally secured by deploying policy to restrict DMA devices:</p>
<ul>
<li><p><a href="https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#DataProtection_AllowDirectMemoryAccess">DataProtection/AllowDirectMemoryAccess</a></p></li>
<li><p><a href="https://support.microsoft.com/en-us/kb/2516445">Block 1394 and Thunderbolt</a></p></li></ul>
</td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Hyberfil.sys<br>Attacks</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Memory<br>Remanence<br>Attacks</p></font></td>
<td BGCOLOR="#FED198"><p>Password protect the firmware and disable booting from external media. If an attack is viable, consider pre-boot authentication</p></td>
<td BGCOLOR="#99E4FB"><p>Password protect the firmware and ensure Secure Boot is enabled.<br>The most effective mitigation, which we advise for high-security devices, is to configure a TPM+PIN protector, disable Standby power management, and shut down or hibernate the device before it leaves the control of an authorized user.</p></td>
</tr>
</table>
**Table 2.**&nbsp;&nbsp;How to choose the best countermeasures for Windows 10
The latest Modern Standby devices, primarily tablets, are designed to be secure by default against all attacks that might compromise the BitLocker encryption key. Other Windows devices can be secure by default too. DMA port–based attacks, which represent the attack vector of choice, are not possible on Modern Standby devices because these port types are prohibited. The inclusion of DMA ports on even non-Modern Standby devices is extremely rare on recent devices, particularly on mobile ones. This could change if Thunderbolt is broadly adopted, so IT should consider this when purchasing new devices. In any case, DMA ports can be disabled entirely, which is an increasingly popular option because the use of DMA ports is infrequent in the non-developer space. To prevent DMA port usage unless an authorized user is signed in, you can set the DataProtection/AllowDirectMemoryAccess policy by using Mobile Device Management (MDM) or the Group Policy setting **Disable new DMA devices when this computer is locked** (beginning with Windows 10, version 1703). This setting is **Not configured** by default. The path to the Group Policy setting is:
**Computer Configuration|Administrative Templates|Windows Components|BitLocker Drive Encryption**
Memory remanence attacks can be mitigated with proper configuration; in cases where the system memory is fixed and non-removable, they are not possible using published techniques. Even in cases where system memory can be removed and loaded into another device, attackers will find the attack vector extremely unreliable, as has been shown in the DRDC Valcartier group’s analysis (see [An In-depth Analysis of the Cold Boot Attack](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078)).
Windows 7 PCs share the same security risks as newer devices but are far more vulnerable to DMA and memory remanence attacks, because Windows 7 devices are more likely to include DMA ports, lack support for UEFI-based Secure Boot, and rarely have fixed memory. To eliminate the need for pre-boot authentication on Windows 7 devices, disable the ability to boot to external media, password-protect the BIOS configuration, and disable the DMA ports. If you believe that your devices may be a target of a memory remanence attack, where the system memory may be removed and put into another computer to gain access to its contents, consider testing your devices to determine whether they are susceptible to this type of attack.
In the end, many customers will find that pre-boot authentication improves security only for a shrinking subset of devices within their organization. Microsoft recommends a careful examination of the attack vectors and mitigations
outlined in this document along with an evaluation of your devices before choosing to implement pre-boot authentication, which may not enhance the security of your devices and instead will only compromise the user experience and add to support costs.
## See also
- [Types of attacks for volume encryption keys](types-of-attacks-for-volume-encryption-keys.md)
- [BitLocker Countermeasures](bitlocker-countermeasures.md)
- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
- [BitLocker overview](bitlocker-overview.md)
 
 

BIN
windows/security/information-protection/bitlocker/images/bitlockernetworkunlocksequence.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.0 KiB

BIN
windows/security/information-protection/bitlocker/images/bitlockerprebootprotection-bios-uefi-startup.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
windows/security/information-protection/bitlocker/images/bitlockerprebootprotection-counterwin7.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 95 KiB

BIN
windows/security/information-protection/bitlocker/images/bitlockerprebootprotection-counterwin8.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 97 KiB

BIN
windows/security/information-protection/bitlocker/images/bitlockerprebootprotection-counterwin81.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 98 KiB

BIN
windows/security/information-protection/bitlocker/images/feedback-app-icon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 933 B

BIN
windows/security/information-protection/bitlocker/images/manage-bde-status.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

253
windows/security/information-protection/bitlocker/prepare-your-organization-for-bitlocker-planning-and-policies.md Normal file
View File

@ -0,0 +1,253 @@
---
title: Prepare your organization for BitLocker Planning and policies (Windows 10)
description: This topic for the IT professional explains how can you plan your BitLocker deployment.
ms.assetid: 6e3593b5-4e8a-40ac-808a-3fdbc948059d
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 04/19/2017
---
# Prepare your organization for BitLocker: Planning and policies
**Applies to**
- Windows 10
This topic for the IT professional explains how can you plan your BitLocker deployment.
When you design your BitLocker deployment strategy, define the appropriate policies and configuration requirements based on the business requirements of your organization. The following topics will help you collect information that you can use to frame your decision-making process about deploying and managing BitLocker systems.
- [Audit your environment](#bkmk-audit)
- [Encryption keys and authentication](#bkk-encrypt)
- [TPM hardware configurations](#bkmk-tpmconfigurations)
- [Non-TPM hardware configurations](#bkmk-nontpm)
- [Disk configuration considerations](#bkmk-disk)
- [BitLocker provisioning](#bkmk-prov)
- [Used Disk Space Only encryption](#bkk-used)
- [Active Directory Domain Services considerations](#bkmk-addscons)
- [FIPS support for recovery password protector](#bkmk-fipssupport)
- [BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
## <a href="" id="bkmk-audit"></a>Audit your environment
To plan your enterprise deployment of BitLocker, you must first understand your current environment. Conduct an informal audit to define your current policies, procedures, and hardware environment. Begin by reviewing your existing corporate security policies as they relate to disk encryption software. If your organization is not currently using disk encryption software, none of these policies will exist. If you are using disk encryption software, then you might need to modify your organization's policies to address the capabilities of BitLocker.
Use the following questions to help you document your organization's current disk encryption security policies:
1. Are there policies to address which computers will use BitLocker and which computers will not use BitLocker?
2. What policies exist to control recovery password and recovery key storage?
3. What are the policies for validating the identity of users that need to perform BitLocker recovery?
4. What policies exist to control who in the organization has access to recovery data?
5. What policies exist to control computer decommissioning or retirement?
## <a href="" id="bkk-encrypt"></a>Encryption keys and authentication
BitLocker helps prevent unauthorized access to data on lost or stolen computers by:
- Encrypting the entire Windows operating system volume on the hard disk.
- Verifying the boot process integrity.
The trusted platform module (TPM) is a hardware component installed in many newer computers by the computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not been tampered with while the system was offline.
In addition, BitLocker offers the option to lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable USB device, such as a flash drive, that contains a startup key. These additional security measures provide multifactor authentication and assurance that the computer will not start or resume from hibernation until the correct PIN or startup key is presented.
On computers that do not have a TPM version 1.2 or higher, you can still use BitLocker to encrypt the Windows operating system volume. However, this implementation will require the user to insert a USB startup key to start the computer or resume from hibernation, and does not provide the pre-startup system integrity verification offered by BitLocker working with a TPM.
### BitLocker key protectors
| Key protector | Description |
| - | - |
| TPM | A hardware device used to help establish a secure root-of-trust. BitLocker only supports TPM version 1.2 or higher.|
| PIN | A user-entered numeric key protector that can only be used in addition to the TPM.|
| Enhanced PIN | A user-entered alphanumeric key protector that can only be used in addition to the TPM.|
| Startup key | An encryption key that can be stored on most removable media. This key protector can be used alone on non-TPM computers, or in conjunction with a TPM for added security.|
| Recovery password | A 48-digit number used to unlock a volume when it is in recovery mode. Numbers can often be typed on a regular keyboard, if the numbers on the normal keyboard are not responding you can always use the function keys (F1-F10) to input the numbers.|
| Recovery key| An encryption key stored on removable media that can be used for recovering data encrypted on a BitLocker volume.|
 
### BitLocker authentication methods
| Authentication method | Requires user interaction | Description |
| - | - | - |
| TPM only| No| TPM validates early boot components.|
| TPM + PIN | Yes| TPM validates early boot components. The user must enter the correct PIN before the start-up process can continue, and before the drive can be unlocked. The TPM will enter lockout if the incorrect PIN is entered repeatedly to protect the PIN from brute force attacks. The number of repeated attempts that will trigger a lockout is variable.|
| TPM + Network key | No | The TPM successfully validates early boot components, and a valid encrypted network key has been provided from the WDS server. This authentication method provides automatic unlock of operating system volumes at system reboot while still maintaining multifactor authentication. |
| TPM + startup key| Yes| The TPM successfully validates early boot components, and a USB flash drive containing the startup key has been inserted.|
| Startup key only | Yes| The user is prompted to insert the USB flash drive that holds the recovery key and/or startup key and reboot the computer.|
 
**Will you support computers without TPM version 1.2 or higher?**
Determine whether you will support computers that do not have a TPM version 1.2 or higher in your environment. If you choose to support BitLocker on this type of computer, a user must use a USB startup key to boot the system. This requires additional support processes similar to multifactor authentication.
**What areas of your organization need a baseline level of data protection?**
The TPM-only authentication method will provide the most transparent user experience for organizations that need a baseline level of data protection to meet security policies. It has the lowest total cost of ownership. TPM-only might also be more appropriate for computers that are unattended or that must reboot unattended.
However, TPM-only authentication method offers the lowest level of data protection. This authentication method protects against attacks that modify early boot components, but the level of protection can be affected by potential weaknesses in hardware or in the early boot components. BitLocker’s multifactor authentication methods significantly increase the overall level of data protection.
**What areas of your organization need a more secure level of data protection?**
If there are areas of your organization where data residing on user computers is considered highly-sensitive, consider the best practice of deploying BitLocker with multifactor authentication on those systems. Requiring the user to input a PIN significantly increases the level of protection for the system. You can also use BitLocker Network Unlock to allow these computers to automatically unlock when connected to a trusted wired network that can provide the Network Unlock key.
**What multifactor authentication method does your organization prefer?**
The protection differences provided by multifactor authentication methods cannot be easily quantified. Consider each authentication method's impact on Helpdesk support, user education, user productivity, and automated systems management processes.
## <a href="" id="bkmk-tpmconfigurations"></a>TPM hardware configurations
In your deployment plan, identify what TPM-based hardware platforms will be supported. Document the hardware models from an OEM of your choice, so that their configurations can be tested and supported. TPM hardware requires special consideration during all aspects of planning and deployment.
### TPM 1.2 states and initialization
For TPM 1.2, there are multiple possible states. Windows 10 automatically initializes the TPM, which brings it to an enabled, activated, and owned state. This is the state that BitLocker requires before it can use the TPM.
### Endorsement keys
For a TPM to be usable by BitLocker, it must contain an endorsement key, which is an RSA key pair. The private half of the key pair is held inside the TPM and is never revealed or accessible outside the TPM. If the TPM does not contain an endorsement key, BitLocker will force the TPM to generate one automatically as part of BitLocker setup.
An endorsement key can be created at various points in the TPM’s lifecycle, but needs to be created only once for the lifetime of the TPM. If an endorsement key does not exist for the TPM, it must be created before TPM ownership can be taken.
For more information about the TPM and the TCG, see the Trusted Computing Group: Trusted Platform Module (TPM) Specifications (<https://go.microsoft.com/fwlink/p/?linkid=69584>).
## <a href="" id="bkmk-nontpm"></a>Non-TPM hardware configurations
Devices that do not include a TPM can still be protected by drive encryption. Windows To Go workspaces can be BitLocker protected using a startup password and PCs without a TPM can use a startup key.
Use the following questions to identify issues that might affect your deployment in a non-TPM configuration:
- Are password complexity rules in place?
- Do you have budget for USB flash drives for each of these computers?
- Do your existing non-TPM devices support USB devices at boot time?
Test your individual hardware platforms with the BitLocker system check option while you are enabling BitLocker. The system check will ensure that BitLocker can read the recovery information from a USB device and encryption keys correctly before it encrypts the volume. CD and DVD drives cannot act as a block storage device and cannot be used to store the BitLocker recovery material.
## <a href="" id="bkmk-disk"></a>Disk configuration considerations
To function correctly, BitLocker requires a specific disk configuration. BitLocker requires two partitions that meet the following requirements:
- The operating system partition contains the operating system and its support files; it must be formatted with the NTFS file system
- The system partition (or boot partition) contains the files that are needed to load Windows after the BIOS or UEFI firware has prepared the system hardware. BitLocker is not enabled on this partition. For BitLocker to work, the system partition must not be encrypted and must be on a different partition than the operating system. On UEFI platforms the system partition must be formatted with the FAT 32 file system. On BIOS platforms the system partition must be formatted with the NTFS file system. It should be at least 350 MB in size
Windows setup will automatically configure the disk drives of your computer to support BitLocker encryption.
Windows Recovery Environment (Windows RE) is an extensible recovery platform that is based on Windows Pre-installation Environment (Windows PE). When the computer fails to start, Windows automatically transitions into this environment, and the Startup Repair tool in Windows RE automates the diagnosis and repair of an unbootable Windows installation. Windows RE also contains the drivers and tools that are needed to unlock a volume protected by BitLocker by providing a recovery key or recovery password. To use Windows RE in conjunction with BitLocker, the Windows RE boot image must reside on a volume that is not protected by BitLocker.
Windows RE can also be used from boot media other than the local hard disk. If you choose not to install Windows RE on the local hard disk of BitLocker-enabled computers, you can use alternate boot methods, such as Windows Deployment Services, CD-ROM, or USB flash drive, for recovery.
## <a href="" id="bkmk-prov"></a>BitLocker provisioning
In Windows Vista and Windows 7, BitLocker was provisioned post installation for system and data volumes through either the manage-bde command line interface or the Control Panel user interface. With newer operating systems, BitLocker can be easily provisioned before the operating system is installed. Preprovisioning requires that the computer have a TPM.
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the BitLocker control panel applet or Windows Explorer. A status of "Waiting For Activation" with a yellow exclamation icon means that the drive was preprovisioned for BitLocker. This status means that there was only a clear protector used when encrypting the volume. In this case, the volume is not protected and needs to have a secure key added to the volume before the drive is considered fully protected. Administrators can use the control panel options, manage-bde tool or WMI APIs to add an appropriate key protector and the volume status will be updated.
When using the control panel options, administrators can choose to **Turn on BitLocker** and follow the steps in the wizard to add a protector, such as a PIN for an operating system volume (or a password if no TPM exists), or a password or smart card protector to a data volume. Then the drive security window is presented prior to changing the volume status.
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation Environment (WinPE). This is done with a randomly generated clear key protector applied to the formatted volume and encrypting the volume prior to running the Windows setup process. If the encryption uses the Used Disk Space Only option this step takes only a few seconds and so incorporates well into regular deployment processes.
## <a href="" id="bkk-used"></a>Used Disk Space Only encryption
The BitLocker Setup wizard provides administrators the ability to choose the Used Disk Space Only or Full encryption method when enabling BitLocker for a volume. Administrators can use the new BitLocker Group Policy setting to enforce either Used Disk Space Only or Full disk encryption.
Launching the BitLocker Setup wizard prompts for the authentication method to be used (password and smart card are available for data volumes). Once the method is chosen and the recovery key is saved, you are asked to choose the drive encryption type, either Used Disk Space Only or Full drive encryption.
Used Disk Space Only means that only the portion of the drive that contains data will be encrypted, unused space will remain unencrypted. This causes the encryption process to be much faster, especially for new PCs and data drives. When BitLocker is enabled with this method as data is added to the drive the portion of the drive used will be encrypted, so there is never unencrypted data stored on the drive.
Full drive encryption means that the entire drive will be encrypted, regardless of whether data is stored on it or not. This is useful for drives that have been repurposed and may contain data remnants from their previous use.
## <a href="" id="bkmk-addscons"></a>Active Directory Domain Services considerations
BitLocker integrates with Active Directory Domain Services (AD DS) to provide centralized key management. By default, no recovery information is backed up to Active Directory. Administrators can configure Group Policy settings to enable backup of BitLocker or TPM recovery information. Before configuring these settings verify that access permissions have been granted to perform the backup.
By default, domain administrators are the only users that will have access to BitLocker recovery information. When you plan your support process, define what parts of your organization need access to BitLocker recovery information. Use this information to define how the appropriate rights will be delegated in your AD DS environment.
It is a best practice to require backup of recovery information for both the TPM and BitLocker to AD DS. You can implement this practice by configuring the Group Policy settings below for your BitLocker-protected computers.
| BitLocker Group Policy setting | Configuration |
| - | - |
| BitLocker Drive Encryption: Turn on BitLocker backup to Active Directory Domain Services| Require BitLocker backup to AD DS (Passwords and key packages)|
| Trusted Platform Module Services: Turn on TPM backup to Active Directory Domain Services | Require TPM backup to AD DS|
 
The following recovery data will be saved for each computer object:
- **Recovery password**
A 48-digit recovery password used to recover a BitLocker-protected volume. Users enter this password to unlock a volume when BitLocker enters recovery mode.
- **Key package data**
With this key package and the recovery password, you will be able decrypt portions of a BitLocker-protected volume if the disk is severely damaged. Each key package will only work with the volume it was created on, which can be identified by the corresponding volume ID.
- **TPM owner authorization password hash**
When ownership of the TPM is taken a hash of the ownership password can be taken and stored in AD DS. This information can then be used to reset ownership of the TPM.
Starting in Windows 8, a change to how the TPM owner authorization value is stored in AD DS was implemented in the AD DS schema. The TPM owner authorization value is now stored in a separate object which is linked to the Computer object. This value was stored as a property in the Computer object itself for the default Windows Server 2008 R2 and later schemas.
To take advantage of this integration, you must upgrade your domain controllers to Windows Server 2012 or extend the Active Directory schema and configure BitLocker-specific Group Policy objects.
>**Note:**  The account that you use to update the Active Directory schema must be a member of the Schema Admins group.
 
Windows Server 2012 domain controllers have the default schema to backup TPM owner authorization information in the separate object. If you are not upgrading your domain controller to Windows Server 2012 you need to extend the schema to support this change.
**To support Windows 8 and later computers that are managed by a Windows Server 2003 or Windows 2008 domain controller**
There are two schema extensions that you can copy down and add to your AD DS schema:
- **TpmSchemaExtension.ldf**
This schema extension brings parity with the Windows Server 2012 schema. With this change, the TPM owner authorization information is stored in a separate TPM object linked to the corresponding computer object. Only the Computer object that has created the TPM object can update it. This means that any subsequent updates to the TPM objects will not succeed in dual boot scenarios or scenarios where the computer is reimaged resulting in a new AD computer object being created. To support such scenarios, an update to the schema was created.
- **TpmSchemaExtensionACLChanges.ldf**
This schema update modifies the ACLs on the TPM object to be less restrictive so that any subsequent operating system which takes ownership of the computer object can update the owner authorization value in AD DS. However, this is less secure as any computer in the domain can now update the OwnerAuth of the TPM object (although it cannot read the OwnerAuth) and DOS attacks can be made from within the enterprise. The recommended mitigation in such a scenario is to do regular backup of TPM objects and enable auditing to track changes for these objects.
To download the schema extensions, see [AD DS schema extensions to support TPM backup](https://technet.microsoft.com/library/jj635854.aspx).
If you have a Windows Server 2012 domain controller in your environment, the schema extensions are already in place and do not need to be updated.
>**Caution:**  To configure Group Policy objects to backup TPM and BitLocker information in AD DS at least one of the domain controllers in your forest must be running at least Windows Server 2008 R2.
If Active Directory backup of the TPM owner authorization value is enabled in an environment without the required schema extensions, the TPM provisioning will fail and the TPM will remain in a Not Ready state for computers running Windows 8 and later.
 
**Setting the correct permissions in AD DS**
To initialize the TPM successfully so that you can turn on BitLocker requires that the correct permissions for the SELF account in be set in AD DS for the **ms-TPMOwnerInformation** attribute. The following steps detail setting these permissions as required by BitLocker:
1. Open **Active Directory Users and Computers**.
2. Select the organizational unit (OU) which contains the computer accounts that will have BitLocker turned on.
3. Right-click the OU and click **Delegate Control** to open the **Delegation of Control** wizard.
4. Click **Next** to go to the **Users or Groups** page and then click **Add**.
5. In the **Select Users, Computers, or Groups** dialog box, type **SELF** as the object name and then click **OK** Once the object has been validated you will be returned to the **Users or Groups** wizard page and the SELF account will be listed. Click **Next**.
6. On the **Tasks to Delegate** page, choose **Create a custom task to delegate** and then click **Next**.
7. On the **Active Directory Object Type** page, choose **Only the following objects in the folder** and then check **Computer Objects** and then click **Next**.
8. On the **Permissions** page, for **Show these permissions**, check **General**, **Property-specific**, and **Creation/deletion of specific child objects**. Scroll down the **Permissions** list and check both **Write msTPM-OwnerInformation** and **Write msTPM-TpmInformationForComputer** then click **Next**.
9. Click **Finish** to apply the permissions settings.
## <a href="" id="bkmk-fipssupport"></a>FIPS support for recovery password protector
Functionality introduced in Windows Server 2012 R2 and Windows 8.1, allows BitLocker to be fully functional in FIPS mode.
>**Note:**  The United States Federal Information Processing Standard (FIPS) defines security and interoperability requirements for computer systems that are used by the U.S. federal government. The FIPS 140 standard defines approved cryptographic algorithms. The FIPS 140 standard also sets forth requirements for key generation and for key management. The National Institute of Standards and Technology (NIST) uses the Cryptographic Module Validation Program (CMVP) to determine whether a particular implementation of a cryptographic algorithm is compliant with the FIPS 140 standard. An implementation of a cryptographic algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed NIST validation. An algorithm that has not been submitted cannot be considered FIPS-compliant even if the implementation produces identical data as a validated implementation of the same algorithm. 
 
Prior to these supported versions of Windows, when Windows was in FIPS mode, BitLocker prevented the creation or use of recovery passwords and instead forced the user to use recovery keys. For more information about these issues, see the support article [kb947249](http://support.microsoft.com/kb/947249).
But on computers running these supported systems with BitLocker enabled:
- FIPS-compliant recovery password protectors can be created when Windows is in FIPS mode. These protectors use the FIPS 140 NIST SP800-132 algorithm.
- Recovery passwords created in FIPS mode on Windows 8.1 can be distinguished from recovery passwords created on other systems.
- Recovery unlock using the FIPS-compliant algorithm based recovery password protector work in all cases that currently work for recovery passwords.
- When FIPS-compliant recovery passwords unlock volumes, the volume is unlocked to allow read/write access even while in FIPS mode.
- FIPS-compliant recovery password protectors can be exported and stored in AD a while in FIPS mode.
The BitLocker Group Policy settings for recovery passwords work the same for all Windows versions that support BitLocker, whether in FIPs mode or not.
However, you cannot use recovery passwords generated on a system in FIPS mode for systems earlier than Windows Server 2012 R2 and Windows 8.1. Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; so recovery keys should be used instead.
## More information
- [Trusted Platform Module](../tpm/trusted-platform-module-overview.md)
- [TPM Group Policy settings](../tpm/trusted-platform-module-services-group-policy-settings.md)
- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
- [BitLocker](bitlocker-overview.md)
- [BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
- [BitLocker basic deployment](bitlocker-basic-deployment.md)

43
windows/security/information-protection/bitlocker/protect-bitlocker-from-pre-boot-attacks.md Normal file
View File

@ -0,0 +1,43 @@
---
title: Protect BitLocker from pre-boot attacks (Windows 10)
description: This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration.
ms.assetid: 24d19988-fc79-4c45-b392-b39cba4ec86b
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 04/19/2017
---
# Protect BitLocker from pre-boot attacks
**Applies to**
- Windows 10
This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration.
BitLocker uses encryption to protect the data on your drive, but BitLocker security is only effective when the encryption key is protected. Many users have relied on pre-boot authentication to protect the operating system’s integrity, disk encryption solution (for example, encryption keys), and the PC’s data from offline attacks. With pre-boot authentication, users must provide some form of credential before unlocking encrypted volumes and starting
Windows. Typically, they authenticate themselves using a PIN or a USB flash drive as a key.
Full-volume encryption using BitLocker Drive Encryption is vital for protecting data and system integrity on devices running the Windows 10, Windows 8.1, Windows 8, or Windows 7 operating system. It is equally important to protect the BitLocker encryption key. On Windows 7 devices, sufficiently protecting that key often required pre-boot authentication, which many users find inconvenient and complicates device management.
Pre-boot authentication provides excellent startup security, but it inconveniences users and increases IT management costs. Every time the PC is unattended, the device must be set to hibernate (in other words, shut down and powered off); when the computer restarts, users must authenticate before the encrypted volumes are unlocked. This requirement increases restart times and prevents users from accessing remote PCs until they can physically access the computer to authenticate, making pre-boot authentication unacceptable in the modern IT world, where users expect their devices to turn on instantly and IT requires PCs to be constantly connected to the network.
If users lose their USB key or forget their PIN, they can’t access their PC without a recovery key. With a properly configured infrastructure, the organization’s support will be able to provide the recovery key, but doing so increases support costs, and users might lose hours of productive work time.
Starting with Windows 8, Secure Boot and Windows Trusted Boot startup process ensures operating system integrity, allowing Windows to start automatically while minimizing the risk of malicious startup tools and rootkits. In addition, many modern devices are fundamentally physically resistant to sophisticated attacks against the computer’s memory, and now Windows authenticates the user before making devices that may represent a threat to the device and encryption keys available for use.
## In this topic
The sections that follow help you understand which PCs still need pre-boot authentication and which can meet your security requirements without the inconvenience of it.
- [Types of attacks for volume encryption keys](types-of-attacks-for-volume-encryption-keys.md)
- [BitLocker countermeasures](bitlocker-countermeasures.md)
- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
## See also
- [BitLocker overview](bitlocker-overview.md)
 
 

270
windows/security/information-protection/bitlocker/protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md Normal file
View File

@ -0,0 +1,270 @@
---
title: Protecting cluster shared volumes and storage area networks with BitLocker (Windows 10)
description: This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
ms.assetid: ecd25a10-42c7-4d31-8a7e-ea52c8ebc092
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 06/19/2017
---
# Protecting cluster shared volumes and storage area networks with BitLocker
**Applies to**
- Windows Server 2016
This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
BitLocker can protect both physical disk resources and cluster shared volumes version 2.0 (CSV2.0). BitLocker on clustered volumes allows for an additional layer of protection for administrators wishing to protect sensitive, highly available data. By adding additional protectors to the clustered volume, administrators can also add an additional barrier of security to resources within an organization by allowing only certain user accounts access to unlock the BitLocker volume.
## <a href="" id="configuring-bitlocker-on-cluster-shared-volumes-"></a>Configuring BitLocker on Cluster Shared Volumes
### Using BitLocker with Clustered Volumes
BitLocker on volumes within a cluster are managed based on how the cluster service "views" the volume to be protected. The volume can be a physical disk resource such as a logical unit number (LUN) on a storage area network (SAN) or network attached storage (NAS).
>**Important**  SANs used with BitLocker must have obtained Windows Hardware Certification. For more info, see [Windows Hardware Lab Kit](https://msdn.microsoft.com/library/windows/hardware/dn930814.aspx).
 
Alternatively, the volume can be a cluster-shared volume, a shared namespace, within the cluster. Windows Server 2012 expanded the CSV architecture, now known as CSV2.0, to enable support for BitLocker. When using BitLocker with volumes designated for a cluster, the volume will need to turn on
BitLocker before its addition to the storage pool within cluster or put the resource into maintenance mode before BitLocker operations will complete.
Windows PowerShell or the manage-bde command line interface is the preferred method to manage BitLocker on CSV2.0 volumes. This is recommended over the BitLocker Control Panel item because CSV2.0 volumes are mount points. Mount points are an NTFS object that is used to provide an entry point to other volumes. Mount points do not require the use of a drive letter. Volumes that lack drive letters do not appear in the BitLocker Control Panel item. Additionally, the new Active Directory-based protector option required for cluster disk resource or CSV2.0 resources is not available in the Control Panel item.
>**Note:**  Mount points can be used to support remote mount points on SMB based network shares. This type of share is not supported for BitLocker encryption.
 
For thinly provisioned storage, such as a Dynamic Virtual Hard Disk (VHD), BitLocker runs in Used Disk Space Only encryption mode. You cannot use the **manage-bde -WipeFreeSpace** command to transition the volume to full-volume encryption on these types of volumes. This is blocked in order to avoid expanding thinly provisioned volumes to occupy the entire backing store while wiping the unoccupied (free) space.
### Active Directory-based protector
You can also use an Active Directory Domain Services (AD DS) protector for protecting clustered volumes held within your AD DS infrastructure. The **ADAccountOrGroup** protector is a domain security identifier (SID)-based protector that can be bound to a user account, machine account or group. When an unlock request is made for a protected volume, the BitLocker service interrupts the request and uses the BitLocker protect/unprotect APIs to unlock or deny the request. BitLocker will unlock protected volumes without user intervention by attempting protectors in the following order:
1. Clear key
2. Driver-based auto-unlock key
3. ADAccountOrGroup protector
1. Service context protector
2. User protector
4. Registry-based auto-unlock key
>**Note:**  A Windows Server 2012 or later domain controller is required for this feature to work properly.
 
### Turning on BitLocker before adding disks to a cluster using Windows PowerShell
BitLocker encryption is available for disks before or after addition to a cluster storage pool. The advantage of encrypting volumes prior to adding them to a cluster is that the disk resource does not require suspending the resource to complete the operation. To turn on BitLocker for a disk before adding it to a cluster, do the following:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Ensure the disk is formatted NTFS and has a drive letter assigned to it.
3. Identify the name of the cluster with Windows PowerShell.
``` syntax
Get-Cluster
```
4. Enable BitLocker on the volume of your choice with an **ADAccountOrGroup** protector, using the cluster name. For example, use a command such as:
``` syntax
Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
>**Warning:**  You must configure an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to fail over properly in a traditional failover cluster.
 
5. Repeat the preceding steps for each disk in the cluster.
6. Add the volume(s) to the cluster.
### Turning on BitLocker for a clustered disk using Windows PowerShell
When the cluster service owns a disk resource already, it needs to be set into maintenance mode before BitLocker can be enabled. Use the following steps for turning BitLocker on for a clustered disk:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Check the status of the cluster disk using Windows PowerShell.
``` syntax
Get-ClusterResource "Cluster Disk 1"
```
3. Put the physical disk resource into maintenance mode using Windows PowerShell.
``` syntax
Get-ClusterResource "Cluster Disk 1" | Suspend-ClusterResource
```
4. Identify the name of the cluster with Windows PowerShell.
``` syntax
Get-Cluster
```
5. Enable BitLocker on the volume of your choice with an **ADAccountOrGroup** protector, using the cluster name. For example, use a command such as:
``` syntax
Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
>**Warning:**  You must configure an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to fail over properly in a traditional failover cluster.
 
6. Use **Resume-ClusterResource** to take the physical disk resource back out of maintenance mode:
``` syntax
Get-ClusterResource "Cluster Disk 1" | Resume-ClusterResource
```
7. Repeat the preceding steps for each disk in the cluster.
### Adding BitLocker encrypted volumes to a cluster using manage-bde
You can also use manage-bde to enable BitLocker on clustered volumes. The steps needed to add a physical disk resource or CSV2.0 volume to an existing cluster includes the following:
1. Verify the BitLocker Drive Encryption feature is installed on the computer.
2. Ensure new storage is formatted as NTFS.
3. Encrypt the volume, add a recovery key and add the cluster administrator as a protector key using the manage-bde command line interface (see example):
- `Manage-bde -on -used <drive letter> -RP -sid domain\CNO$ -sync`
1. BitLocker will check to see if the disk is already part of a cluster. If it is, administrators will encounter a hard block. Otherwise, the encryption will continue.
2. Using the -sync parameter is optional. Using it ensures the command waits until the encryption for the volume is completed before releasing the volume for use in the cluster storage pool.
4. Open the Failover Cluster Manager snap-in or cluster PowerShell cmdlets to enable the disk to be clustered
- Once the disk is clustered it can also be enabled for CSV.
5. During the resource online operation, cluster will check to see if the disk is BitLocker encrypted.
1. If the volume is not BitLocker enabled, traditional cluster online operations occur.
2. If the volume is BitLocker enabled, the following check occurs:
- If volume is **locked**, BitLocker will impersonate the CNO and unlock the volume using the CNO protector. If this operation fails an event will be logged that the volume could not be unlocked and the online operation will fail.
6. Once the disk is online in the storage pool, it can be added to a CSV by right clicking on the disk resource and choosing "**Add to cluster shared volumes**".
CSVs can include both encrypted and unencrypted volumes. To check the status of a particular volume for BitLocker encryption, administrators can utilize the manage-bde -status command with a path to the volume inside the CSV namespace as seen in the example command line below.
``` syntax
manage-bde -status "C:\ClusterStorage\volume1"
```
### Physical Disk Resources
Unlike CSV2.0 volumes, physical disk resources can only be accessed by one cluster node at a time. This means that operations such as encrypting, decrypting, locking or unlocking volumes require context to perform. For example, you cannot unlock or decrypt a physical disk resource if you are not administering the cluster node that owns the disk resource because the disk resource is not available.
### Restrictions on BitLocker actions with cluster volumes
The following table contains information about both Physical Disk Resources (i.e. traditional failover cluster volumes) and Cluster Shared Volumes (CSV) and the actions that are allowed by BitLocker in each situation.
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><strong>Action</strong></p></td>
<td align="left"><p><strong>On owner node of failover volume</strong></p></td>
<td align="left"><p><strong>On Metadata Server (MDS) of CSV</strong></p></td>
<td align="left"><p><strong>On (Data Server) DS of CSV</strong></p></td>
<td align="left"><p><strong>Maintenance Mode</strong></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Manage-bde –on</strong></p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Manage-bde –off</strong></p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Manage-bde Pause/Resume</strong></p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked**</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Manage-bde –lock</strong></p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>manage-bde –wipe</strong></p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Unlock</strong></p></td>
<td align="left"><p>Automatic via cluster service</p></td>
<td align="left"><p>Automatic via cluster service</p></td>
<td align="left"><p>Automatic via cluster service</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>manage-bde –protector –add</strong></p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>manage-bde -protector -delete</strong></p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>manage-bde –autounlock</strong></p></td>
<td align="left"><p>Allowed (not recommended)</p></td>
<td align="left"><p>Allowed (not recommended)</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed (not recommended)</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Manage-bde -upgrade</strong></p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>Shrink</strong></p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>Extend</strong></p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Allowed</p></td>
<td align="left"><p>Blocked</p></td>
<td align="left"><p>Allowed</p></td>
</tr>
</tbody>
</table>
 
>**Note:**  Although the manage-bde -pause command is Blocked in clusters, the cluster service will automatically resume a paused encryption or decryption from the MDS node
 
In the case where a physical disk resource experiences a failover event during conversion, the new owning node will detect the conversion is not complete and will complete the conversion process.
### Other considerations when using BitLocker on CSV2.0
Some other considerations to take into account for BitLocker on clustered storage include the following:
- BitLocker volumes have to be initialized and beginning encryption before they are available to add to a CSV2.0 volume.
- If an administrator needs to decrypt a CSV volume, remove the volume from the cluster or put into disk maintenance mode. You can add the CSV back to the cluster while waiting for decryption to complete.
- If an administrator needs to start encrypting a CSV volume, remove the volume from the cluster or put it in maintenance mode.
- If conversion is paused with encryption in progress and the CSV volume is offline from the cluster, the cluster thread (health check) will automatically resume conversion when the volume is online to the cluster.
- If conversion is paused with encryption in progress and a physical disk resource volume is offline from the cluster, the BitLocker driver will automatically resume conversion when the volume is online to the cluster.
- If conversion is paused with encryption in progress, while the CSV volume is in maintenance mode, the cluster thread (health check) will automatically resume conversion when moving the volume back from maintenance.
- If conversion is paused with encryption in progress, while the disk resource volume is in maintenance mode, the BitLocker driver will automatically resume conversion when the volume is moved back from maintenance mode.

129
windows/security/information-protection/bitlocker/types-of-attacks-for-volume-encryption-keys.md Normal file
View File

@ -0,0 +1,129 @@
---
title: Types of attacks for volume encryption keys (Windows 10)
description: There are many ways Windows helps protect your organization from attacks, including Unified Extensible Firmware Interface (UEFI) secure boot, Trusted Platform Module (TPM), Group Policy, complex passwords, and account lockouts.
ms.assetid: 405060a9-2009-44fc-9f84-66edad32c6bc
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 10/27/2017
---
# Types of attacks for volume encryption keys
**Applies to**
- Windows 10
There are many ways Windows helps protect your organization from attacks, including Unified Extensible Firmware Interface (UEFI) Secure Boot, Trusted Platform Module (TPM), Group Policy, complex passwords, and account lockouts.
The next few sections describe each type of attack that could be used to compromise a volume encryption key, whether for BitLocker or a non-Microsoft encryption solution. After an attacker has compromised a volume encryption key, the attacker can read data from your system drive or even install malware while Windows is offline. Each section begins with a graphical overview of the attack’s strengths and weaknesses as well as suggested mitigations.
### Bootkit and rootkit attacks
Rootkits are a sophisticated and dangerous type of malware that runs in kernel mode, using the same privileges as the operating system. Because rootkits have the same or possibly even more rights than the operating system, they can completely hide themselves from Windows and even an antimalware solution. Often, rootkits are part of an entire suite of malware that can bypass local logins, record passwords, transfer private files, and capture cryptography keys.
Different types of bootkits and rootkits load at different software levels:
- **Kernel level.** Rootkits running at the kernel level have the highest privilege in the operating system. They may be able to inject malicious code or replace portions of the core operating system, including both the kernel and device drivers.
- **Application level.** These rootkits are aimed to replace application binaries with malicious code, such as a Trojan, and can even modify the behavior of existing applications.
- **Library level.** The purpose of library-level rootkits is to hook, patch, or replace system calls with malicious code that can hide the malware’s presence.
- **Hypervisor level.** Hypervisor rootkits target the boot sequence. Their primary purpose is to modify the boot sequence to load themselves as a hypervisor.
- **Firmware level.** These rootkits overwrite the PC’s BIOS firmware, giving the malware low-level access and potentially the ability to install or hide malware, even if it’s cleaned or removed from the hard disk.
Regardless of the operating system or encryption method, rootkits have access to confidential data once installed. Application-level rootkits can read any files the user can access, bypassing volume-level encryption. Kernel-, library-, hypervisor-, and firmware-level rootkits have direct access to system files on encrypted volumes and can also retrieve an encryption key from memory.
Windows offers substantial protection from bootkits and rootkits, but it is possible to bypass operating system security when an attacker has physical access to the device and can install the malware to the device while Windows is offline. For example, an attacker might boot a PC from a USB flash drive containing malware that starts before Windows. The malware can replace system files or the PC’s firmware or simply start Windows under its control.
To sufficiently protect a PC from boot and rootkits, devices must use pre-boot authentication or Secure Boot, or the encryption solution must use the device’s Trusted Platform Module (TPM) as a means of monitoring the integrity of the end-to-end boot process. Pre-boot authentication is available for any device, regardless of the hardware, but because it is inconvenient to users, it should be used only to mitigate threats that are applicable to the device. On devices with Secure Boot enabled, you do not need to use pre-boot authentication to protect against boot and rootkit attacks.
Although password protection of the UEFI configuration is important for protecting a device’s configuration and preventing an attacker from disabling Secure Boot, use of a TPM and its Platform Configuration Register (PCR) measurements (PCR7) to ensure that the system’s bootloader (whether a Windows or non-Microsoft encryption solution) is tamper free and the first code to start on the device is critical. An encryption solution that doesn’t use a device’s TPM to protect its components from tampering may be unable to protect itself from bootkit-level infections that could log a user’s password or acquire encryption keys.
For this reason, when BitLocker is configured on devices that include a TPM, the TPM and its PCRs are always used to secure and confirm the integrity of the pre–operating system environment before making encrypted volumes accessible.
Any change to the UEFI configuration invalidates the PCR7 and requires the user to enter the BitLocker recovery key. Because of this feature, it’s not critical to password-protect your UEFI configuration. But UEFI password protection is a best practice and is still required for systems not using a TPM (such as non-Microsoft alternatives).
### Brute-force Sign-in Attacks
Attackers can find any password if you allow them to guess enough times. The process of trying millions of different passwords until you find the right one is known as a *brute-force sign-in attack*. In theory, an attacker could obtain any password by using this method.
Three opportunities for brute-force attacks exist:
- **Against the pre-boot authenticator.** An attacker could attack the device directly by attempting to guess the user’s BitLocker PIN or an equivalent authenticator. The TPM mitigates this approach by invoking an anti-hammering lockout capability that requires the user to wait until the lockout period ends or enter the BitLocker recovery key.
- **Against the recovery key.** An attacker could attempt to guess the 48-digit BitLocker recovery key. Even without a lockout period, the key is long enough to make brute-force attacks impractical. Specifically, the BitLocker recovery key has 128 bits of entropy; thus, the average brute-force attack would succeed after 18,446,744,073,709,551,616 guesses. If an attacker could guess 1 million passwords per second, the average brute-force attack would require more than 580,000 years to be successful.
- **Against the operating system sign-in authenticator.** An attacker can attempt to guess a valid user name and password. Windows implements a delay between password guesses, slowing down brute-force attacks. In addition, all recent versions of Windows allow administrators to require complex passwords and password lockouts. Similarly, administrators can use Microsoft Exchange ActiveSync policy or Group Policy to configure Windows 8.1 and Windows 8 to automatically restart and require the user to enter the BitLocker 48-digit recovery key after a specified number of invalid password attempts. When these settings are enabled and users follow best practices for complex passwords, brute-force attacks against the operating system sign-in are impractical.
In general, brute-force sign-in attacks are not practical against Windows when administrators enforce complex passwords and account lockouts.
### Direct Memory Access Attacks
Direct memory access (DMA) allows certain types of hardware devices to communicate directly with a device’s system memory. For example, if you use Thunderbolt to connect another device to your computer, the second device automatically has Read and Write access to the target computer’s memory.
Unfortunately, DMA ports don’t use authentication and access control to protect the contents of the computer’s memory. Whereas Windows can often prevent system components and apps from reading and writing to protected parts of memory, a device can use DMA to read any location in memory, including the location of any encryption keys.
DMA attacks are relatively easy to execute and require little technical skills. Anyone can download a tool from the Internet, such as those made by [Passware](http://www.lostpassword.com/), [ElcomSoft](http://elcomsoft.com/), and
others, and then use a DMA attack to read confidential data from a PC’s memory. Because encryption solutions store their encryption keys in memory, they can be accessed by a DMA attack.
Not all port types are vulnerable to DMA attacks. USB in particular does not allow DMA, but devices that have any of the following port types are vulnerable:
- FireWire
- Thunderbolt
- ExpressCard
- PCMCIA
- PCI
- PCI-X
- PCI Express
To perform a DMA attack, attackers typically connect a second PC that is running a memory-scanning tool (for example, Passware, ElcomSoft) to the FireWire or Thunderbolt port of the target computer. When connected, the software
scans the system memory of the target and locates the encryption key. Once acquired, the key can be used to decrypt the drive and read or modify its contents.
A much more efficient form of this attack exists in theory: An attacker crafts a custom FireWire or Thunderbolt device that has the DMA attack logic programmed on it. Now, the attacker simply needs to physically connect the device. If the attacker does not have physical access, they could disguise it as a free USB flash drive and distribute it to employees of a target organization. When connected, the attacking device could use a DMA attack to scan the PC’s memory for the encryption key. It could then transmit the key (or any data in the PC’s memory) using the PC’s Internet connection or its own wireless connection. This type of attack would require an extremely high level of sophistication, because it requires that the attacker create a custom device (devices of these types are not readily available in the marketplace at this time).
Today, one of the most common uses for DMA ports on Windows devices is for developer debugging, a task that some developers need to perform and one that few consumers will ever perform. Because USB; DisplayPort; and other, more secure port types satisfy consumers, most new mobile PCs do not include DMA ports. Microsoft’s view is that because of the inherent security risks of DMA ports, they do not belong on mobile devices, and Microsoft has prohibited their inclusion on any Modern Standby-certified devices. Modern Standby devices offer mobile phone–like power management and instant-on capabilities; at the time of writing, they are primarily found in Windows tablets.
DMA-based expansion slots are another avenue of attack, but these slots generally appear only on desktop PCs that are designed for expansion. Organizations can use physical security to prevent outside attacks against their desktop PCs. In addition, a DMA attack on the expansion slot would require a custom device; as a result, an attacker would most likely insert an interface with a traditional DMA port (for example, FireWire) into the slot to attack the PC.
To mitigate a port-based DMA attack an administrator can configure policy settings to disable FireWire and other device types that have DMA. Also, many PCs allow those devices to be disabled by using firmware settings. Although the need for pre-boot authentication can be eliminated at the device level or through Windows configuration, the BitLocker pre-boot authentication feature is still available when needed. When used, it successfully mitigates all types of DMA port and expansion slot attacks on any type of device.
### Hyberfil.sys Attacks
The hyberfil.sys file is the Windows hibernation file. It contains a snapshot of system memory that is generated when a device goes into hibernation and includes the encryption key for BitLocker and other encryption technologies. Attackers have claimed that they have successfully extracted encryption keys from the hyberfil.sys file.
Like the DMA port attack discussed in the previous section, tools are available that can scan the hyberfile.sys file and locate the encryption key, including a tool made by [Passware](http://www.lostpassword.com/). Microsoft does not consider Windows to be vulnerable to this type of attack, because Windows stores the hyberfil.sys file within the encrypted system volume. As a result, the file would be accessible only if the attacker had both physical and sign-in access to the PC. When an attacker has sign-in access to the PC, there are few reasons for the attacker to decrypt the drive, because they would already have full access to the data within it.
In practice, the only reason an attack on hyberfil.sys would grant an attacker additional access is if an administrator had changed the default Windows configuration and stored the hyberfil.sys file on an unencrypted drive. By default, Windows 10 is designed to be secure against this type of attack.
### Memory Remanence Attacks
A memory remanence attack is a side-channel attack that reads the encryption key from memory after restarting a PC. Although a PC’s memory is often considered to be cleared when the PC is restarted, memory chips don’t immediately lose their memory when you disconnect power. Therefore, an attacker who has physical access to the PC’s memory might be able to read data directly from the memory—including the encryption key.
When performing this type of cold boot attack, the attacker accesses the PC’s physical memory and recovers the encryption key within a few seconds or minutes of disconnecting power. This type of attack was demonstrated by researchers at [Princeton University](http://www.youtube.com/watch?v=JDaicPIgn9U). With the encryption key, the attacker would be able to decrypt the drive and access its files.
To acquire the keys, attackers follow this process:
1. Freeze the PC’s memory. For example, an attacker can freeze the memory to −50°C by spraying it with aerosol air duster spray.
2. Restart the PC.
3. Instead of restarting Windows, boot to another operating system. Typically, this is done by connecting a bootable flash drive or loading a bootable DVD.
4. The bootable media loads the memory remanence attack tools, which the attacker uses to scan the system memory and locate the encryption keys.
5. The attacker uses the encryption keys to access the drive’s data.
If the attacker is unable to boot the device to another operating system (for example, if bootable flash drives have been disabled or Secure Boot is enabled), the attacker can attempt to physically remove the frozen memory from the device and attach it to a different, possibly identical device. Fortunately, this process has proven extremely unreliable, as evidenced by the Defence Research and Development Canada (DRDC) Valcartier group’s analysis (see [An In-depth Analysis of the Cold Boot Attack](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078)). On an increasing portion of modern devices, this type of attack is not even possible, because memory is soldered directly to the motherboard.
Although Princeton’s research proved that this type of attack was possible on devices that have removable memory, device hardware has changed since the research was published in 2008:
- Secure Boot prevents the malicious tools that the Princeton attack depends on from running on the target device.
- Windows systems with BIOS or UEFI can be locked down with a password, and booting to a USB drive can be prevented.
- If booting to USB is required on the device, it can be limited to starting trusted operating systems by using Secure Boot.
- The discharge rates of memory are highly variable among devices, and many devices have memory that is completely immune to memory remanence attacks.
- Increased density of memory diminishes their remanence properties and reduces the likelihood that the attack can be successfully executed, even when memory is physically removed and placed in an identical system where the system’s configuration may enable booting to the malicious tools.
Because of these factors, this type of attack is rarely possible on modern devices. Even in cases where the risk factors exist on legacy devices, attackers will find the attack unreliable. For detailed info about the practical uses for forensic memory acquisition and the factors that make a computer vulnerable or resistant to memory remanence attacks, read [An In-depth Analysis of the Cold Boot Attack](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078).
The BitLocker pre-boot authentication feature can successfully mitigate memory remanence attacks on most devices, but you can also mitigate such attacks by protecting the system UEFI or BIOS and prevent the PC from booting from external media (such as a USB flash drive or DVD). The latter option is often a better choice, because it provides sufficient protection without inconveniencing users with pre-boot authentication.
## See also
- [BitLocker countermeasures](bitlocker-countermeasures.md)
- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
- [BitLocker overview](bitlocker-overview.md)