Merge branch 'main' into patch-1

This commit is contained in:
Tiara Quan
2022-11-17 09:06:57 -08:00
committed by GitHub
16 changed files with 397 additions and 181 deletions

View File

@ -45,5 +45,7 @@
- name: Using a proxy with Delivery Optimization
href: delivery-optimization-proxy.md
- name: Content endpoints for Delivery Optimization and Microsoft Connected Cache
href: delivery-optimization-endpoints.md
href: delivery-optimization-endpoints.md
- name: Testing Delivery Optimization
href: delivery-optimization-test.md

View File

@ -0,0 +1,209 @@
---
title: Testing Delivery Optimization
description: Explanation of Delivery Optimization distributed cache and high-level design. Demonstrate how Delivery Optimization peer-to-peer works in different test scenarios.
ms.date: 11/08/2022
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: reference
ms.localizationpriority: medium
author: cmknox
ms.author: carmenf
ms.reviewer: mstewart
manager: naengler
---
# Testing Delivery Optimization
## Overview
Delivery Optimization is a powerful and useful tool to help enterprises manage bandwidth usage for downloading Microsoft content. It's a solution designed to be used in large-scale environments with large numbers of devices, various content sizes, etc. Delivery Optimization is native to Win10+ and provides default configuration to get the most out of the typical customer environment. It's used to deliver many different types of content, so Microsoft customers enjoy the best possible download experience for their environment. There are three components to Delivery Optimization, 1) HTTP downloader, 2) Peer-to-peer (P2P) cloud technology, and 3) Microsoft Connected Cache. One of the most powerful advantages of using Delivery Optimization is the ability to fine-tune settings that empower users to dial in Microsoft content delivery to meet the needs of specific environments.
## Monitoring The Results
Since Delivery Optimization is on by default, you'll be able to monitor the value either through the Windows Settings for Delivery Optimization, using Delivery Optimization PowerShell [cmdlets.](waas-delivery-optimization-setup.md), and/or via the [Windows Update for Business Report.](../update/wufb-reports-workbook.md) experience in Azure.
In the case where Delivery Optimization isn't working in your environment, it's important to investigate to get to the root of the problem. We recommend a test environment be created to easily evaluate typical devices to ensure Delivery Optimization is working properly. For starters, Scenario 1: Basic Setup should be created to test the use of Delivery Optimization between two machines. This scenario is designed to eliminate any noise in the environment to ensure there's nothing preventing Delivery Optimization from working on the devices. Once you have a baseline, you can expand the test environment for more sophisticated tests.
## Expectations and Goals
The focus of the testing scenarios in this article is primarily centered on demonstrating the Delivery Optimization policies centered around the successful downloading of bytes using P2P. More specifically, the goal will be to show peer to peer is working as expected, using the following criteria:
* Peers can find each other (for example on the same LAN / subnet / Group matching your 'Download Mode' policy).
* Files are downloading in the expected 'Download Mode' policy setting (validates connectivity to DO cloud, HTTP, and local configs).
* At least some downloads happening via P2P (validates connectivity between peers).
Several elements that influence overall peering, using Delivery Optimization. The most common, impactful environment factors should be considered.
* **The number of files in the cache and** **the** **number of devices have a big effect on overall peering.** There's a set number of files available for peering at a time, from each client, so the peering device may not be serving a particular file.
* **File size** **and** **internet connection** **reliability matter.** There's a Delivery Optimization setting to determine the minimum file size to use P2P. In addition, an internet connection must be open and reliable enough to let the Delivery Optimization client make cloud service API calls and download metadata files before starting a file download.
* **Delivery Optimization Policies can play a role.** In general, it's important to familiarize yourself with the Delivery Optimization settings and defaults [Delivery Optimization reference - Windows Deployment | Microsoft Docs.](waas-delivery-optimization-reference.md).
### Delivery Optimization is a Hybrid P2P Platform
* Delivery Optimizations hybrid approach to downloading from multiple sources (HTTP and peer) in parallel is especially critical for large-scale environments, constantly assessing the optimal source from which to deliver the content. In conjunction, the distribution of content cache, across participating devices, contributes to Delivery Optimizations ability to find bandwidth savings as more peers become available.
* At the point a download is initiated, the DO client starts downloading from the HTTP source and discovering peers simultaneously. With a smaller file, most of the bytes could be downloaded from an HTTP source before connecting to a peer, even though peers are available. With a larger file and quality LAN peers, it might reduce the HTTP request rate to near zero, but only after making those initial requests from HTTP.
* In the next section, you'll see how the two testing scenarios produce differing results in the number of bytes coming from HTTP vs. peers, which shows Delivery Optimization continuously evaluating the optimal location from which to download the content.
## Test Scenarios
### Scenario 1: Basic Setup
**Goal:**
Demonstrate how Delivery Optimization peer-to-peer technology works using two machines in a controlled test environment
**Expected Results:**
Machine 1 will download zero bytes from peers and Machine 2 will download 50-99% from peers.
#### Test Machine Setup
|Setup Checklist| Value/Explanation
|--------|-------------------------------|
|Number of machines used| 2 |
|Virtual Machines/physical devices| 2 |
|Windows OS version | Windows 10 (21H2) and Windows 11 (21H2) |
|RAM | 8 GB |
|Disk size | 127 GB |
|Network | Connected to same network, one that is representative of the corporate network. |
|Pause Windows Updates | This controls the test environment so no other content is made available during the test, and potentially altering the outcome of the test. If there are problems and no peering happens, use 'Get-DeliveryOptimizationStatus' on the first machine to return a real-time list of the connected peers. |
|Ensure all Store apps are up to date | This will help prevent any new, unexpected updates to download during testing. |
|Delivery Optimization 'Download Mode' Policy | 2 (Group)(set on each machine) |
|Delivery Optimization 'GroupID' Policy | Set the *same* 'GUID' on each test machine. A GUID is a required value, which can be generated using PowerShell, [[guid]::NewGuid().](https://blogs.technet.microsoft.com/heyscriptingguy/2013/07/25/powertip-create-a-new-guid-by-using-powershell/). |
|**Required on Windows 11 devices only** set Delivery Optimization 'Restrict Peer Selection' policy | 0-NAT (set on each machine). The default behavior in Windows 11 is set to '2-Local Peer Discovery'. For testing purposes, this needs to be scoped to the NAT. |
#### Test Instructions
The following set of instructions will be used for each machine:
1. Open PowerShell console as 'Administrator'.
* Clear the DO cache: 'Delete-DeliveryOptimizationCache'.
* Run 'Get-DeliveryOptimizationStatus'.
2. Open MS Store and search for 'Asphalt Legends 9'. Select *Get* to initiate the download of the content (content size: ~3.4 GB).
**On machine #1**
* Run 'Test Instructions'
|Windows 10 | Windows 11
|--------|-------------------------------|
| :::image type="content" source="images/test-scenarios/win10/m1-basic-complete.png" alt-text="Windows 10 21H2 - Machine 1 - Basic Test." lightbox="images/test-scenarios/win10/m1-basic-complete.png"::: | :::image type="content" source="images/test-scenarios/win11/m1-basic-complete.png" alt-text="Windows 11 21H2 - Machine 1 - Basic Test." lightbox="images/test-scenarios/win11/m1-basic-complete.png"::: |
| **Observations** | |
| * No peers were found on the first machine downloading the content.<br>* 'TotalBytesDownloaded' is equal to the file size.<br>* Status is set to 'Caching' the content so future peers can use it.<br>* Download was happening in the foreground.<br>* DownloadMode is set to 'Group' and no peers were found.<br>* No distinct observations seen between Window 10 and Windows 11 devices. |
*Wait 5 minutes*.
**On machine #2**
* Run 'Test Instructions'
|Windows 10 | Windows 11 |
|--------|--------------------------------|
| :::image type="content" source="images/test-scenarios/win10/m2-basic-complete.png" alt-text="Windows 10 21H2 - Machine 2 - Basic Test." lightbox="images/test-scenarios/win10/m2-basic-complete.png"::: | :::image type="content" source="images/test-scenarios/win11/m2-basic-complete.png" alt-text="Windows 11 21H2 - Machine 2 - Basic Test." lightbox="images/test-scenarios/win11/m2-basic-complete.png":::|
| **Observations** | **Observations**|
| * A peer was found for the content and 87% of total bytes came from the peer. <br> * One peer was found for the piece of content, which is expected as there are only two devices in the peering group. <br> * Download mode was set to 'Group', but since group mode includes both LAN and Group devices, Delivery Optimization prioritizes LAN peers, if found. Therefore, 'BytesFromLanPeers' shows bytes where 'BytesFromGroupPeers' doesn't. <br> * 'DownloadDuration' is roughly the same between machines.|* A peer was found for the content and 90% of total bytes came from the peer. <br> * All other points are the same as Windows 10 results. |
### Scenario 2: Advance Setup
**Goal:**
Demonstrate how Delivery Optimization peer-to-peer technology works in a non-controlled environment and expanding to three machines
**Expected Results:**
Machine 1 will download zero bytes from peers and Machine 2 will find peers and download 50-99% from peers. Machine 3 will find two peers and download 50-99% from peers.
#### Test Machine Setup
|Setup Checklist| Value/Explanation |
|--------|-------------------------------|
|Number of machines used| 3 |
|Virtual Machines| 3 |
|Windows OS version | Windows 10 (21H2) |
|RAM | 8 GB |
|Disk size | 127 GB |
|Network | Connected to same network, one that is representative of the corporate network. |
|Delivery Optimization 'Download Mode' Policy| 2 (Group)(set on each machine) |
|Delivery Optimization 'Group ID' Policy| Set the *same* 'GUID' on each test machine. A GUID is required value, which can be generated using PowerShell, '[guid]::NewGuid().](https://blogs.technet.microsoft.com/heyscriptingguy/2013/07/25/powertip-create-a-new-guid-by-using-powershell/)'. |
|Delivery Optimization 'Delay background download from http' Policy | 60 (set on each machine) |
|Delivery Optimization 'Delay foreground download from http Policy |60 (set on each machine) |
#### Testing Instructions
The following set of instructions will be used for each machine:
1. Clear the DO cache: Delete-DeliveryOptimizationCache.
2. Open MS Store and search for 'Asphalt Legends 9'. Select *Get* to initiate the download of the content (content size: ~3.4 GB).
3. Open PowerShell console as Administrator. Run 'Get-DeliveryOptimizationStatus'.
**On machine #1:**
* Run Test Instructions
**Output: Windows 10 (21H2)**
![Windows 10 21H2 - Machine 1 - Advanced Test.](images/test-scenarios/win10/m1-adv-complete.png)
**Observations**
* The first download in the group of devices shows all bytes coming from HTTP, 'BytesFromHttp'.
* Download is in the Foreground because the Store app is doing the download and in the foreground on the device because it is initiated by the user in the Store app.
* No peers are found.
*Wait 5 minutes*.
**On machine #2:**
* Run Test Instructions
**Output** Windows 10 (21H2)
![Windows 10 21H2 - Machine 2 - Advanced Test.](images/test-scenarios/win10/m2-adv-complete.png)
**Observations**
* 'PercentPeerCaching' is 99.8%
* There are still 'BytesFromHttp' source being used
* One peer was found
* All peering was done from device on the LAN, as shown with 'BytesFromLanPeers'
**On machine #3:**
* Run Test Instructions
**Output:** Windows 10 (21H2)
![Windows 10 21H2 - Machine 3 - Advanced Test.](images/test-scenarios/win10/m3-adv-complete.png)
**Observations**
* 'PercentPeerCaching' is roughly the same as machine #2, at 99.7%.
* Now, two peers are found.
* Still downloading from HTTP source as seen with 'BytesFromHttp' value.
## Peer sourcing observations for all machines in the test group
The distributed nature of the Delivery Optimization technology is obvious when you rerun the Get-DeliveryOptimizationStatus cmdlet on each of the test machines. For each, there's a new value populated for the BytesToLanPeers field. This demonstrates that as more peers become available, the requests to download bytes are distributed across the peering group and act as the source for the peering content. Each peer plays a role in servicing the other.
**Output:** Machine 1
'BytesToPeers' sourced from Machine 1 are '5704426044'. This represents the total number of bytes downloaded by the two peers in the group.
![Windows 10 21H2 - Machine 1 - Advanced BytesToPeers Test.](images/test-scenarios/win10/m1-adv-bytes-to-peers.png)
**Output:** Machine 2
'BytesToPeers' sourced from Machine 2 are '1899143740'. When there are two peers in the group with bytes available, notice that the distribution of bytes comes from either Machine 1 or Machine 2.
![Windows 10 21H2 - Machine 2 - Advanced BytesToPeers Test.](images/test-scenarios/win10/m2-adv-bytes-to-peers.png)
**Output:** Machine 3
'BytesToPeers' sourced from Machine 3 are '0'. This means that no other peers are downloading bytes from this peer, which is expected since it was the last machine in the group.
![Windows 10 21H2 - Machine 3 - Advanced BytesToPeers Test.](images/test-scenarios/win10/m3-adv-bytes-to-peers.png)
## Conclusion
Using Delivery Optimization can help make a big impact in customer environments to optimize bandwidth. The peer-to-peer technology offers many configurations designed to be flexible for any organization. Delivery Optimization uses a distributed cache across different sources to ensure the most optimal download experience, while limiting the resources used on each device.
The testing scenarios found in this document help to show a controlled test environment, helping to prevent updates from interrupting the peering results. The other, a more real-world case, demonstrates how content available across peers will be used as the source of the content.
If there are issues found while testing, the Delivery Optimization PowerShell [cmdlets.](waas-delivery-optimization-setup.md) can be a helpful tool to help explain what is happening in the environment.

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 101 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 77 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 384 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 105 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 101 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 107 KiB

View File

@ -99,4 +99,6 @@ landingContent:
url: delivery-optimization-proxy.md
- text: Content endpoints for Delivery Optimization and Microsoft Connected Cache
url: delivery-optimization-endpoints.md
- text: Testing Delivery Optimization
url: delivery-optimization-test.md

Binary file not shown.

Before

Width:  |  Height:  |  Size: 61 KiB

After

Width:  |  Height:  |  Size: 50 KiB

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