BitLocker: How to enable Network Unlock

BitLocker: How to enable Network Unlock 7 out of 9 rated this helpful - Rate this topic Published: August 15, 2012 Updated: August 15, 2012 Applies To: Windows Server 2012 Windows 8 and Windows Server 2012 has added a new BitLocker protector option for operating system volumes called Network Unlock. 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 machine 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. 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: Computers running Windows 8 or Windows Server 2012 with UEFI DHCP drivers can be Network Unlock clients. BitLocker Network Unlock optional feature installed on Windows Server 2012. A separate Windows Server 2012 server running the Windows Deployment Services (WDS) role. A DHCP server, separate from the WDS server. 1

Properly configured public/private key pairing. Network Unlock Group Policy settings configured. 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, the first network interface card (NIC) on the computer, usually the onboard NIC, must be configured to support DHCP and used for Network Unlock. This is especially worth noting when you have multiple NICs, 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 NICs when it reaches one with a DHCP port failure for any reason. Thus, if the first enumerated NIC 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 Windows Server 2012 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 a Windows Server 2012 running 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 Windows Server 2012 WDS server and returned encrypted with its corresponding session key. 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 Windows Server 2012 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 2

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 Windows Server 2012 domain controller. 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). Configuring Network Unlock The following steps allow an administrator to configure Network Unlock in a domain. 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: Install-WindowsFeature WDS-Deployment 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: Get-Service WDSServer 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: Install-WindowsFeature BitLocker-NetworkUnlock 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. 3

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: o 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 0. Create a.pfx file by right-clicking the previously created certificate, choosing All Tasks, then Export. 1. Select Yes, export the private key. 2. Complete the wizard to create the.pfx file. To create a self-signed certificate, do the following: 1. Create a text file with an.inf extension. For example, notepad.exe BitLocker- NetworkUnlock.inf 4

2. Add the following contents to the previously created file: 3. [NewRequest] 4. Subject="CN=BitLocker Network Unlock certificate" 5. Exportable=true 6. RequestType=Cert 7. KeyLength=2048 8. 9. [Extensions] 10. 1.3.6.1.4.1.311.21.10 = {text} 11. _continue_ = OID=1.3.6.1.4.1.311.67.1.1 12. 13. 2.5.29.37 = "{text}" 14. _continue_= 1.3.6.1.4.1.311.67.1.1 15. Open an elevated command prompt and use the certreq tool to create a new certificate using the following command: 16. certreq new BitLocker-NetworkUnlock.inf BitLocker-NetworkUnlock.cer 17. Verify the previous command properly created the certificate by confirming the.cer file exists 18. Launch the Certificate Manager by running certmgr.msc 19. Create a.pfx file by navigating to the Certificates Current User pane, right-clicking the previously imported certificate, selecting All Tasks, then Export. Follow through the wizard to create the.pfx file. 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. 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. The following steps describe how to deploy the required Group Policy setting: 1. Copy the.cer file created for Network Unlock to the domain controller 5

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. Step Seven: Require TPM+PIN protectors at startup (recommended) An additional recommendation 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 Creating 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 8respectively. Ensure the Show resulting changes dialog box is selected. 6

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: o o 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. 7

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 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 8

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". 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. Updating 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. Troubleshooting 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: 9

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 snapins 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: 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: 2. wevtutil sl Microsoft-Windows-Deployment-Services- Diagnostics/Debug /e:true 3. 4. Open Event Viewer on the WDS server. In the left pane, click Applications and Services Logs, click Microsoft, click 10

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 11