mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 11:53:37 +00:00
Freshness review
This commit is contained in:
@ -2,7 +2,7 @@
|
||||
title: Configure Windows Hello for Business
|
||||
description: Learn about the configuration options for Windows Hello for Business and how to implement them in your organization.
|
||||
ms.topic: how-to
|
||||
ms.date: 01/03/2024
|
||||
ms.date: 04/23/2024
|
||||
---
|
||||
|
||||
# Configure Windows Hello for Business
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Dynamic lock
|
||||
description: Learn how to configure dynamic lock on Windows devices via group policies. This feature locks a device when a Bluetooth signal falls below a set value.
|
||||
ms.date: 02/29/2024
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
|
File diff suppressed because it is too large
Load Diff
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Configure single sign-on (SSO) for Microsoft Entra joined devices
|
||||
description: Learn how to configure single sign-on to on-premises resources for Microsoft Entra joined devices, using Windows Hello for Business.
|
||||
ms.date: 12/30/2022
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
@ -9,7 +9,7 @@ ms.topic: how-to
|
||||
|
||||
[!INCLUDE [apply-to-hybrid-key-and-cert-trust](deploy/includes/apply-to-hybrid-key-and-cert-trust.md)]
|
||||
|
||||
Windows Hello for Business combined with Microsoft Entra joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Microsoft Entra joined devices may need to access these resources. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Microsoft Entra joined devices using Windows Hello for Business, using a key or a certificate.
|
||||
Windows Hello for Business combined with Microsoft Entra joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. As organizations transition resources to the cloud, some resources might remain on-premises, and Microsoft Entra joined devices might need to access them. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Microsoft Entra joined devices using Windows Hello for Business, using a key or a certificate.
|
||||
|
||||
> [!NOTE]
|
||||
> These steps are not needed when using the cloud Kerberos trust model.
|
||||
@ -25,12 +25,12 @@ Unlike Microsoft Entra hybrid joined devices, Microsoft Entra joined devices don
|
||||
|
||||
### CRL Distribution Point (CDP)
|
||||
|
||||
Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it writes information about the certificate into a *certificate revocation list* (CRL).\
|
||||
Certificates issued by a certificate authority can be revoked. When a certificate authority revokes a certificate, it writes information about the certificate into a *certificate revocation list* (CRL).\
|
||||
During certificate validation, Windows compares the current certificate with information in the CRL to determine if the certificate is valid.
|
||||
|
||||

|
||||
:::image type="content" source="images/aadj/Certificate-CDP.png" alt-text="Screenshot of a certificate's CDP property.":::
|
||||
|
||||
The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Microsoft Entra joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
|
||||
In the screenshot, the CDP property of the domain controller certificate shows an LDAP path. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Microsoft Entra joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
|
||||
|
||||
To resolve this issue, the CRL distribution point must be a location accessible by Microsoft Entra joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
|
||||
|
||||
@ -45,17 +45,18 @@ Certificate authorities write CDP information in certificates as they're issued.
|
||||
|
||||
#### Why does Windows need to validate the domain controller certificate?
|
||||
|
||||
Windows Hello for Business enforces the strict KDC validation security feature when authenticating from a Microsoft Entra joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on a Microsoft Entra joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met:
|
||||
Windows Hello for Business enforces the *strict KDC validation* security feature when authenticating from a Microsoft Entra joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on a Microsoft Entra joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met:
|
||||
|
||||
- The domain controller has the private key for the certificate provided
|
||||
- The root CA that issued the domain controller's certificate is in the device's *Trusted Root Certificate Authorities*
|
||||
- Use the *Kerberos Authentication certificate template* instead of any other older template
|
||||
- The domain controller's certificate has the *KDC Authentication* extended key usage (EKU)
|
||||
- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain
|
||||
- The domain controller's certificate's signature hash algorithm is **sha256**
|
||||
- The domain controller's certificate's public key is **RSA (2048 Bits)**
|
||||
- The domain controller's certificate's signature hash algorithm is *sha256*
|
||||
- The domain controller's certificate's public key is *RSA (2048 Bits)*
|
||||
|
||||
Authenticating from a Microsoft Entra hybrid joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Microsoft Entra joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU.
|
||||
> [!IMPORTANT]
|
||||
> Authenticating from a Microsoft Entra hybrid joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Microsoft Entra joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU.
|
||||
|
||||
## Configure a CRL distribution point for an issuing CA
|
||||
|
||||
@ -118,7 +119,7 @@ These procedures configure NTFS and share permissions on the web server to allow
|
||||
1. In the **Advanced Sharing** dialog box, select **OK**
|
||||
|
||||
> [!Tip]
|
||||
> Make sure that users can access **\\\Server FQDN\sharename**.
|
||||
> Make sure that users can access `\\Server FQDN\sharename`.
|
||||
|
||||
### Disable Caching
|
||||
1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server)
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: How Windows Hello for Business authentication works
|
||||
description: Learn about the Windows Hello for Business authentication flows.
|
||||
ms.date: 01/03/2024
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: reference
|
||||
---
|
||||
# Windows Hello for Business authentication
|
||||
@ -19,7 +19,7 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
|
||||
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.|
|
||||
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.|
|
||||
|B | The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID.|
|
||||
|C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. Microsoft Entra ID then validates the returned signed nonce, and creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
|
||||
|D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
|
||||
@ -58,7 +58,7 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
|
||||
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|
||||
|
||||
> [!NOTE]
|
||||
> You may have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
|
||||
> You may have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
|
||||
|
||||
## Microsoft Entra hybrid join authentication using cloud Kerberos trust
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: How Windows Hello for Business provisioning works
|
||||
description: Learn about the provisioning flows for Windows Hello for Business.
|
||||
ms.date: 01/03/2024
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: reference
|
||||
appliesto:
|
||||
---
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: How Windows Hello for Business works
|
||||
description: Learn how Windows Hello for Business works, and how it can help you protect your organization.
|
||||
ms.date: 01/09/2024
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: concept-article
|
||||
---
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: Windows Hello for Business overview
|
||||
description: Learn how Windows Hello for Business replaces passwords with strong two-factor authentication on Windows devices.
|
||||
ms.topic: overview
|
||||
ms.date: 01/03/2024
|
||||
ms.date: 04/23/2024
|
||||
---
|
||||
|
||||
# Windows Hello for Business
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Multi-factor unlock
|
||||
description: Learn how to configure Windows Hello for Business multi-factor unlock by extending Windows Hello with trusted signals.
|
||||
ms.date: 01/03/2024
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: PIN reset
|
||||
description: Learn how Microsoft PIN reset service enables your users to recover a forgotten Windows Hello for Business PIN, and how to configure it.
|
||||
ms.date: 01/03/2024
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: Windows Hello for Business policy settings
|
||||
description: Learn about the policy settings to configure Configure Windows Hello for Business.
|
||||
ms.topic: reference
|
||||
ms.date: 01/03/2024
|
||||
ms.date: 04/23/2024
|
||||
---
|
||||
|
||||
# Windows Hello for Business policy settings
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
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.date: 04/23/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: WebAuthn APIs
|
||||
description: Learn how to use WebAuthn APIs to enable passwordless authentication for your sites and apps.
|
||||
ms.date: 07/27/2023
|
||||
ms.date: 04/23/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
# WebAuthn APIs for passwordless authentication on Windows
|
||||
@ -20,7 +20,7 @@ Users of these apps or sites can use any browser that supports WebAuthn APIs for
|
||||
|
||||
Developers should use the WebAuthn APIs to support FIDO2 authentication keys in a consistent way for users. Additionally, developers can use all the transports that are available per FIDO2 specifications (USB, NFC, and BLE) while avoiding the interaction and management overhead.
|
||||
|
||||
> [!NOTE]
|
||||
> [!NOTE]
|
||||
> When these APIs are in use, Windows 10 browsers or applications don't have direct access to the FIDO2 transports for FIDO-related messaging.
|
||||
|
||||
## The big picture
|
||||
@ -29,7 +29,7 @@ The Client to Authenticator Protocol 2 (CTAP2) and WebAuthn define an abstractio
|
||||
|
||||
The authentication process starts when the user makes a specific user gesture that indicates consent for the operation. At the request of the client, the authenticator securely creates strong cryptographic keys and stores them locally.
|
||||
|
||||
After these client-specific keys are created, clients can request attestations for registration and authentication. The type of signature that the private key uses reflects the user gesture that was made.
|
||||
After these client-specific keys are created, clients can request attestations for registration and authentication. The type of signature that the private key uses reflects the user gesture that was made.
|
||||
|
||||
The following diagram shows how CTAP and WebAuthn interact. The light blue dotted arrows represent interactions that depend on the specific implementation of the platform APIs.
|
||||
|
||||
@ -39,15 +39,15 @@ The following diagram shows how CTAP and WebAuthn interact. The light blue dotte
|
||||
|
||||
A combined WebAuthn/CTAP2 dance includes the following cast of characters:
|
||||
|
||||
- **Client device**. The *client device* is the hardware that hosts a given strong authentication. Laptops and phones are examples of client devices.
|
||||
- **Client device**. The *client device* is the hardware that hosts a given strong authentication. Laptops and phones are examples of client devices.
|
||||
|
||||
- **Relying parties and clients**. *Relying parties* are web or native applications that consume strong credentials. The relying parties run on client devices.
|
||||
- **Relying parties and clients**. *Relying parties* are web or native applications that consume strong credentials. The relying parties run on client devices.
|
||||
|
||||
- As a relying party, a native application can also act as a WebAuthn client to make direct WebAuthn calls.
|
||||
|
||||
- As a relying party, a web application can't directly interact with the WebAuthn API. The relying party must broker the deal through the browser.
|
||||
|
||||
> [!NOTE]
|
||||
|
||||
- As a relying party, a web application can't directly interact with the WebAuthn API. The relying party must broker the deal through the browser.
|
||||
|
||||
> [!NOTE]
|
||||
> The preceding diagram doesn't depict Single Sign-On (SSO) authentication. Be careful not to confuse FIDO relying parties with federated relying parties.
|
||||
|
||||
- **WebAuthn API**. The *WebAuthn API* enables clients to make requests to authenticators. The client can request the authenticator to create a key, provide an assertion about a key, report capabilities, manage a PIN, and so on.
|
||||
@ -82,7 +82,7 @@ The following options might be useful in the future, but haven't been observed i
|
||||
|
||||
The Microsoft FIDO2 implementation has been years in the making. Software and services are implemented independently as standards-compliant entities. As of the Windows 10, version 1809 (October 2018) release, all Microsoft components use the latest WebAuthn Candidate Release. It's a stable release that's not expected to normatively change before the specification is finally ratified. Because Microsoft is among the first in the world to deploy FIDO2, some combinations of popular non-Microsoft components won't be interoperable yet.
|
||||
|
||||
Here's an approximate layout of where the Microsoft bits go:
|
||||
Here's an approximate layout of where the Microsoft bits go:
|
||||
|
||||
:::image type="content" source="images/webauthn-apis/webauthn-apis-fido2-overview-microsoft-version.png" alt-text="The diagram shows how the WebAuthn API interacts with the Microsoft relying parties and the CTAPI2 API.":::
|
||||
|
||||
@ -94,12 +94,12 @@ Here's an approximate layout of where the Microsoft bits go:
|
||||
- Offline scenarios work (enabled by using HMAC)
|
||||
- Users can put keys for multiple user accounts on the same authenticator
|
||||
- If it's necessary, authenticators can use a client PIN to unlock a TPM
|
||||
> [!IMPORTANT]
|
||||
> [!IMPORTANT]
|
||||
> Because Microsoft Account requires features and extensions that are unique to FIDO2 CTAP2 authenticators, it doesn't accept CTAP1 (U2F) credentials.
|
||||
|
||||
- **WebAuthn client: Microsoft Edge**. Microsoft Edge can handle the user interface for the WebAuthn and CTAP2 features that this article describes. It also supports the AppID extension. Microsoft Edge can interact with both CTAP1 and CTAP2 authenticators. This scope for interaction means that it can create and use both U2F and FIDO2 credentials. However, Microsoft Edge doesn't speak the U2F protocol. Therefore, relying parties must use only the WebAuthn specification. Microsoft Edge on Android doesn't support WebAuthn.
|
||||
|
||||
> [!NOTE]
|
||||
> [!NOTE]
|
||||
> For authoritative information about Microsoft Edge support for WebAuthn and CTAP, see [Legacy Microsoft Edge developer documentation](/microsoft-edge/dev-guide/windows-integration/web-authentication).
|
||||
|
||||
- **Platform: Windows 10, Windows 11**. Windows 10 and Windows 11 host the Win32 Platform WebAuthn APIs.
|
||||
|
Reference in New Issue
Block a user