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 #7698 from MicrosoftDocs/main

Browse Source 
Publish main to live on 12/28 @ 10:30 am
This commit is contained in:
Stephanie Savell 2022-12-28 12:35:05 -06:00 committed by GitHub
commit ca4efde063
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 41 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -29,16 +29,16 @@ sections:
- question: What is Windows Hello for Business cloud Kerberos trust?
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?
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?
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?
answer: |

4
windows/security/identity-protection/hello-for-business/hello-overview.md
View File

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

42
windows/security/identity-protection/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
View File

@ -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.
ms.prod: windows-client
author: paolomatarazzo
ms.date: 03/22/2022
ms.date: 12/28/2022
manager: aaroncz
ms.author: paoloma
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:
- 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.
- Connecting to a network using Wi-Fi or VPN
- 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.
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 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 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 also cleaned up when the WiFi or VPN connection is disconnected.
- 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*:
- 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]
> 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).
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.
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.
This behavior helps prevent credentials from being misused by untrusted third parties.
## 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).
### Setting the ZoneMap
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.
For multi-label names, such as http://finance.net, the ZoneMap needs to be updated.
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.
## MDM Policy
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
@ -79,10 +81,10 @@ If the credentials are certificate-based, then the elements in the following tab
| 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. |
| 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. |
| 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. |
| 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

7
windows/whats-new/whats-new-windows-10-version-1809.md
View File

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