diff --git a/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md b/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md index 92faac8b6a..3c38d5e1f6 100644 --- a/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md +++ b/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md @@ -122,7 +122,6 @@ A properly configured Active Directory Certification Authority can use this cert - *Object Identifier:* **1.3.6.1.4.1.311.67.1.1** 1. Select the newly created **BitLocker Network Unlock** application policy and select **OK** - 1. 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 1. Select the **Security** tab. Confirm that the **Domain Admins** group has been granted **Enroll** permission 1. Select **OK** to complete configuration of the template @@ -137,51 +136,33 @@ Network Unlock can use imported certificates from an existing public key infrast To enroll a certificate from an existing certificate authority: -1. On the WDS server, open Certificate Manager by using `certmgr.msc`. - -2. Under **Certificates - Current User**, right-click **Personal**. - -3. Select **All Tasks** > **Request New Certificate**. - -4. When the Certificate Enrollment wizard opens, select **Next**. - -5. Select **Active Directory Enrollment Policy**. - -6. Choose the certificate template that was created for Network Unlock on the domain controller. Then select **Enroll**. - -7. When prompted for more information, select **Subject Name** and provide a friendly name value. The friendly name should include information for the domain or organizational unit for the certificate. For example: - - *BitLocker Network Unlock Certificate for Contoso domain* - -8. Create the certificate. Ensure the certificate appears in the **Personal** folder. - -9. Export the public key certificate for Network Unlock: - - 1. Create a `.cer` file by right-clicking the previously created certificate, selecting **All Tasks**, and then selecting **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. - -10. Export the public key with a private key for Network Unlock. - - 1. Create a `.pfx` file by right-clicking the previously created certificate, selecting **All Tasks**, and then selecting **Export**. - - 2. Select **Yes, export the private key**. - - 3. Complete the steps to create the `.pfx` file. +1. On the WDS server, open Certificate Manager by using `certmgr.msc` +1. Under **Certificates - Current User**, right-click **Personal** +1. Select **All Tasks** > **Request New Certificate** +1. When the Certificate Enrollment wizard opens, select **Next** +1. Select **Active Directory Enrollment Policy** +1. Choose the certificate template that was created for Network Unlock on the domain controller. Then select **Enroll** +1. When prompted for more information, select **Subject Name** and provide a friendly name value. The friendly name should include information for the domain or organizational unit for the certificate For example: *BitLocker Network Unlock Certificate for Contoso domain* +1. Create the certificate. Ensure the certificate appears in the **Personal** folder +1. Export the public key certificate for Network Unlock: + 1. Create a `.cer` file by right-clicking the previously created certificate, selecting **All Tasks**, and then selecting **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** +1. Export the public key with a private key for Network Unlock + 1. Create a `.pfx` file by right-clicking the previously created certificate, selecting **All Tasks**, and then selecting **Export** + 1. Select **Yes, export the private key** + 1. Complete the steps to create the `.pfx` file To create a self-signed certificate, either use the `New-SelfSignedCertificate` cmdlet in Windows PowerShell or use `certreq.exe`. For example: -**Windows PowerShell:** +#### PowerShell ```powershell 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.exe:** +#### certreq.exe 1. Create a text file with an `.inf` extension, for example: @@ -189,7 +170,7 @@ New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN= notepad.exe BitLocker-NetworkUnlock.inf ``` -2. Add the following contents to the previously created file: +1. Add the following contents to the previously created file: ```ini [NewRequest] @@ -210,35 +191,28 @@ New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN= _continue_ = "1.3.6.1.4.1.311.67.1.1" ``` -3. Open an elevated Command Prompt and use the `certreq.exe` tool to create a new certificate. Use the following command, specifying the full path to the file that was created previously along with the file name: +1. Open an elevated Command Prompt and use the `certreq.exe` tool to create a new certificate. Use the following command, specifying the full path to the file that was created previously along with the file name: ```cmd certreq.exe -new BitLocker-NetworkUnlock.inf BitLocker-NetworkUnlock.cer ``` -4. Verify that certificate was properly created by the previous command by confirming that the `.cer` file exists. - -5. Launch the **Certificates - Local Computer** console by running `certlm.msc`. - -6. Create a `.pfx` file by following the below steps the **Certificates - Local Computer** console: +1. Verify that certificate was properly created by the previous command by confirming that the `.cer` file exists +1. Launch the **Certificates - Local Computer** console by running `certlm.msc` +1. Create a `.pfx` file by following the below steps the **Certificates - Local Computer** console: 1. Navigate to **Certificates - Local Computer** > **Personal** > **Certificates** - - 2. Right-click the previously imported certificate, select **All Tasks**, and then select **Export** - - 3. Follow through the wizard to create the `.pfx` file. + 1. Right-click the previously imported certificate, select **All Tasks**, and then select **Export** + 1. Follow through the wizard to create the `.pfx` file ### Deploy the private key and certificate to the WDS server After creating the certificate and key, deploy them to the infrastructure to properly unlock systems. To deploy the certificates: -1. On the WDS server, launch the **Certificates - Local Computer** console by running `certlm.msc`. - -2. Right-click **BitLocker Drive Encryption Network Unlock** item under **Certificates (Local Computer)**, select **All Tasks**, and then select **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. +1. On the WDS server, launch the **Certificates - Local Computer** console by running `certlm.msc` +1. Right-click **BitLocker Drive Encryption Network Unlock** item under **Certificates (Local Computer)**, select **All Tasks**, and then select **Import** +1. In the **File to Import** dialog, choose the `.pfx` file created previously +1. Enter the password used to create the `.pfx` and complete the wizard ### Configure group policy settings for Network Unlock @@ -246,35 +220,28 @@ With certificate and key deployed to the WDS server for Network Unlock, the fina 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 then select **Require startup PIN with TPM** or **Allow startup PIN with TPM**. -3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers. +1. Open Group Policy Management Console (`gpmc.msc`) +1. Enable the policy **Require additional authentication at startup**, and then select **Require startup PIN with TPM** or **Allow startup PIN with TPM** +1. 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 that was created for Network Unlock to the domain controller. - -2. On the domain controller, open 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. Copy the `.cer` file that was created for Network Unlock to the domain controller +1. On the domain controller, open Group Policy Management Console (`gpmc.msc`) +1. Create a new Group Policy Object or modify an existing object to enable the **Allow Network Unlock at startup** setting +1. 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 select **Add Network Unlock Certificate**. - - 3. Follow the wizard steps and import the `.cer` file that was copied earlier. + 1. Right-click the folder and select **Add Network Unlock Certificate** + 1. 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 needed, delete the current certificate before deploying a new one. The Network Unlock certificate is located under the **`HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\FVE_NKP`** registry key on the client computer. -5. Reboot the clients after the Group Policy is deployed. +1. Reboot the clients after the Group Policy is deployed > [!NOTE] > The **Network (Certificate Based)** protector will be added only after a reboot, with the policy enabled and a valid certificate present in the FVE_NKP store. @@ -283,9 +250,9 @@ The following steps describe how to deploy the required group policy setting: 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 are the subnet(s) the 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 fails and stops responding to requests. +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 fails and stops 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 equal-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. +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 equal-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. ```ini [SUBNETS] @@ -295,14 +262,14 @@ 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 the subnets clients that can be unlocked from that certificate. +Following the `[SUBNETS]` section, there can be sections for each Network Unlock certificate, identified by the certificate thumbprint formatted without any spaces, which define the subnets clients that can be unlocked from that certificate. > [!NOTE] > When specifying the certificate thumbprint, do not include any spaces. If spaces are included in the thumbprint, the subnet configuration fails 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 subnets are listed in a certificate section, then only those subnets 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 doesn't have a section in the subnet policy configuration file, then no subnet restrictions are applied for unlocking with that certificate. 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 commenting it out with a prepended semi-colon. +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 commenting it out with a prepended semi-colon. ```ini [2158a767e1c14e88e27a4c0aee111d2de2eafe60] @@ -327,24 +294,18 @@ To turn off the unlock server, the PXE provider can be unregistered from the WDS 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. > [!NOTE] -> Servers that don't receive the Group Policy Object (GPO) will require a PIN when they boot. In such cases, find out why the server didn't receive the GPO to update the certificate. +> Servers that don't receive the group policy setting require a PIN when they boot. In such cases, find out why the servers don't receive the GPO to update the certificate. ## Troubleshoot Network Unlock Troubleshooting Network Unlock issues begins by verifying the environment. Many times, a small configuration issue can be the root cause of the failure. Items to verify include: -- Verify that the client hardware is UEFI-based and is on firmware version 2.3.1 and that the UEFI firmware is in native mode without a Compatibility Support Module (CSM) for BIOS mode enabled. Verification can be done by checking that the firmware doesn't have an option enabled such as "Legacy mode" or "Compatibility mode" or that the firmware doesn't 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 whether group policy is reaching the clients properly. Verification of group policy can be done using the `GPRESULT.exe` or `RSOP.msc` utilities. - -- Verify whether the clients were rebooted after applying the policy. - +- Verify that the client hardware is UEFI-based and is on firmware version 2.3.1 and that the UEFI firmware is in native mode without a Compatibility Support Module (CSM) for BIOS mode enabled. Verification can be done by checking that the firmware doesn't have an option enabled such as "Legacy mode" or "Compatibility mode" or that the firmware doesn't 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 whether group policy is reaching the clients properly. Verification of group policy can be done using the `GPRESULT.exe` or `RSOP.msc` utilities +- Verify whether the clients were rebooted after applying the policy - Verify whether the **Network (Certificate Based)** protector is listed on the client. Verification of the protector 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 local computer: ```powershell @@ -356,7 +317,7 @@ Troubleshooting Network Unlock issues begins by verifying the environment. Many Gather the following files to troubleshoot BitLocker Network Unlock. -- The Windows event logs. Specifically, get the BitLocker event logs and the Microsoft-Windows-Deployment-Services-Diagnostics-Debug log. +- The Windows event logs. Specifically, get 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. To retrieve WDS debug logs, the WDS debug logs first need to be enabled. Use either of the following two methods to turn on WDS debug logging. @@ -368,62 +329,9 @@ Gather the following files to troubleshoot BitLocker Network Unlock. - Open **Event Viewer** on the WDS server: - 1. In the left pane, navigate to **Applications and Services Logs** > **Microsoft** > **Windows** > **Deployment-Services-Diagnostics** > **Debug**. - 2. In the right pane, select **Enable Log**. + 1. In the left pane, navigate to **Applications and Services Logs** > **Microsoft** > **Windows** > **Deployment-Services-Diagnostics** > **Debug** + 2. In the right pane, select **Enable Log** -- The DHCP subnet configuration file (if one exists). - -- The output of the BitLocker status on the volume. Gather this output into a text file by using `manage-bde.exe -status`. Or in Windows PowerShell, use `Get-BitLockerVolume`. - -- The Network Monitor capture on the server that hosts the WDS role, filtered by client IP address. - - - -## Related articles - -- [BitLocker overview](index.md) -- [BitLocker frequently asked questions (FAQ)](faq.yml) -- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md) +- The DHCP subnet configuration file (if one exists) +- The output of the BitLocker status on the volume. Gather this output into a text file by using `manage-bde.exe -status`. Or in Windows PowerShell, use `Get-BitLockerVolume` +- The Network Monitor capture on the server that hosts the WDS role, filtered by client IP address