Update Windows Hello for Business documentation

This commit is contained in:
Paolo Matarazzo 2023-12-12 08:29:52 -05:00
parent ef57c365a4
commit c1d435b3e3
5 changed files with 36 additions and 32 deletions

View File

@ -8054,6 +8054,11 @@
"source_path": "windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/pin-reset",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md",
"redirect_url": "/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services",
"redirect_document_id": false
}
]
}

View File

@ -43,7 +43,7 @@ The trust model determines how you want users to authenticate to the on-premises
- The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today.
- The certificate trust model also supports enterprises, which aren't ready to deploy Windows Server 2016 Domain Controllers.
> [!Note]
> [!NOTE]
> RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
Following are the various deployment guides and models included in this topic:

View File

@ -16,11 +16,11 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
List of provisioning flows:
- [Microsoft Entra joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
- [Microsoft Entra joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
- [Microsoft Entra joined provisioning in a managed environment](#microsoft-entra-joined-provisioning-in-a-managed-environment)
- [Microsoft Entra joined provisioning in a federated environment](#microsoft-entra-joined-provisioning-in-a-federated-environment)
- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#microsoft-entra-hybrid-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
- [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
- [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment)
@ -108,6 +108,7 @@ List of provisioning flows:
|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
## Domain joined provisioning in an On-premises Certificate Trust deployment
![Domain joined provisioning in an On-premises Certificate Trust deployment.](images/howitworks/prov-onprem-certtrust.png)
[Full size image](images/howitworks/prov-onprem-certtrust.png)

View File

@ -167,10 +167,11 @@ If your organization doesn't have on-premises resources, write **Cloud Only** in
If your organization is federated with Azure or uses any service, such as AD Connect, Office365 or OneDrive, or your users access cloud and on-premises resources, write **Hybrid** in box **1a** on your planning worksheet.
If your organization doesn't have cloud resources, write **On-Premises** in box **1a** on your planning worksheet.
> [!NOTE]
> * Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests".
> * Migration from on-premise to hybrid deployment will require redeployment.
>[!NOTE]
>
>- Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests"
>- Migration from on-premise to hybrid deployment will require redeployment
### Trust type

View File

@ -1,13 +1,13 @@
---
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.date: 08/03/2023
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.date: 12/12/2023
ms.topic: how-to
---
# How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
# How to use single sign-on (SSO) over VPN and Wi-Fi connections
This article explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over Wi-Fi 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 Wi-Fi or VPN connections. The following scenarios are typically used:
- 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
@ -21,7 +21,7 @@ The credentials that are used for the connection authentication are placed in *C
The credentials are placed in Credential Manager as a *session credential*:
- A *session credential* implies that it is valid for the current user session
- A *session credential* implies that it's valid for the current user session
- The credentials are cleaned up when the Wi-Fi or VPN connection is disconnected
> [!NOTE]
@ -30,22 +30,22 @@ The credentials are placed in Credential Manager as a *session credential*:
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.
The local security authority looks 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.
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.
But, if the application is a UWP app, it evaluates 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 is 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
@ -72,8 +72,8 @@ 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 doesn't 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 doesn't have the DN required to find the domain controller. |
| Key Storage Provider (KSP) | If the device is joined to Microsoft Entra ID, a discrete SSO certificate is used. |
| 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 Microsoft Entra 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> |
@ -86,9 +86,6 @@ For more information, see [Configure certificate infrastructure for SCEP](/mem/i
You need IP connectivity to a DNS server and domain controller over the network interface so that authentication can succeed as well.
Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones are not domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store.
Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones aren't domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store.
Domain controllers must be using certificates based on the updated KDC certificate template Kerberos Authentication.
This requires that all authenticating domain controllers run Windows Server 2016, or you'll need to enable strict KDC validation on domain controllers that run previous versions of Windows Server.
For more information, see [Enabling Strict KDC Validation in Windows Kerberos](https://www.microsoft.com/download/details.aspx?id=6382).
Domain controllers must be using certificates based on the updated *KDC certificate template* Kerberos Authentication.