mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
Merge branch 'main' into vp-csp-auto2
This commit is contained in:
commit
ecee0331f2
@ -1,7 +1,7 @@
|
|||||||
### YamlMime:FAQ
|
### YamlMime:FAQ
|
||||||
metadata:
|
metadata:
|
||||||
title: Windows Hello for Business Frequently Asked Questions (FAQ)
|
title: Windows Hello for Business Frequently Asked Questions (FAQ)
|
||||||
description: Use these frequently asked questions (FAQ) to learn important details about Windows Hello for Business.
|
description: Use these frequently asked questions (FAQ) to learn important details about Windows Hello for Business.
|
||||||
keywords: identity, PIN, biometric, Hello, passport
|
keywords: identity, PIN, biometric, Hello, passport
|
||||||
ms.prod: windows-client
|
ms.prod: windows-client
|
||||||
ms.technology: itpro-security
|
ms.technology: itpro-security
|
||||||
@ -29,16 +29,16 @@ sections:
|
|||||||
|
|
||||||
- question: What is Windows Hello for Business cloud Kerberos trust?
|
- question: What is Windows Hello for Business cloud Kerberos trust?
|
||||||
answer: |
|
answer: |
|
||||||
Windows Hello for Business cloud Kerberos trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid cloud Kerberos trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
|
Windows Hello for Business *cloud Kerberos trust* is a **trust model** that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
|
||||||
|
|
||||||
|
|
||||||
- question: What about virtual smart cards?
|
- question: What about virtual smart cards?
|
||||||
answer: |
|
answer: |
|
||||||
Windows Hello for Business is the modern, two-factor credential for Windows 10. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using Windows 10 and virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows 10 deployments use Windows Hello for Business. Virtual smart cards remain supported for Windows 7 and Windows 8.
|
Windows Hello for Business is the modern, two-factor credential for Windows. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows deployments use Windows Hello for Business.
|
||||||
|
|
||||||
- question: What about convenience PIN?
|
- question: What about convenience PIN?
|
||||||
answer: |
|
answer: |
|
||||||
Microsoft is committed to its vision of a <u>world without passwords.</u> We recognize the *convenience* provided by convenience PIN, but it stills uses a password for authentication. Microsoft recommends that customers using Windows 10 and convenience PINs should move to Windows Hello for Business. New Windows 10 deployments should deploy Windows Hello for Business and not convenience PINs. Microsoft will be deprecating convenience PINs in the future and will publish the date early to ensure customers have adequate lead time to deploy Windows Hello for Business.
|
While *convenience PIN* provides a convenient way to sign in to Windows, it stills uses a password for authentication. Customers using *convenience PINs* should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs. Microsoft will be deprecating convenience PINs in the future and will publish the date early to ensure customers have adequate lead time to deploy Windows Hello for Business.
|
||||||
|
|
||||||
- question: Can I use Windows Hello for Business key trust and RDP?
|
- question: Can I use Windows Hello for Business key trust and RDP?
|
||||||
answer: |
|
answer: |
|
||||||
@ -63,7 +63,7 @@ sections:
|
|||||||
|
|
||||||
- question: How can a PIN be more secure than a password?
|
- question: How can a PIN be more secure than a password?
|
||||||
answer: |
|
answer: |
|
||||||
When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
|
When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
|
||||||
The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
|
The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
|
||||||
|
|
||||||
- question: What's a container?
|
- question: What's a container?
|
||||||
@ -169,7 +169,7 @@ sections:
|
|||||||
|
|
||||||
- question: Where is Windows Hello biometrics data stored?
|
- question: Where is Windows Hello biometrics data stored?
|
||||||
answer: |
|
answer: |
|
||||||
When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
|
When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
|
||||||
|
|
||||||
- question: What is the format used to store Windows Hello biometrics data on the device?
|
- question: What is the format used to store Windows Hello biometrics data on the device?
|
||||||
answer: |
|
answer: |
|
||||||
@ -233,9 +233,9 @@ sections:
|
|||||||
|
|
||||||
- question: How does PIN caching work with Windows Hello for Business?
|
- question: How does PIN caching work with Windows Hello for Business?
|
||||||
answer: |
|
answer: |
|
||||||
Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
|
Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
|
||||||
|
|
||||||
Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.
|
Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.
|
||||||
|
|
||||||
The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. Windows 10 doesn't provide any Group Policy settings to adjust this caching.
|
The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. Windows 10 doesn't provide any Group Policy settings to adjust this caching.
|
||||||
|
|
||||||
|
@ -45,9 +45,9 @@ Windows stores biometric data that is used to implement Windows Hello securely o
|
|||||||
|
|
||||||
## The difference between Windows Hello and Windows Hello for Business
|
## The difference between Windows Hello and Windows Hello for Business
|
||||||
|
|
||||||
- Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it's set up, but can use a password hash depending on an individual's account type. This configuration is referred to as Windows Hello convenience PIN and it's not backed by asymmetric (public/private key) or certificate-based authentication.
|
- Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it's set up, but can use a password hash depending on an individual's account type. This configuration is referred to as *Windows Hello convenience PIN* and it's not backed by asymmetric (public/private key) or certificate-based authentication.
|
||||||
|
|
||||||
- **Windows Hello for Business**, which is configured by group policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This behavior makes it more secure than **Windows Hello convenience PIN**.
|
- *Windows Hello for Business*, which is configured by group policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This behavior makes it more secure than *Windows Hello convenience PIN*.
|
||||||
|
|
||||||
## Benefits of Windows Hello
|
## Benefits of Windows Hello
|
||||||
|
|
||||||
|
@ -1,9 +1,9 @@
|
|||||||
---
|
---
|
||||||
title: How to use Single Sign-On (SSO) over VPN and Wi-Fi connections (Windows 10 and Windows 11)
|
title: How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
|
||||||
description: Explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections.
|
description: Explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections.
|
||||||
ms.prod: windows-client
|
ms.prod: windows-client
|
||||||
author: paolomatarazzo
|
author: paolomatarazzo
|
||||||
ms.date: 03/22/2022
|
ms.date: 12/28/2022
|
||||||
manager: aaroncz
|
manager: aaroncz
|
||||||
ms.author: paoloma
|
ms.author: paoloma
|
||||||
ms.reviewer: pesmith
|
ms.reviewer: pesmith
|
||||||
@ -18,47 +18,49 @@ ms.topic: how-to
|
|||||||
|
|
||||||
This article explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections. The following scenarios are typically used:
|
This article explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections. The following scenarios are typically used:
|
||||||
|
|
||||||
- Connecting to a network using Wi-Fi or VPN.
|
- Connecting to a network using Wi-Fi or VPN
|
||||||
- Use credentials for WiFi or VPN authentication to also authenticate requests to access a domain resource without being prompted for your domain credentials.
|
- Use credentials for Wi-Fi or VPN authentication to also authenticate requests to access domain resources, without being prompted for domain credentials
|
||||||
|
|
||||||
For example, you want to connect to a corporate network and access an internal website that requires Windows integrated authentication.
|
For example, you want to connect to a corporate network and access an internal website that requires Windows integrated authentication.
|
||||||
|
|
||||||
The credentials that are used for the connection authentication are placed in Credential Manager as the default credentials for the logon session. Credential Manager stores credentials that can be used for specific domain resources. These are based on the target name of the resource:
|
The credentials that are used for the connection authentication are placed in *Credential Manager* as the default credentials for the **logon session**. Credential Manager stores credentials that can be used for specific domain resources. These are based on the target name of the resource:
|
||||||
- For VPN, the VPN stack saves its credential as the session default.
|
|
||||||
- For WiFi, Extensible Authentication Protocol (EAP) provides support.
|
|
||||||
|
|
||||||
The credentials are placed in Credential Manager as a "\*Session" credential.
|
- For VPN, the VPN stack saves its credential as the **session default**
|
||||||
A "\*Session" credential implies that it is valid for the current user session.
|
- For WiFi, Extensible Authentication Protocol (EAP) provides support
|
||||||
The credentials are also cleaned up when the WiFi or VPN connection is disconnected.
|
|
||||||
|
The credentials are placed in Credential Manager as a *session credential*:
|
||||||
|
|
||||||
|
- A *session credential* implies that it is valid for the current user session
|
||||||
|
- The credentials are cleaned up when the WiFi or VPN connection is disconnected
|
||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
> In Windows 10, version 21h2 and later, the "\*Session" credential is not visible in Credential Manager.
|
> In Windows 10, version 21H2 and later, the *session credential* is not visible in Credential Manager.
|
||||||
|
|
||||||
For example, if someone using Microsoft Edge tries to access a domain resource, Microsoft Edge has the right Enterprise Authentication capability. This allows [WinInet](/windows/win32/wininet/wininet-reference) to release the credentials that it gets from the Credential Manager to the SSP that is requesting it.
|
For example, if someone using Microsoft Edge tries to access a domain resource, Microsoft Edge has the right Enterprise Authentication capability. This allows [WinInet](/windows/win32/wininet/wininet-reference) to release the credentials that it gets from Credential Manager to the SSP that is requesting it.
|
||||||
For more information about the Enterprise Authentication capability, see [App capability declarations](/windows/uwp/packaging/app-capability-declarations).
|
For more information about the Enterprise Authentication capability, see [App capability declarations](/windows/uwp/packaging/app-capability-declarations).
|
||||||
|
|
||||||
The local security authority will look at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application.
|
The local security authority will look at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application.
|
||||||
If the app isn't a UWP, it doesn't matter.
|
If the app isn't a UWP, it doesn't matter.
|
||||||
But if the application is a UWP app, it will evaluate at the device capability for Enterprise Authentication.
|
But, if the application is a UWP app, it will evaluate at the device capability for Enterprise Authentication.
|
||||||
If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential will be released.
|
If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential will be released.
|
||||||
This behavior helps prevent credentials from being misused by untrusted third parties.
|
This behavior helps prevent credentials from being misused by untrusted third parties.
|
||||||
|
|
||||||
## Intranet zone
|
## Intranet zone
|
||||||
|
|
||||||
For the Intranet zone, by default it only allows single-label names, such as Http://finance.
|
For the Intranet zone, by default it only allows single-label names, such as *http://finance*.
|
||||||
If the resource that needs to be accessed has multiple domain labels, then the workaround is to use the [Registry CSP](/windows/client-management/mdm/registry-csp).
|
If the resource that needs to be accessed has multiple domain labels, then the workaround is to use the [Registry CSP](/windows/client-management/mdm/registry-csp).
|
||||||
|
|
||||||
### Setting the ZoneMap
|
### Setting the ZoneMap
|
||||||
|
|
||||||
The ZoneMap is controlled using a registry that can be set through MDM.
|
The ZoneMap is controlled using a registry that can be set through MDM.
|
||||||
By default, single-label names such as http://finance are already in the intranet zone.
|
By default, single-label names such as *http://finance* are already in the intranet zone.
|
||||||
For multi-label names, such as http://finance.net, the ZoneMap needs to be updated.
|
For multi-label names, such as *http://finance.net*, the ZoneMap needs to be updated.
|
||||||
|
|
||||||
## MDM Policy
|
## MDM Policy
|
||||||
|
|
||||||
OMA URI example:
|
OMA URI example:
|
||||||
|
|
||||||
./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-2781/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/`<domain name>`/* as an Integer Value of 1 for each of the domains that you want to SSO into from your device. This adds the specified domains to the Intranet Zone of the Microsoft Edge browser.
|
`./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-2781/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/<domain name>` as an `Integer` value of `1` for each of the domains that you want to SSO into from your device. This adds the specified domains to the Intranet Zone of the Microsoft Edge browser.
|
||||||
|
|
||||||
## Credential requirements
|
## Credential requirements
|
||||||
|
|
||||||
@ -66,10 +68,10 @@ For VPN, the following types of credentials will be added to credential manager
|
|||||||
|
|
||||||
- Username and password
|
- Username and password
|
||||||
- Certificate-based authentication:
|
- Certificate-based authentication:
|
||||||
- TPM Key Storage Provider (KSP) Certificate
|
- TPM Key Storage Provider (KSP) Certificate
|
||||||
- Software Key Storage Provider (KSP) Certificates
|
- Software Key Storage Provider (KSP) Certificates
|
||||||
- Smart Card Certificate
|
- Smart Card Certificate
|
||||||
- Windows Hello for Business Certificate
|
- Windows Hello for Business Certificate
|
||||||
|
|
||||||
The username should also include a domain that can be reached over the connection (VPN or WiFi).
|
The username should also include a domain that can be reached over the connection (VPN or WiFi).
|
||||||
|
|
||||||
@ -79,10 +81,10 @@ If the credentials are certificate-based, then the elements in the following tab
|
|||||||
|
|
||||||
| Template element | Configuration |
|
| Template element | Configuration |
|
||||||
|------------------|---------------|
|
|------------------|---------------|
|
||||||
| SubjectName | The user’s distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
|
| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
|
||||||
| SubjectAlternativeName | The user’s fully qualified UPN where a domain name component of the user’s UPN matches the organizations internal domain’s DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
|
| SubjectAlternativeName | The user's fully qualified UPN where a domain name component of the user's UPN matches the organizations internal domain's DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
|
||||||
| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
|
| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
|
||||||
| EnhancedKeyUsage | One or more of the following EKUs is required: </br>- Client Authentication (for the VPN) </br>- EAP Filtering OID (for Windows Hello for Business)</br>- SmartCardLogon (for Azure AD-joined devices) </br>If the domain controllers require smart card EKU either:</br>- SmartCardLogon</br>- id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) <br>Otherwise:</br>- TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2) |
|
| EnhancedKeyUsage | One or more of the following EKUs is required: </br><ul><li>Client Authentication (for the VPN)</li><li>EAP Filtering OID (for Windows Hello for Business)</li><li>SmartCardLogon (for Azure AD-joined devices)</li></ul>If the domain controllers require smart card EKU either:<ul><li>SmartCardLogon</li><li>id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) </li></ul>Otherwise:</br><ul><li>TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)</li></ul> |
|
||||||
|
|
||||||
## NDES server configuration
|
## NDES server configuration
|
||||||
|
|
||||||
|
@ -286,9 +286,12 @@ One of the things we’ve heard from you is that it’s hard to know when you’
|
|||||||
|
|
||||||
## Remote Desktop with Biometrics
|
## Remote Desktop with Biometrics
|
||||||
|
|
||||||
Azure Active Directory and Active Directory users using Windows Hello for Business can use biometrics to authenticate to a remote desktop session.
|
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.
|
||||||
|
Users using earlier versions of Windows 10 could authenticate to a remote desktop using Windows Hello for Business but were limited to using their PIN as their authentication gesture. Windows 10, version 1809 introduces the ability for users to authenticate to a remote desktop session using their Windows Hello for Business biometric gesture.
|
||||||
|
|
||||||
To get started, sign into your device using Windows Hello for Business. Bring up **Remote Desktop Connection** (mstsc.exe), type the name of the computer you want to connect to, and click **Connect**. Windows remembers that you signed using Windows Hello for Business, and automatically selects Windows Hello for Business to authenticate you to your RDP session. You can also click **More choices** to choose alternate credentials. Windows uses facial recognition to authenticate the RDP session to the Windows Server 2016 Hyper-V server. You can continue to use Windows Hello for Business in the remote session, but you must use your PIN.
|
Azure Active Directory and Active Directory users using Windows Hello for Business in a certificate trust model, can use biometrics to authenticate to a remote desktop session.
|
||||||
|
|
||||||
|
To get started, sign into your device using Windows Hello for Business. Bring up **Remote Desktop Connection** (mstsc.exe), type the name of the device you want to connect to, and select **Connect**. Windows remembers that you signed using Windows Hello for Business, and automatically selects Windows Hello for Business to authenticate you to your RDP session. You can also select **More choices** to choose alternate credentials. Windows uses biometrics to authenticate the RDP session to the Windows device. You can continue to use Windows Hello for Business in the remote session, but in the remote session you must use the PIN.
|
||||||
|
|
||||||
See the following example:
|
See the following example:
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user