deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 21:37:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #9204 from MicrosoftDocs/main

Browse Source 
Publish main to live 12/11/2023, 3:30 PM
This commit is contained in:
Gary Moore 2023-12-11 15:40:09 -08:00 committed by GitHub
commit 3c36b00b70
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
13 changed files with 362 additions and 276 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
.openpublishing.redirection.windows-security.json
View File

@ -8039,6 +8039,16 @@
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/firewall-settings-lost-on-upgrade.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/rdp-sign-in",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/rdp-sign-in",
"redirect_document_id": false
}
]
}

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

@ -1,172 +0,0 @@
---
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.topic: how-to
ms.date: 07/25/2023
---
# Deploy certificates for remote desktop (RDP) sign-in
This document describes Windows Hello for Business functionalities or scenarios that apply to:
- **Deployment type:** [!INCLUDE [hybrid](./includes/hello-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [cloud-kerberos](./includes/hello-trust-cloud-kerberos.md)], [!INCLUDE [key](./includes/hello-trust-key.md)]
- **Join type:** [!INCLUDE [hello-join-aadj](./includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](./includes/hello-join-hybrid.md)]
---
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:
- Deploy certificates to hybrid joined devices using an on-premises Active Directory Certificate Services enrollment policy
- Deploy certificates to hybrid or Microsoft Entra joined devices using Intune
- Work with third-party PKIs
## Deploy certificates via Active Directory Certificate Services (AD CS)
> [!NOTE]
> This process is applicable to *Microsoft Entra hybrid joined* devices only.
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.
### Create a Windows Hello for Business certificate template
Follow these steps to create a certificate template:
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* | <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><br>**Note:** If you deploy certificates via Intune, select **Supply in the request** instead of *Build from this Active Directory*.|
|*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. 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**
### Request a certificate
1. Sign in to a client that is Microsoft Entra hybrid 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
> [!CAUTION]
> This process is applicable to both *Microsoft Entra joined* and *Microsoft Entra hybrid joined* devices that are managed via Intune.
>
> If you deploy certificates via Intune and configure Windows Hello for Business via group policy, the devices will fail to obtain a certificate, logging the error code `0x82ab0011` in the `DeviceManagement-Enterprise-Diagnostic-Provider` log.\
> To avoid the error, configure Windows Hello for Business via Intune instead of group policy.
Deploying a certificate to Microsoft Entra joined or Microsoft Entra hybrid 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 Microsoft Entra 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 <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Intune 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 `{{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:* **Not configured**</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].
### Request a certificate for Intune clients
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

4
windows/security/identity-protection/hello-for-business/hello-faq.yml
View File

@ -5,7 +5,7 @@ metadata:
author: paolomatarazzo
ms.author: paoloma
ms.topic: faq
ms.date: 08/03/2023
ms.date: 12/08/2023
title: Common questions about Windows Hello for Business
summary: Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This Frequently Asked Questions (FAQ) article is intended to help you learn more about Windows Hello for Business.
@ -242,7 +242,7 @@ sections:
- attempting to access on-premises resources secured by Active Directory
- question: Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust?
answer: |
Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](rdp-sign-in.md) for this purpose.
- question: Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust?
answer: |
No, only the number necessary to handle the load from all cloud Kerberos trust devices.

47
windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md
View File

@ -1,47 +0,0 @@
---
title: Remote Desktop
description: Learn how Windows Hello for Business supports using biometrics with remote desktop
ms.date: 09/01/2023
ms.topic: conceptual
---
# Remote Desktop
**Requirements**
- Hybrid and On-premises Windows Hello for Business deployments
- Microsoft Entra joined, Microsoft Entra hybrid joined, and Enterprise joined devices
Windows Hello for Business supports using a certificate deployed to a Windows Hello for Business container as a supplied credential to establish a remote desktop connection to a server or another device. This feature takes advantage of the redirected smart card capabilities of the remote desktop protocol. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md) to establish a remote desktop protocol connection.
Microsoft continues to investigate supporting using keys trust for supplied credentials in a future release.
## Remote Desktop with Biometrics
**Requirements**
- Hybrid and On-premises Windows Hello for Business deployments
- Microsoft Entra joined, Microsoft Entra hybrid joined, and Enterprise joined devices
- Biometric enrollments
The ability for users to authenticate to a remote desktop session using their Windows Hello for Business biometric is on by default.
### How does it work
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.
### Compatibility
Users appreciate convenience of biometrics and administrators value the security however, you may experience compatibility issues with your applications and Windows Hello for Business certificates. You can relax knowing a Group Policy setting and a [MDM URI](/windows/client-management/mdm/passportforwork-csp) exist to help you revert to the previous behavior for those users who need it.
> [!div class="mx-imgBorder"]
> ![WHFB Certificate GP Setting.](images/rdpbio/rdpbiopolicysetting.png)
> [!IMPORTANT]
> The remote desktop with biometric feature does not work with [Dual Enrollment](hello-feature-dual-enrollment.md) feature or scenarios where the user provides alternative credentials. Microsoft continues to investigate supporting the feature.

73
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
View File

@ -79,45 +79,45 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync
2. Select **Sign in to Graph Explorer** and provide Azure credentials.
> [!NOTE]
> To successfully query the Graph API, adequate [permissions](/graph/api/user-get?) must be granted.
> [!NOTE]
> To successfully query the Graph API, adequate [permissions](/graph/api/user-get?) must be granted.
3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You'll now be prompted for delegated permissions consent.
4. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Microsoft Entra ID. Select **Run query**.
> [!NOTE]
> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters, we will use the $select [Optional OData query parameter](/graph/api/user-get?). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios.
> [!NOTE]
> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters, we will use the $select [Optional OData query parameter](/graph/api/user-get?). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios.
#### Request
#### Request
<!-- {
<!-- {
"blockType": "request",
"name": "get_user_select"
} -->
```msgraph-interactive
GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}?$select=displayName,userPrincipalName,onPremisesDistinguishedName
```
} -->
```msgraph-interactive
GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}?$select=displayName,userPrincipalName,onPremisesDistinguishedName
```
5. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute. Ensure the attribute has a value and that the value is accurate for the given user. If the **onPremisesDistinguishedName** attribute isn't synchronized the value will be **null**.
#### Response
<!-- {
#### Response
<!-- {
"blockType": "response",
"truncated": true,
"@odata.type": "microsoft.graph.user"
} -->
```http
HTTP/1.1 200 OK
Content-type: application/json
} -->
```http
HTTP/1.1 200 OK
Content-type: application/json
{
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(displayName,userPrincipalName,onPremisesDistinguishedName)/$entity",
"displayName": "Nestor Wilke",
"userPrincipalName": "NestorW@contoso.com",
"onPremisesDistinguishedName" : "CN=Nestor Wilke,OU=Operations,DC=contoso,DC=com"
}
```
}
```
## Prepare the Network Device Enrollment Services (NDES) Service Account
@ -250,7 +250,7 @@ Sign-in to the issuing certificate authority with access equivalent to _local ad
1. Open an elevated command prompt and type the following command:
```console
```cmd
certutil -setreg Policy\EditFlags +EDITF_ATTRIBUTEENDDATE
```
@ -428,13 +428,13 @@ Sign-in the NDES server with access equivalent to _Domain Admins_.
2. Type the following command to register the service principal name
```console
```cmd
setspn -s http/[FqdnOfNdesServer] [DomainName\\NdesServiceAccount]
```
where **[FqdnOfNdesServer]** is the fully qualified domain name of the NDES server and **[DomainName\NdesServiceAccount]** is the domain name and NDES service account name separated by a backslash (\\). An example of the command looks like the following:
```console
```cmd
setspn -s http/ndes.corp.contoso.com contoso\ndessvc
```
@ -486,7 +486,7 @@ Sign-in to the certificate authority or management workstations with an _Enterpr
> [!NOTE]
> If you closed Server Manger from the last set of tasks, start Server Manager and click the action flag that shows a yellow exclamation point.
![Server Manager Post-Install Yellow flag.](images/aadjcert/servermanager-post-ndes-yellowactionflag.png)
:::image type="content" alt-text="Server Manager Post-Install Yellow flag." source="images/aadjcert/servermanager-post-ndes-yellowactionflag.png" lightbox="images/aadjcert/servermanager-post-ndes-yellowactionflag.png":::
1. Select the **Configure Active Directory Certificate Services on the destination server** link.
@ -544,13 +544,13 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
3. Type the following command:
```console
```cmd
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName]
```
where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Microsoft Entra joined devices. Example:
```console
```cmd
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication
```
@ -583,7 +583,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
4. Select **Download connector service**. Select **Accept terms & Download**. Save the file (AADApplicationProxyConnectorInstaller.exe) in a location accessible by others on the domain.
![Azure Application Proxy Connectors.](images/aadjcert/azureconsole-applicationproxy-connectors-empty.png)
:::image type="content" alt-text="Azure Application Proxy Connectors." source="images/aadjcert/azureconsole-applicationproxy-connectors-empty.png" lightbox="images/aadjcert/azureconsole-applicationproxy-connectors-empty.png":::
5. Sign-in the computer that will run the connector with access equivalent to a _domain user_.
@ -616,11 +616,11 @@ Sign-in a workstation with access equivalent to a _domain user_.
3. Under **MANAGE**, select **Application proxy**.
![Azure Application Proxy Connector groups.](images/aadjcert/azureconsole-applicationproxy-connectors-default.png)
:::image type="content" alt-text="Azure Application Proxy Connector groups." source="images/aadjcert/azureconsole-applicationproxy-connectors-default.png" lightbox="images/aadjcert/azureconsole-applicationproxy-connectors-default.png":::
4. Select **New Connector Group**. Under **Name**, type **NDES WHFB Connectors**.
![Azure Application New Connector Group.](images/aadjcert/azureconsole-applicationproxy-connectors-newconnectorgroup.png)
:::image type="content" alt-text="Azure Application New Connector Group." source="images/aadjcert/azureconsole-applicationproxy-connectors-newconnectorgroup.png" lightbox="images/aadjcert/azureconsole-applicationproxy-connectors-newconnectorgroup.png":::
5. Select each connector agent in the **Connectors** list that will service Windows Hello for Business certificate enrollment requests.
@ -644,7 +644,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
7. Under **Internal URL**, select **https://** from the first list. In the text box next to **https://**, type the hostname you want to use as your external hostname for the Microsoft Entra application proxy. In the list next to the hostname you typed, select a DNS suffix you want to use externally for the Microsoft Entra application proxy. It's recommended to use the default, -[tenantName].msapproxy.net where **[tenantName]** is your current Microsoft Entra tenant name (-mstephendemo.msappproxy.net).
![Azure NDES Application Proxy Configuration.](images/aadjcert/azureconsole-appproxyconfig.png)
:::image type="content" alt-text="Azure NDES Application Proxy Configuration." source="images/aadjcert/azureconsole-appproxyconfig.png" lightbox="images/aadjcert/azureconsole-appproxyconfig.png":::
8. Select **Passthrough** from the **Pre Authentication** list.
@ -699,7 +699,7 @@ Sign-in the NDES server with access equivalent to _local administrator_.
2. Expand the node that has the name of the NDES server. Expand **Sites** and select **Default Web Site**.
![NDES IIS Console](images/aadjcert/ndes-iis-console.png)
:::image type="content" alt-text="NDES IIS Console" source="images/aadjcert/ndes-iis-console.png" lightbox="images/aadjcert/ndes-iis-console.png":::
3. Select **Bindings...** under **Actions**. Select **Add**.
@ -771,7 +771,7 @@ Sign-in the NDES server with access equivalent to _local administrator_.
3. In the content pane, double-click **Request Filtering**. Select **Edit Feature Settings...** in the action pane.
![Intune NDES Request filtering.](images/aadjcert/NDES-IIS-RequestFiltering.png)
:::image type="content" alt-text="Intune NDES Request filtering." source="images/aadjcert/NDES-IIS-RequestFiltering.png" lightbox="images/aadjcert/NDES-IIS-RequestFiltering.png":::
4. Select **Allow unlisted file name extensions**.
@ -793,7 +793,7 @@ Sign-in the NDES server with access equivalent to _local administrator_.
2. Run the following commands:
```console
```cmd
reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 65534
reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 65534
```
@ -842,7 +842,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
7. Select **Assigned** from the **Membership type** list.
![Microsoft Entra new group creation.](images/aadjcert/azureadcreatewhfbcertgroup.png)
:::image type="content" alt-text="Microsoft Entra new group creation." source="images/aadjcert/azureadcreatewhfbcertgroup.png" lightbox="images/aadjcert/azureadcreatewhfbcertgroup.png":::
8. Select **Members**. Use the **Select members** pane to add members to this group. When finished, select **Select**.
@ -880,7 +880,8 @@ Sign-in a workstation with access equivalent to a _domain user_.
11. Next to **Subject name format**, type **CN={{OnPrem_Distinguished_Name}}** to make the on-premises distinguished name the subject of the issued certificate.
> [!NOTE]
> If the distinguished name contains special characters like a plus sign ("+"), comma (","), semicolon (";"), or equal sign ("="), the bracketed name must be enclosed in quotation marks: CN=”{{OnPrem_Distinguished_Name}}”.
> If the distinguished name contains special characters like a plus sign ("+"), comma (","), semicolon (";"), or equal sign ("="), the bracketed name must be enclosed in quotation marks: `CN="{{OnPrem_Distinguished_Name}}"`.
>
> If the length of the distinguished name is more than 64 characters, the name length enforcement on the Certification Authority [must be disabled](/previous-versions/windows/it-pro/windows-server-2003/cc784789(v=ws.10)?#disable-dn-length-enforcement).
12. Specify **User Principal Name (UPN)** as a **Subject Alternative Name** parameter. Set its value as {{UserPrincipalName}}.
@ -893,7 +894,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
16. Type a percentage (without the percent sign) next to **Renewal Threshold** to determine when the certificate should attempt to renew. The recommended value is **20**.
![WHFB SCEP certificate Profile EKUs.](images/aadjcert/profile03.png)
:::image type="content" alt-text="WHFB SCEP certificate Profile EKUs." source="images/aadjcert/profile03.png" lightbox="images/aadjcert/profile03.png":::
17. Under **SCEP Server URLs**, type the fully qualified external name of the Microsoft Entra application proxy you configured. Append to the name **/certsrv/mscep/mscep.dll**. For example, ```https://ndes-mtephendemo.msappproxy.net/certsrv/mscep/mscep.dll```. Select **Add**. Repeat this step for each additional NDES Microsoft Entra application proxy you configured to issue Windows Hello for Business certificates. Microsoft Intune round-robin load balances requests among the URLs listed in the SCEP certificate profile.
@ -915,7 +916,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
5. In the **Assignments** pane, select **Selected Groups** from the **Assign to** list. Select **Select groups to include**.
![WHFB SCEP Profile Assignment.](images/aadjcert/profile04.png)
:::image type="content" alt-text="WHFB SCEP Profile Assignment." source="images/aadjcert/profile04.png" lightbox="images/aadjcert/profile04.png":::
6. Select the **AADJ WHFB Certificate Users** group. Select **Select**.

BIN
windows/security/identity-protection/hello-for-business/images/rdp/rdc-entra-hybrid-joined.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
windows/security/identity-protection/hello-for-business/images/rdp/rdc-entra-joined.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
windows/security/identity-protection/hello-for-business/images/rdp/rdp-certificate-template.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 181 KiB

BIN
windows/security/identity-protection/hello-for-business/images/rdpbio/RDPBioPolicySetting.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 42 KiB

296
windows/security/identity-protection/hello-for-business/rdp-sign-in.md Normal file
View File

@ -0,0 +1,296 @@
---
title: Remote Desktop sign-in with Windows Hello for Business
description: Learn how to configure Remote Desktop (RDP) sign-in with Windows Hello for Business.
ms.date: 12/11/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 deploying 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 two 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
> [!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 requirements 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 more requirements:
> [!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) infrastructure.\
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 Active Directory 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* | <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* | Select **Supply in the request**.|
|*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><br>**Note:** If you deploy certificates with a PKCS profile, select the option **Allow private key to be exported**|
|*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>|
|*Security*|Add the security principal used for SCEP or PKCS **Enroll** access|
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
# [:::image type="icon" source="../../images/icons/certificate.svg" border="false"::: **AD CS policy**](#tab/adcs)
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* | <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>|
|*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. 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
### Add Microsoft Passport Key Storage Provider to the certificate template
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 in the table
```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>
```
:::row:::
:::column span="3":::
>[!NOTE]
>You can verify that the template is updated by checking its properties.
:::column-end:::
:::column span="1":::
:::image type="content" source="images/rdp/rdp-certificate-template.png" alt-text="Screenshot of the RDP certificate template updated with the Passport KSP." lightbox="images/rdp/rdp-certificate-template.png" border="false":::
:::column-end:::
:::row-end:::
---
### Issue the certificate template
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**
## Deploy certificates
The process of deploying certificates is different depending on whether you use Microsoft Intune or an Active Directory enrollment policy. Select the option that best suits your needs.
# [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Microsoft Intune**](#tab/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 <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Intune 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}}` <br><br>**Note:** if there's a mismatch between the user UPN suffix and the Active Directory domain FQDN, use `CN={{OnPrem_Distinguished_Name}}` instead.|
|*Subject alternative name* |From the dropdown, select **User principal name (UPN)** with a value of `{{UserPrincipalName}}`|
|*Certificate validity period* | Configure a value of your choosing|
|*Key storage provider (KSP)* | **Enroll to Windows Hello for Business, otherwise fail**|
|*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:* **Not configured**</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].
> [!CAUTION]
>
> If you deploy certificates via Intune and configure Windows Hello for Business via group policy, the devices will fail to obtain a certificate, logging the error code `0x82ab0011` in the `DeviceManagement-Enterprise-Diagnostic-Provider` log.\
> To avoid the error, configure Windows Hello for Business via Intune instead of group policy.
# [:::image type="icon" source="../../images/icons/certificate.svg" border="false"::: **AD CS policy**](#tab/adcs)
Here are the steps to manually request a certificate using an Active Directory Certificate Services enrollment policy:
1. Sign in to a client that is Microsoft Entra hybrid 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
---
## 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 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 generates 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 also generates a `.req` file, which can be submitted to your PKI for a certificate.
## Verify that the certificate is deployed
To verify that the certificate is correctly deployed to the Windows Hello for Business container, use the following command:
```cmd
certutil -store -user my
```
The output lists keys and certificates stored in the user store. If a certificate issued from your CA is deployed to the Windows Hello for Business container, the output displays the certificate with a `Provider` value of `Microsoft Passport Key Storage Provider`.
For example:
```cmd
C:\Users\amanda.brady>certutil -store -user my
my "Personal"
================ Certificate 0 ================
Serial Number: 110000001f4c4eccc46fc8f93a00000000001f
Issuer: CN=Contoso - Issuing CA, DC=CONTOSO, DC=COM
NotBefore: 12/8/2023 6:16 AM
NotAfter: 12/7/2024 6:16 AM
Subject: CN=amanda.brady@contoso.com
Non-root Certificate
Template: 1.3.6.1.4.1.311.21.8.2835349.12167323.7094945.1118853.678601.83.11484210.8005739
Cert Hash(sha1): 63c6ce5fc512933179d3c0a5e94ecba98092f93d
Key Container = S-1-12-1-../../login.windows.net/../amanda.brady@contoso.com
Provider = Microsoft Passport Key Storage Provider
Private key is NOT exportable
Encryption test passed
```
## User experience
Once users obtain their certificate, they can RDP to any Windows devices in the same Active Directory forest as the users' Active Directory account by opening Remote Desktop Connection (`mstsc.exe`). When connecting to the remote host, they're prompted to use Windows Hello for Business to unlock the private key of the certificate.
:::row:::
:::column span="2":::
**Microsoft Entra joined device**
The user can authenticate using any available Windows Hello unlock gestures, including biometrics.
:::column-end:::
:::column span="2":::
**Microsoft Entra hybrid joined device**
The credential prompt identifies the Windows Hello credential provider as *Security device credential*. The user must use the PIN credential provider to unlock.
:::column-end:::
:::row-end:::
:::row:::
:::column span="2":::
:::image type="content" source="images/rdp/rdc-entra-joined.png" alt-text="Screenshot of Remote Desktop Connection authentication prompt using biometrics." border="false":::
:::column-end:::
:::column span="2":::
:::image type="content" source="images/rdp/rdc-entra-hybrid-joined.png" alt-text="Screenshot of Remote Desktop Connection authentication prompt using a PIN." border="false":::
:::column-end:::
:::row-end:::
Here's a brief video showing the user experience from a Microsoft Entra joined device using fingerprint as unlock factor:
> [!VIDEO https://learn-video.azurefd.net/vod/player?id=b6e1038d-98b5-48dc-8afb-65523d12cfaf]
> [!NOTE]
> The user must be authorized to connect to the remote server using the Remote Desktop protocol, for example by being a member of the Remote Desktop Users local group on the remote host.
## Compatibility
While users appreciate the convenience of biometrics, and administrators value the security, you might experience compatibility issues with applications and Windows Hello for Business certificates. In such scenarios, you can deploy a policy setting to revert to the previous behavior for the users needing it.
### Use Windows Hello for Business certificates as smart card certificates
If you enable this policy setting, applications use Windows Hello for Business certificates as smart card certificates. Biometric factors are unavailable when a user is asked to authorize the use of the certificate's private key. This policy setting is designed to allow compatibility with applications that rely exclusively on smart card certificates.
If you disable or don't configure this policy setting, applications don't use Windows Hello for Business certificates as smart card certificates. Biometric factors are available when a user is asked to authorize the use of the certificate's private key.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[UseHelloCertificatesAsSmartCardCertificates][WIN-1]|
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |
<!-- links -->
[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
[WIN-1]: /windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesusehellocertificatesassmartcardcertificates

4
windows/security/identity-protection/hello-for-business/toc.yml
View File

@ -96,8 +96,6 @@ items:
href: hello-cert-trust-policy-settings.md
- name: Planning for Domain Controller load
href: hello-adequate-domain-controllers.md
- name: Deploy certificates for remote desktop (RDP) sign-in
href: hello-deployment-rdp-certs.md
- name: How-to Guides
items:
- name: Prepare people to use Windows Hello
@ -119,7 +117,7 @@ items:
- name: Multi-factor Unlock
href: feature-multifactor-unlock.md
- name: Remote desktop (RDP) sign-in
href: hello-feature-remote-desktop.md
href: rdp-sign-in.md
- name: Troubleshooting
items:
- name: Known deployment issues

BIN
windows/security/identity-protection/images/remote-credential-guard.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.6 MiB

10
windows/security/identity-protection/remote-credential-guard.md
View File

@ -2,7 +2,7 @@
title: Remote Credential Guard
description: Learn how Remote Credential Guard helps to secure Remote Desktop credentials by never sending them to the target device.
ms.topic: how-to
ms.date: 12/04/2023
ms.date: 12/08/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
@ -145,8 +145,8 @@ The policy can have different values, depending on the level of security you wan
- **Require Remote Credential Guard**: Remote Desktop Client must use Remote Credential Guard to connect to remote hosts
- **Restrict credential delegation**: Remote Desktop Client must use Restricted Admin or Remote Credential Guard to connect to remote hosts. In this configuration, Remote Credential Guard is preferred, but it uses Restricted Admin mode (if supported) when Remote Credential Guard can't be used
> [!NOTE]
> When *Restrict Credential Delegation* is enabled, the `/restrictedAdmin` switch will be ignored. Windows enforces the policy configuration instead and uses Remote Credential Guard.
> [!NOTE]
> When *Restrict Credential Delegation* is enabled, the `/restrictedAdmin` switch will be ignored. Windows enforces the policy configuration instead and uses Remote Credential Guard.
To configure your clients, you can use:
@ -187,11 +187,11 @@ Not documented.
---
## Use Remote Credential Guard
## User experience
Once a client receives the policy, you can connect to the remote host using Remote Credential Guard by opening the Remote Desktop Client (`mstsc.exe`). The user is automatically authenticated to the remote host:
:::image type="content" source="images/remote-credential-guard.gif" alt-text="Animation showing a client connecting to a remote server using Remote Credential Guard with SSO.":::
>[!VIDEO https://learn-video.azurefd.net/vod/player?id=39cc96a2-5193-48be-a4f3-d491571fd9a1]
> [!NOTE]
> The user must be authorized to connect to the remote server using the Remote Desktop protocol, for example by being a member of the Remote Desktop Users local group on the remote host.