deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-28 05:07:23 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'main' of github.com:MicrosoftDocs/windows-docs-pr into pm-20221117-docfx-updates

Browse Source
This commit is contained in:
Paolo Matarazzo 2022-11-17 16:09:19 -05:00
commit c618894943
8 changed files with 216 additions and 185 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
windows/deployment/update/images/update-terminology.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 61 KiB

After

Width:  |  Height:  |  Size: 50 KiB

4
windows/deployment/update/servicing-stack-updates.md
View File

@ -40,7 +40,9 @@ Servicing stack update are released depending on new issues or vulnerabilities.
Both Windows client and Windows Server use the cumulative update mechanism, in which many fixes to improve the quality and security of Windows are packaged into a single update. Each cumulative update includes the changes and fixes from all previous updates.
Servicing stack updates must ship separately from the cumulative updates because they modify the component that installs Windows updates. The servicing stack is released separately because the servicing stack itself requires an update. For example, the cumulative update [KB4284880](https://support.microsoft.com/help/4284880/windows-10-update-kb4284880) requires the [May 17, 2018 servicing stack update](https://support.microsoft.com/help/4132216), which includes updates to Windows Update.
Servicing stack updates improve the reliability of the update process to mitigate potential issues while installing the latest quality updates and feature updates. If you don't install the latest servicing stack update, there's a risk that your device can't be updated with the latest Microsoft security fixes.
Beginning with the February 2021 LCU, Microsoft will publish all future cumulative updates and SSUs for Windows 10, version 2004 and later together as one cumulative monthly update to the normal release category in WSUS.
## Is there any special guidance?

2
windows/deployment/update/waas-manage-updates-wufb.md
View File

@ -48,7 +48,7 @@ Windows Update for Business enables an IT administrator to receive and manage a
Windows Update for Business provides management policies for several types of updates to Windows 10 devices:
- **Feature updates:** Previously referred to as "upgrades," feature updates contain not only security and quality revisions, but also significant feature additions and changes. Feature updates are released as soon as they become available.
- **Quality updates:** Quality updates are traditional operating system updates, typically released on the second Tuesday of each month (though they can be released at any time). These include security, critical, and driver updates. Windows Update for Business also treats non-Windows updates (such as updates for Microsoft Office or Visual Studio) as quality updates. These non-Windows Updates are known as "Microsoft updates" and you can set devices to receive such updates (or not) along with their Windows updates.
- **Quality updates:** Quality updates are traditional operating system updates, typically released on the second Tuesday of each month (though they can be released at any time). These include security, critical, and driver updates.
- **Driver updates:** Updates for non-Microsoft drivers that are relevant to your devices. Driver updates are on by default, but you can use Windows Update for Business policies to turn them off if you prefer.
- **Microsoft product updates**: Updates for other Microsoft products, such as versions of Office that are installed by using Windows Installer (MSI). Versions of Office that are installed by using Click-to-Run can't be updated by using Windows Update for Business. Product updates are off by default. You can turn them on by using Windows Update for Business policies.

30
windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md
View File

@ -1,7 +1,7 @@
---
title: Fix issues found by the Readiness assessment tool
description: This article details how to fix issues found by the Readiness assessment tool
ms.date: 05/30/2022
ms.date: 11/17/2022
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: how-to
@ -14,7 +14,9 @@ msreviewer: hathind
# Fix issues found by the Readiness assessment tool
Seeing issues with your tenant? This article details how to remediate issues found with your tenant.
Seeing issues with your tenant? This article details how to remediate issues found with your tenant.
If you need more assistance with tenant enrollment, you can submit a [tenant enrollment support request](#submit-a-support-request).
## Check results
@ -70,3 +72,27 @@ Windows Autopatch requires the following licenses:
| Result | Meaning |
| ----- | ----- |
| Not ready | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Azure Active Directory Premium, and Microsoft Intune are required. For more information, see [more about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses). |
## Submit a support request
> [!IMPORTANT]
> Make sure you've [added and verified your admin contacts](../deploy/windows-autopatch-admin-contacts.md). The Windows Autopatch Service Engineering Team will contact these individuals for assistance with troubleshooting issues.
If you need more assistance with tenant enrollment, you can submit support tickets to the Windows Autopatch Service Engineering Team in the Windows Autopatch enrollment tool. Email is the recommended approach to interact with the Windows Autopatch Service Engineering Team.
**To submit a new support request:**
1. If the Readiness assessment tool fails, remediation steps can be found by selecting **View details** under **Management settings** and then selecting the individual check. The **Contact Support** button will be available below remediation instructions in the fly-in-pane.
2. Enter your question(s) and/or a description of the problem.
3. Review all the information you provided for accuracy.
4. When you're ready, select **Create**.
### Manage an active support request
The primary contact for the support request will receive email notifications when a case is created, assigned to a service engineer to investigate, and mitigated. If you have a question about the case, the best way to get in touch is to reply directly to one of the emails. If we have questions about your request or need more details, we'll email the primary contact listed in the support request.
**To view all your active pre-enrollment support requests:**
1. Sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and navigate to the **Tenant Administration** menu.
1. In the **Windows Autopatch** section, select **Tenant Enrollment**.
1. Select the **Support history** tab. You can view the list of all support cases, or select an individual case to view the details.

3
windows/deployment/windows-autopilot/demonstrate-deployment-on-vm.md
View File

@ -47,6 +47,9 @@ You'll need the following components to complete this lab:
|**Hyper-V or a physical device running Windows 10**|The guide assumes that you'll use a Hyper-V VM, and provides instructions to install and configure Hyper-V if needed. To use a physical device, skip the steps to install and configure Hyper-V.|
|**An account with Azure Active Directory (Azure AD) Premium license**|This guide will describe how to get a free 30-day trial Azure AD Premium subscription that can be used to complete the lab.|
> [!NOTE]
> When using a VM for Autopilot testing, assign at least two processors and 4 GB of memory.
## Procedures
A summary of the sections and procedures in the lab is provided below. Follow each section in the order it's presented, skipping the sections that don't apply to you. Optional procedures are provided in the appendices.

354
windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
View File

@ -1,207 +1,201 @@
---
title: Deploying Certificates to Key Trust Users to Enable RDP
description: Learn how to deploy certificates to a Key Trust user to enable remote desktop with supplied credentials
title: Deploy certificates for remote desktop sign-in
description: Learn how to deploy certificates to cloud Kerberos trust and key trust users, to enable remote desktop sign-in with supplied credentials.
ms.prod: windows-client
author: paolomatarazzo
ms.author: paoloma
manager: aaroncz
ms.reviewer: prsriva
ms.reviewer: erikdau
ms.collection:
- M365-identity-device-management
- ContentEngagementFY23
ms.topic: article
ms.topic: how-to
localizationpriority: medium
ms.date: 02/22/2021
appliesto:
- ✅ <b>Windows 10</b>
- ✅ <b>Windows 11</b>
- ✅ <b>Hybrid deployment</b>
- ✅ <b>Key trust</b>
- ✅ <b>Cloud Kerberos trust</b>
ms.date: 11/15/2022
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10 and later</a>
ms.technology: itpro-security
---
# Deploy Certificates to Key Trust and Cloud Kerberos Trust Users to Enable RDP
# Deploy certificates for remote desktop (RDP) sign-in
Windows Hello for Business supports using a certificate as the supplied credential when establishing a remote desktop connection to a server or other device. For certificate trust deployments, creation of this certificate occurs at container creation time.
This document describes Windows Hello for Business functionalities or scenarios that apply to:\
✅ **Deployment type:** [hybrid](hello-how-it-works-technology.md#hybrid-deployment)\
✅ **Trust type:** [cloud Kerberos trust](hello-hybrid-cloud-kerberos-trust.md), [ key trust](hello-how-it-works-technology.md#key-trust)\
✅ **Device registration type:** [Azure AD join](hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](hello-how-it-works-technology.md#hybrid-azure-ad-join)
This document discusses an approach for key trust and cloud Kerberos trust deployments where authentication certificates can be deployed to an existing WHFB user.
<br>
Three approaches are documented here:
---
1. Deploying a certificate to hybrid joined devices using an on-premises Active Directory certificate enrollment policy.
Windows Hello for Business supports using a certificate as the supplied credential, when establishing a remote desktop connection to another Windows device. This document discusses three approaches for *cloud Kerberos trust* and *key trust* deployments, where authentication certificates can be deployed to an existing Windows Hello for Business user:
1. Deploying a certificate to hybrid or Azure AD-joined devices using Simple Certificate Enrollment Protocol (SCEP) and Intune.
- Deploy certificates to hybrid joined devices using an on-premises Active Directory Certificate Services enrollment policy
- Deploy certificates to hybrid or Azure AD-joined devices using Intune
- Work with third-party PKIs
1. Working with non-Microsoft enterprise certificate authorities.
## Deploying a certificate to a hybrid joined device using an on-premises Active Directory Certificate enrollment policy
### Create a Windows Hello for Business certificate template
1. Sign in to your issuing certificate authority (CA).
1. Open the **Certificate Authority** Console (%windir%\system32\certsrv.msc).
1. In the left pane of the MMC, expand **Certification Authority (Local)**, and then expand your CA within the Certification Authority list.
1. Right-click **Certificate Templates** and then click **Manage** to open the **Certificate Templates** console.
1. Right-click the **Smartcard Logon** template and click **Duplicate Template**
![Duplicating Smartcard Template.](images/rdpcert/duplicatetemplate.png)
1. On the **Compatibility** tab:
1. Clear the **Show resulting changes** check box
1. Select **Windows Server 2012 or Windows Server 2012 R2** from the Certification Authority list
1. Select **Windows Server 2012 or Windows Server 2012 R2** from the Certification Recipient list
1. On the **General** tab:
1. Specify a Template display name, such as **WHfB Certificate Authentication**
1. Set the validity period to the desired value
1. Take note of the Template name for later, which should be the same as the Template display name minus spaces (**WHfBCertificateAuthentication** in this example).
1. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**.
1. On the **Subject Name** tab:
1. Select the **Build from this Active Directory** information button if it is not already selected
1. Select **Fully distinguished name** from the **Subject name format** list if Fully distinguished name is not already selected
1. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
1. On the **Request Handling** tab:
1. Select the **Renew with same key** check box
1. Set the Purpose to **Signature and smartcard logon**
1. Click **Yes** when prompted to change the certificate purpose
1. Click **Prompt the user during enrollment**
1. On the **Cryptography** tab:
1. Set the Provider Category to **Key Storage Provider**
1. Set the Algorithm name to **RSA**
1. Set the minimum key size to **2048**
1. Select **Requests must use one of the following providers**
1. Tick **Microsoft Software Key Storage Provider**
1. Set the Request hash to **SHA256**
1. On the **Security** tab, 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. Click **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:
`certutil -dstemplate \<TemplateName\> \> \<TemplateName\>.txt`
Replace \<TemplateName\> with the Template name you took note of earlier in step 7.
1. Open the text file created by the command above.
1. Delete the last line of the output from the file that reads **CertUtil: -dsTemplate command completed successfully.**
1. 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:
certutil -dsaddtemplate \<TemplateName\>.txt
1. In the Certificate Authority console, right-click **Certificate Templates**, select **New**, and select **Certificate Template to Issue**
![Selecting Certificate Template to Issue.](images/rdpcert/certificatetemplatetoissue.png)
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…**
![Request a new certificate.](images/rdpcert/requestnewcertificate.png)
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.
<br>
<details>
<summary><b>Create a Windows Hello for Business certificate template</b></summary>
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* | <ul><li>Clear the **Show resulting changes** check box</li><li>Select **Windows Server 2012 or Windows Server 2012 R2** from the *Certification Authority list*</li><li>Select **Windows Server 2012 or Windows Server 2012 R2** from the *Certification Recipient list*</li></ul>|
| *General* | <ul><li>Specify a **Template display name**, for example *WHfB Certificate Authentication*</li><li>Set the validity period to the desired value</li><li>Take note of the Template name for later, which should be the same as the Template display name minus spaces (*WHfBCertificateAuthentication* in this example)</li></ul>|
| *Extensions* | Verify the **Application Policies** extension includes **Smart Card Logon**|
| *Subject Name* | <ul><li> Select the **Build from this Active Directory** information button if it isn't already selected</li><li>Select **Fully distinguished name** from the **Subject name format** list if Fully distinguished name isn't already selected</li><li>Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**</li></ul>|
|*Request Handling*|<ul><li>Set the Purpose to **Signature and smartcard logon** and select **Yes** when prompted to change the certificate purpose</li><li>Select the **Renew with same key** check box</li><li>Select **Prompt the user during enrollment**</li></ul>|
|*Cryptography*|<ul><li>Set the Provider Category to **Key Storage Provider**</li><li>Set the Algorithm name to **RSA**</li><li>Set the minimum key size to **2048**</li><li>Select **Requests must use one of the following providers**</li><li>Select **Microsoft Software Key Storage Provider**</li><li>Set the Request hash to **SHA256**</li></ul>|
|*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 `<TemplateName>` with the **Template display name** noted above
```cmd
certutil.exe -dstemplate <TemplateName> > <TemplateName.txt>
```
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 <TemplateName.txt>
```
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**
</details>
<br>
<details>
<summary><b>Request a certificate</b></summary>
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
</details>
## 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.
<br>
<details>
<summary><b>Create a policy in Intune</b></summary>
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 <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
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*| <ul><li>*Name:* **Smart Card Logon**</li><li>*Object Identifier:* `1.3.6.1.4.1.311.20.2.2`</li><li>*Predefined Values:* **Smart Card Logon**</li><br><li>*Name:* **Client Authentication**</li><li>*Object Identifier:* `1.3.6.1.5.5.7.3.2 `</li><li>*Predefined Values:* **Client Authentication**</li></ul>|
|*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].
</details>
<br>
<details>
<summary><b>Request a certificate</b></summary>
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
</details>
## 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

6
windows/security/information-protection/bitlocker/bitlocker-countermeasures.md
View File

@ -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.

2
windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
View File

@ -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 higher<p>Windows 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:<br/>- Enable Application Guard to print into the XPS format.<br/>- Enable Application Guard to print into the PDF format.<br/>- Enable Application Guard to print to locally attached printers.<br/>- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.<br/><br/>**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
|Allow Persistence|Windows 10 Enterprise, 1709 or higher<p>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.<p>**Disabled or not configured.** All user data within Application Guard is reset between sessions.<p>**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.<p>**To reset the container:**<br/>1. Open a command-line program and navigate to `Windows/System32`.<br/>2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.<br/>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<p>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:<br/>- Enable Microsoft Defender Application Guard only for Microsoft Edge<br/>- Enable Microsoft Defender Application Guard only for Microsoft Office<br/>- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office<br/><br/>**Disabled.** Turns off Application Guard, allowing all apps to run in Microsoft Edge and Microsoft Office. <br/><br/>**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<p>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.<p>**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<p>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.<p>**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<p>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.<br><br>**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<p>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.<p>**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<p>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.<p>**Disabled or not configured.** Certificates aren't shared with Microsoft Defender Application Guard.|