--- title: Remote Desktop sign-in with Windows Hello for Business description: Learn how you can sign-in via Remote Desktop (RDP) using Windows Hello for Business. ms.date: 12/09/2023 ms.topic: how-to --- # Remote Desktop sign-in with Windows Hello for Business You can use Windows Hello for Business to sign in to a remote desktop session, using the redirected smart card capabilities of the Remote Desktop Protocol (RDP). This is possible by deplyoing a certificate to the user's device, which is then used as the supplied credential when establishing the RDP connection to another Windows device. This article describes three certificate deployment approaches, where authentication certificates are deployed to the Windows Hello for Business container: - Using Microsoft Intune with SCEP or PKCS connectors - Using an Active Directory Certificate Services (AD CS) enrollment policy - Using a third-party PKI > [!TIP] > Consider using Remote Credential Guard instead of Windows Hello for Business for RDP sign-in. Remote Credential Guard provides single sign-on (SSO) to RDP sessions using Kerberos authentication, and doesn't require the deployment of certificates. For more information, see [Remote Credential Guard](../remote-credential-guard.md). ## How it works Windows generates and stores cryptographic keys using a software component called a *key storage provider* (KSP): - Software-based keys are created and stored using the *Microsoft Software Key Storage Provider* - Smart card keys are created and stored using the *Microsoft Smart Card Key Storage Provider* - Keys created and protected by Windows Hello for Business are created and stored using the *Microsoft Passport Key Storage Provider* A certificate on a smart card starts with creating an asymmetric key pair using the Microsoft Smart Card KSP. Windows requests a certificate based on the key pair from your enterprises issuing certificate authority, which returns a certificate that is stored in the user's Personal certificate store. The private key remains on the smart card and the public key is stored with the certificate. Metadata on the certificate (and the key) stores the key storage provider used to create the key (remember the certificate contains the public key). The same concept applies to Windows Hello for Business, except that the keys are created using the Microsoft Passport KSP. The user's private key remains protected by the device's security module (TPM) and the user's gesture (PIN/biometric). The certificate APIs hide the complexity. When an application uses a certificate, the certificate APIs locate the keys using the saved key storage provider. The key storage providers direct the certificate APIs on which provider they use to find the private key associated with the certificate. This is how Windows knows you have a smart card certificate without the smart card inserted, and prompts you to insert the smart card. Windows Hello for Business emulates a smart card for application compatibility, and the Microsoft Passport KSP prompts the user for their biometric gesture or PIN. > [!NOTE] > Remote Desktop with biometric doesn't work with [Dual Enrollment](hello-feature-dual-enrollment.md) or scenarios where the user provides alternative credentials. ## Requirements Here's a list of requiremets to enable RDP sign-in with Windows Hello for Business: > [!div class="checklist"] > * A PKI infrastructure based on AD CS or third-party > * Windows Hello for Business deployed to the clients > * If you plan to support Microsoft Entra joined devices, the domain controllers must have a certificate, which serves as a *root of trust* for the clients. The certificate ensures that clients don't communicate with rogue domain controllers If you plan to deploy certificates using Microsoft Intune, here are additional requiremets: > [!div class="checklist"] > * Ensure you have the infrastructure to support either [SCEP][MEM-1] or [PKCS][MEM-2] deployment > * Deploy the root CA certificate and any other intermediate certificate authority certificates to Microsoft Entra joined Devices using a [Trusted root certificate policy][MEM-5] ## Create a certificate template The process of creating a certificate template is applicable to scenarios where you use an on-premises Active Directory Certificate Services (AD CS) infrastrusture.\ You must first create a certificate template, and then deploy certificates based on that template to the Windows Hello for Business container. The certificate template configuration is different depending on whether you deploy certificates using Microsoft Intune or an AD CS enrollment policy. Select the option that best suits your needs. # [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Microsoft Intune**](#tab/intune) 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: | Tab Name | Configurations | | --- | --- | | *Compatibility* | | | *General* | | | *Extensions* | Verify the **Application Policies** extension includes **Smart Card Logon**.| | *Subject Name* | Select **Supply in the request**.| |*Request Handling*|
**Note:** If you deploy certificates with a PKCS profile, select the option **Allow private key to be exported**| |*Cryptography*|