.txt
-
-1. In the Certificate Authority console, right-click **Certificate Templates**, select **New**, and select **Certificate Template to Issue**
-
- 
-
-1. From the list of templates, select the template you previously created (**WHFB Certificate Authentication**) and click **OK**. It can take some time for the template to replicate to all servers and become available in this list.
-
-1. After the template replicates, in the MMC, right-click in the Certification Authority list, click **All Tasks** and then click **Stop Service**. Right-click the name of the CA again, click **All Tasks**, and then click **Start Service**.
-
-### Requesting a Certificate
-
-1. Ensure the hybrid Azure AD joined device has network line of sight to Active Directory domain controllers and the issuing certificate authority.
-
-1. Start the **Certificates – Current User** console (%windir%\system32\certmgr.msc).
-
-1. In the left pane of the MMC, right-click **Personal**, click **All Tasks**, and then click **Request New Certificate…**
-
- 
-
-1. On the Certificate Enrollment screen, click **Next**.
-
-1. Under Select Certificate Enrollment Policy, ensure **Active Directory Enrollment Policy** is selected and then click **Next**.
-
-1. Under Request Certificates, click the check-box next to the certificate template you created in the previous section (WHfB Certificate Authentication) and then click **Enroll**.
-
-1. After a successful certificate request, click Finish on the Certificate Installation Results screen
-
-## Deploying a certificate to Hybrid or Azure AD Joined Devices using Simple Certificate Enrollment Protocol (SCEP) via Intune
-
-Deploying a certificate to Azure AD Joined Devices may be achieved with the Simple Certificate Enrollment Protocol (SCEP) via Intune. For guidance deploying the required infrastructure, refer to [Configure infrastructure to support SCEP certificate profiles with Microsoft Intune](/mem/intune/protect/certificates-scep-configure).
-
-Next you should deploy the root CA certificate (and any other intermediate certificate authority certificates) to Azure AD Joined Devices using a Trusted root certificate profile with Intune. For guidance, refer to [Create trusted certificate profiles in Microsoft Intune](/mem/intune/protect/certificates-trusted-root).
-
-Once these requirements have been met, a new device configuration profile may be configured from Intune that provisions a certificate for the user of the device. Proceed as follows:
-
-1. Sign in to the Microsoft [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
-
-1. Navigate to Devices \> Configuration Profiles \> Create profile.
-
-1. Enter the following properties:
- 1. For Platform, select **Windows 10 and later**.
- 1. For Profile, select **SCEP Certificate**.
- 1. Click **Create**.
-
-1. In **Basics**, enter the following parameters:
- 1. **Name**: Enter a descriptive name for the profile. Name your profiles so you can easily identify them later. For example, a good profile name is SCEP profile for entire company.
- 1. **Description**: Enter a description for the profile. This setting is optional, but recommended.
- 1. Select **Next**.
-
-1. In the **Configuration settings**, complete the following:
- 1. For Certificate Type, choose **User**.
- 1. For Subject name format, set it to **CN={{UserPrincipalName}}**.
- 1. Under Subject alternative name, select **User principal name (UPN)** from the drop-down menu and set the value to **CN={{UserPrincipalName}}**.
- 1. For Certificate validity period, set a value of your choosing.
- 1. For Key storage provider (KSP), choose **Enroll to Windows Hello for Business, otherwise fail (Windows 10 and later)**.
- 1. For Key usage, choose **Digital Signature**.
- 1. For Key size (bits), choose **2048**.
- 1. For Hash algorithm, choose **SHA-2**.
- 1. Under Root Certificate, click **+Root Certificate** and select the trusted certificate profile you created earlier for the Root CA Certificate.
- 1. Under Extended key usage, add the following:
-
- | Name | Object Identifier | Predefined Values |
- |------|-------------------|-------------------|
- | Smart Card Logon | 1.3.6.1.4.1.311.20.2.2 | Smart Card Logon |
- | Client Authentication | 1.3.6.1.5.5.7.3.2 | Client Authentication |
-
- 1. For Renewal threshold (%), set a value of your choosing.
- 1. For SCEP Server URLs, provide the public endpoint that you configured during the deployment of your SCEP infrastructure.
- 1. Click **Next**
-1. In Assignments, target the devices or users who should receive a certificate and click **Next**
-
-1. In Applicability Rules, provide additional issuance restrictions if required and click **Next**
-
-1. In Review + create, click **Create**
-
-Once the configuration profile has been created, targeted clients will receive the profile from Intune on their next refresh cycle. You should find a new certificate in the user store. To validate the certificate is present, do the following steps:
-
-1. Open the Certificates - Current User console (%windir%\system32\certmgr.msc)
-
-1. In the left pane of the MMC, expand **Personal** and select **Certificates**
-
-1. In the right-hand pane of the MMC, check for the new certificate
+## Deploy certificates via Active Directory Certificate Services (AD CS)
> [!NOTE]
-> This infrastructure may also deploy the same certificates to co-managed or modern-managed Hybrid Azure Active Directory-Joined devices using Intune Policies.
+> This process is applicable to *hybrid Azure AD joined* devices only.
-## Using non-Microsoft Enterprise Certificate Authorities
+To deploy certificates using an on-premises Active Directory Certificate Services enrollment policy, you must first create a *certificate template*, and then deploy certificates based on that template.
-If you are using a Public Key Infrastructure that uses non-Microsoft services, the certificate templates published to the on-premises Active Directory may not be available. For guidance with integration of Intune/SCEP with non-Microsoft PKI deployments, refer to [Use third-party certification authorities (CA) with SCEP in Microsoft Intune](/mem/intune/protect/certificate-authority-add-scep-overview).
+Expand the following sections to learn more about the process.
-As an alternative to using SCEP or if none of the previously covered solutions will work in your environment, you can manually generate Certificate Signing Requests (CSR) for submission to your PKI. To assist with this approach, you can use the [Generate-CertificateRequest](https://www.powershellgallery.com/packages/Generate-CertificateRequest) PowerShell commandlet.
+
+
+Create a Windows Hello for Business certificate template
-The Generate-CertificateRequest commandlet will generate an .inf file for a pre-existing Windows Hello for Business key. The .inf can be used to generate a certificate request manually using certreq.exe. The commandlet will also generate a .req file, which can be submitted to your PKI for a certificate.
+Follow these steps to create a certificate template:
-## RDP Sign-in with Windows Hello for Business Certificate Authentication
+1. Sign in to your issuing certificate authority (CA) and open *Server Manager*
+1. Select **Tools > Certification Authority**. The Certification Authority Microsoft Management Console (MMC) opens
+1. In the MMC, expand the CA name and right-click **Certificate Templates > Manage**
+1. The Certificate Templates console opens. All of the certificate templates are displayed in the details pane
+1. Right-click the **Smartcard Logon** template and select **Duplicate Template**
+1. Use the following table to configure the template:
-After adding the certificate using an approach from any of the previous sections, you should be able to RDP to any Windows device or server in the same Forest as the user’s on-premises Active Directory account, provided the PKI certificate chain for the issuing certificate authority is deployed to that target server.
+ | Tab Name | Configurations |
+ | --- | --- |
+ | *Compatibility* | - Clear the **Show resulting changes** check box
- Select **Windows Server 2012 or Windows Server 2012 R2** from the *Certification Authority list*
- Select **Windows Server 2012 or Windows Server 2012 R2** from the *Certification Recipient list*
|
+ | *General* | - Specify a **Template display name**, for example *WHfB Certificate Authentication*
- Set the validity period to the desired value
- Take note of the Template name for later, which should be the same as the Template display name minus spaces (*WHfBCertificateAuthentication* in this example)
|
+ | *Extensions* | Verify the **Application Policies** extension includes **Smart Card Logon**|
+ | *Subject Name* | - Select the **Build from this Active Directory** information button if it isn't already selected
- Select **Fully distinguished name** from the **Subject name format** list if Fully distinguished name isn't already selected
- Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
|
+ |*Request Handling*|- Set the Purpose to **Signature and smartcard logon** and select **Yes** when prompted to change the certificate purpose
- Select the **Renew with same key** check box
- Select **Prompt the user during enrollment**
|
+ |*Cryptography*|- Set the Provider Category to **Key Storage Provider**
- Set the Algorithm name to **RSA**
- Set the minimum key size to **2048**
- Select **Requests must use one of the following providers**
- Select **Microsoft Software Key Storage Provider**
- Set the Request hash to **SHA256**
|
+ |*Security*|Add the security group that you want to give **Enroll** access to. For example, if you want to give access to all users, select the **Authenticated** users group, and then select Enroll permissions for them|
-1. Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid Azure Active Directory-Joined client where the authentication certificate has been deployed.
-1. Attempt an RDP session to a target server.
-1. Use the certificate credential protected by your Windows Hello for Business gesture.
+1. Select **OK** to finalize your changes and create the new template. Your new template should now appear in the list of Certificate Templates
+1. Close the Certificate Templates console
+1. Open an elevated command prompt and change to a temporary working directory
+1. Execute the following command, replacing `` with the **Template display name** noted above
+
+ ```cmd
+ certutil.exe -dstemplate >
+ ```
+
+1. Open the text file created by the command above.
+ - Delete the last line of the output from the file that reads\
+ `CertUtil: -dsTemplate command completed successfully.`
+ - Modify the line that reads\
+ `pKIDefaultCSPs = "1,Microsoft Software Key Storage Provider"` to\
+ `pKIDefaultCSPs = "1,Microsoft Passport Key Storage Provider"`
+1. Save the text file
+1. Update the certificate template by executing the following command:
+
+ ```cmd
+ certutil.exe -dsaddtemplate
+ ```
+
+1. In the Certificate Authority console, right-click **Certificate Templates**, select **New > Certificate Template to Issue**
+1. From the list of templates, select the template you previously created (**WHFB Certificate Authentication**) and select **OK**. It can take some time for the template to replicate to all servers and become available in this list
+1. After the template replicates, in the MMC, right-click in the Certification Authority list, select **All Tasks > Stop Service**. Right-click the name of the CA again, select **All Tasks > Start Service**
+
+
+
+
+
+Request a certificate
+
+1. Sign in to a client that is hybrid Azure AD joined, ensuring that the client has line of sight to a domain controller and the issuing CA
+1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc`
+1. In the left pane of the MMC, right-click **Personal > All Tasks > Request New Certificate…**
+1. On the Certificate Enrollment screen, select **Next**
+1. Under *Select Certificate Enrollment Policy*, select **Active Directory Enrollment Policy > Next**
+1. Under *Request Certificates*, select the check-box for the certificate template you created in the previous section (*WHfB Certificate Authentication*) and then select **Enroll**
+1. After a successful certificate request, select **Finish** on the Certificate Installation Results screen
+
+
+
+## Deploy certificates via Intune
+
+> [!NOTE]
+> This process is applicable to both *Azure AD joined* and *hybrid Azure AD joined* devices that are managed via Intune.
+
+Deploying a certificate to Azure AD joined or hybrid Azure AD joined devices may be achieved using the Simple Certificate Enrollment Protocol (SCEP) or PKCS (PFX) via Intune. For guidance deploying the required infrastructure, refer to:
+
+- [Configure infrastructure to support SCEP certificate profiles with Microsoft Intune][MEM-1]
+- [Configure and use PKCS certificates with Intune][MEM-2]
+
+Next, you should deploy the root CA certificate (and any other intermediate certificate authority certificates) to Azure AD joined Devices using a *Trusted root certificate* policy with Intune. For guidance, refer to [Create trusted certificate profiles in Microsoft Intune][MEM-5].
+
+Once these requirements are met, a policy can be configured in Intune that provisions certificates for the users on the targeted device.
+
+
+
+Create a policy in Intune
+
+This section describes how to configure a SCEP policy in Intune. Similar steps can be followed to configure a PKCS policy.
+
+1. Go to the Microsoft Endpoint Manager admin center
+1. Select **Devices > Configuration profiles > Create profile**
+1. Select **Platform > Windows 10 and later** and **Profile type > Templates > SCEP Certificate**
+1. Select **Create**
+1. In the *Basics* panel, provide a **Name** and, optionally, a **Description > Next**
+1. In the *Configuration settings* panel, use the following table to configure the policy:
+
+ | Setting| Configurations |
+ | --- | --- |
+ |*Certificate Type*| User |
+ |*Subject name format* | `CN={{UserPrincipalName}}` |
+ |*Subject alternative name* |From the dropdown, select **User principal name (UPN)** with a value of `CN={{UserPrincipalName}}`
+ |*Certificate validity period* | Configure a value of your choosing|
+ |*Key storage provider (KSP)* | **Enroll to Windows Hello for Business, otherwise fail (Windows 10 and later)**
+ |*Key usage*| **Digital Signature**|
+ |*Key size (bits)* | **2048**|
+ |*For Hash algorithm*|**SHA-2**|
+ |*Root Certificate*| Select **+Root Certificate** and select the trusted certificate profile created earlier for the Root CA Certificate|
+ |*Extended key usage*| - *Name:* **Smart Card Logon**
- *Object Identifier:* `1.3.6.1.4.1.311.20.2.2`
- *Predefined Values:* **Smart Card Logon**
- *Name:* **Client Authentication**
- *Object Identifier:* `1.3.6.1.5.5.7.3.2 `
- *Predefined Values:* **Client Authentication**
|
+ |*Renewal threshold (%)*|Configure a value of your choosing|
+ |*SCEP Server URLs*|Provide the public endpoint(s) that you configured during the deployment of your SCEP infrastructure|
+
+1. Select **Next**
+1. In the *Assignments* panel, assign the policy to a security group that contains as members the devices or users that you want to configure and select **Next**
+1. In the *Applicability Rules* panel, configure issuance restrictions, if needed, and select **Next**
+1. In the *Review + create* panel, review the policy configuration and select **Create**
+
+For more information how to configure SCEP policies, see [Configure SCEP certificate profiles in Intune][MEM-3].
+To configure PKCS policies, see [Configure and use PKCS certificate with Intune][MEM-4].
+
+
+
+
+
+Request a certificate
+Once the Intune policy is created, targeted clients will request a certificate during their next policy refresh cycle. To validate that the certificate is present in the user store, follow these steps:
+
+1. Sign in to a client targeted by the Intune policy
+1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc`
+1. In the left pane of the MMC, expand **Personal** and select **Certificates**
+1. In the right-hand pane of the MMC, check for the new certificate
+
+
+
+## Use third-party certification authorities
+
+If you're using a non-Microsoft PKI, the certificate templates published to the on-premises Active Directory may not be available. For guidance with integration of Intune/SCEP with non-Microsoft PKI deployments, refer to [Use third-party certification authorities (CA) with SCEP in Microsoft Intune][MEM-6].
+
+As an alternative to using SCEP or if none of the previously covered solutions will work in your environment, you can manually generate Certificate Signing Requests (CSR) for submission to your PKI. To assist with this approach, you can use the [Generate-CertificateRequest][HTTP-1] PowerShell commandlet.
+
+The `Generate-CertificateRequest` commandlet will generate an *.inf* file for a pre-existing Windows Hello for Business key. The *.inf* can be used to generate a certificate request manually using `certreq.exe`. The commandlet will also generate a *.req* file, which can be submitted to your PKI for a certificate.
+
+## RDP sign-in with Windows Hello for Business certificate authentication
+
+After obtaining a certificate, users can RDP to any Windows devices in the same Active Directory forest as the user's Active Directory account.
+
+> [!NOTE]
+> The certificate chain of the issuing CA must be trusted by the target server.
+
+1. Open the Remote Desktop Client (`mstsc.exe`) on the client where the authentication certificate has been deployed
+1. Attempt an RDP session to a target server
+1. Use the certificate credential protected by your Windows Hello for Business gesture to authenticate
+
+[MEM-1]: /mem/intune/protect/certificates-scep-configure
+[MEM-2]: /mem/intune/protect/certificates-pfx-configure
+[MEM-3]: /mem/intune/protect/certificates-profile-scep
+[MEM-4]: /mem/intune/protect/certificates-pfx-configure
+[MEM-5]: /mem/intune/protect/certificates-trusted-root
+[MEM-6]: /mem/intune/protect/certificate-authority-add-scep-overview
+
+[HTTP-1]: https://www.powershellgallery.com/packages/Generate-CertificateRequest
\ No newline at end of file
diff --git a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md
index e515250330..03c95bbdde 100644
--- a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md
+++ b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md
@@ -155,6 +155,12 @@ It also blocks automatic or manual attempts to move the paging file.
Enable secure boot and mandatorily prompt a password to change BIOS settings.
For customers requiring protection against these advanced attacks, 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.
+### Tricking BitLocker to pass the key to a rogue operating system
+
+An attacker might modify the boot manager configuration database (BCD) which is stored on a non-encrypted partition and add an entry point to a rogue operating system on a different partition. During the boot process, BitLocker code will make sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, we don’t recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5.
+
+An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This will not succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0, and to successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the BitLocker key.
+
## Attacker countermeasures
The following sections cover mitigations for different types of attackers.
diff --git a/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md b/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
index a00cec360b..c71d2b029e 100644
--- a/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
+++ b/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
@@ -60,7 +60,7 @@ These settings, located at `Computer Configuration\Administrative Templates\Wind
|Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higherWindows 11 Enterprise|Determines whether Application Guard can use the print functionality.|**Enabled.** This is effective only in managed mode. Turns on the print functionality and lets you choose whether to additionally:
- Enable Application Guard to print into the XPS format.
- Enable Application Guard to print into the PDF format.
- Enable Application Guard to print to locally attached printers.
- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.
**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
|Allow Persistence|Windows 10 Enterprise, 1709 or higher
Windows 11 Enterprise|Determines whether data persists across different sessions in Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Application Guard saves user-downloaded files and other items (such as, cookies, Favorites, and so on) for use in future Application Guard sessions.
**Disabled or not configured.** All user data within Application Guard is reset between sessions.
**NOTE**: If you later decide to stop supporting data persistence for your employees, you can use our Windows-provided utility to reset the container and to discard any personal data.
**To reset the container:**
1. Open a command-line program and navigate to `Windows/System32`.
2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.
3. Type `wdagtool.exe cleanup RESET_PERSISTENCE_LAYER`. The container environment is reset, including discarding all employee-generated data.|
|Turn on Microsoft Defender Application Guard in Managed Mode|Windows 10 Enterprise, 1809 or higher
Windows 11 Enterprise|Determines whether to turn on Application Guard for Microsoft Edge and Microsoft Office.|**Enabled.** Turns on Application Guard for Microsoft Edge and/or Microsoft Office, honoring the network isolation settings, rendering untrusted content in the Application Guard container. Application Guard won't actually be turned on unless the required prerequisites and network isolation settings are already set on the device. Available options:
- Enable Microsoft Defender Application Guard only for Microsoft Edge
- Enable Microsoft Defender Application Guard only for Microsoft Office
- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office
**Disabled.** Turns off Application Guard, allowing all apps to run in Microsoft Edge and Microsoft Office.
**Note:** For Windows 10, if you have KB5014666 installed, and for Windows 11, if you have KB5014668 installed, you are no longer required to configure network isolation policy to enable Application Guard for Edge.|
-|Allow files to download to host operating system|Windows 10 Enterprise or Pro, 1803 or higher
Windows 11 Enterprise or Pro|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** This is effective only in managed mode. Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.
**Disabled or not configured.** Users aren't able to save downloaded files from Application Guard to the host operating system.|
+|Allow files to download to host operating system|Windows 10 Enterprise or Pro, 1803 or higher
Windows 11 Enterprise or Pro|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.
**Disabled or not configured.** Users aren't able to save downloaded files from Application Guard to the host operating system.|
|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1803 or higher
Windows 11 Enterprise|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** This is effective only in managed mode. Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.
**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won’t load any third-party graphics drivers or interact with any connected graphics hardware.|
|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher
Windows 11 Enterprise|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.
**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.|
|Allow Microsoft Defender Application Guard to use Root Certificate Authorities from a user's device|Windows 10 Enterprise or Pro, 1809 or higher
Windows 11 Enterprise or Pro|Determines whether Root Certificates are shared with Microsoft Defender Application Guard.|**Enabled.** Certificates matching the specified thumbprint are transferred into the container. Use a comma to separate multiple certificates.
**Disabled or not configured.** Certificates aren't shared with Microsoft Defender Application Guard.|