deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-23 22:33:41 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'MicrosoftDocs:main' into zwhitt-microsoft-cg-patch1

Browse Source
This commit is contained in:
zwhitt-microsoft
2024-05-06 11:10:07 -07:00
committed by GitHub
parent 2428e36151 aa149e9785
commit f24cfd0fd3
471 changed files with 8141 additions and 5391 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/security/identity-protection/hello-for-business/configure.md
View File

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

72
windows/security/identity-protection/hello-for-business/dual-enrollment.md Normal file
View File

@ -0,0 +1,72 @@
---
title: Dual enrollment
description: Learn how to configure Windows Hello for Business dual enrollment and how to configure Active Directory to support Domain Administrator enrollment.
ms.date: 05/06/2024
ms.topic: how-to
---
# Dual enrollment
[!INCLUDE [intro](deploy/includes/intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-onpremises](deploy/includes/tooltip-deployment-onpremises.md)], [!INCLUDE [tooltip-deployment-hybrid](deploy/includes/tooltip-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [tooltip-cert-trust](deploy/includes/tooltip-trust-cert.md)]
- **Join type:** [!INCLUDE [tooltip-join-domain](deploy/includes/tooltip-join-domain.md)], [!INCLUDE [tooltip-join-hybrid](deploy/includes/tooltip-join-hybrid.md)]
---
> [!IMPORTANT]
> Dual enrollment does not replace or provide the same security as Privileged Access Workstations feature. Microsoft encourages organizations to use the Privileged Access Workstations for their privileged credential users. Organizations can consider Windows Hello for Business dual enrollment in situations where the Privileged Access feature can't be used. To learn more, see [Privileged Access Workstations](/windows-server/identity/securing-privileged-access/privileged-access-workstations).
Dual enrollment enables administrators to perform elevated, administrative functions by enrolling both their nonprivileged and privileged credentials on their device.
By design, Windows doesn't enumerate all Windows Hello for Business users from within a user's session. Using the group policy setting, **Allow enumeration of emulated smart card for all users**, you can configure a device to enumerate all enrolled Windows Hello for Business credentials on selected devices.
With this setting, administrative users can sign in to Windows using their nonprivileged Windows Hello credentials for normal work flow such as email, but can launch Microsoft Management Consoles (MMCs), Remote Desktop Services clients, and other applications by selecting **Run as different user** or **Run as administrator**, selecting the privileged user account, and providing their PIN. Administrators can also take advantage of this feature with command-line applications by using `runas.exe` combined with the `/smartcard` argument. This enables administrators to perform their day-to-day operations without needing to sign in and out, or use fast user switching when alternating between privileged and nonprivileged workloads.
> [!IMPORTANT]
> You must configure a Windows computer for Windows Hello for Business dual enrollment before either user (privileged or non-privileged) provisions Windows Hello for Business. Dual enrollment is a special setting that is configured on the Windows Hello container during creation.
## Configure Windows Hello for Business dual enrollment
Here are the steps to enable dual enrollment:
- Configure Active Directory to support Domain Administrator enrollment
- Configure dual enrollment using Group Policy
### Configure Active Directory to support Domain Administrator enrollment
The designed Windows Hello for Business configuration gives the `Key Admins` group read and write permissions to the `msDS-KeyCredentialsLink` attribute. You provided these permissions at root of the domain and use object inheritance to ensure the permissions apply to all users in the domain regardless of their location within the domain hierarchy.
Active Directory Domain Services uses `AdminSDHolder` to secure privileged users and groups from unintentional modification by comparing and replacing the security on privileged users and groups to match those defined on the AdminSDHolder object on an hourly cycle. For Windows Hello for Business, your domain administrator account might receive the permissions but they disappear from the user object unless you give the `AdminSDHolder` read and write permissions to the `msDS-KeyCredential` attribute.
Sign in to a domain controller or management workstation with access equivalent to *domain administrator*.
1. Type the following command to add the **allow** read and write property permissions for msDS-KeyCredentialLink attribute for the `Key Admins` group on the `AdminSDHolder` object
```cmd
dsacls "CN=AdminSDHolder,CN=System,DC=domain,DC=com" /g "[domainName\keyAdminGroup]":RPWP;msDS-KeyCredentialLink
```
where `DC=domain,DC=com` is the LDAP path of your Active Directory domain and `domainName\keyAdminGroup` is the NetBIOS name of your domain and the name of the group you use to give access to keys based on your deployment. For example:
```cmd
dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=mstepdemo,DC=net" /g "mstepdemo\Key Admins":RPWP;msDS-KeyCredentialLink
```
1. To trigger security descriptor propagation, open `ldp.exe`
1. Select **Connection** and select **Connect...** Next to **Server**, type the name of the domain controller that holds the PDC role for the domain. Next to **Port**, type **389** and select **OK**
1. Select **Connection** and select **Bind...** Select **OK** to bind as the currently signed-in user
1. Select **Browser** and select **Modify**. Leave the **DN** text box blank. Next to **Attribute**, type **RunProtectAdminGroupsTask**. Next to **Values**, type `1`. Select **Enter** to add this to the **Entry List**
1. Select **Run** to start the task
1. Close LDP
### Configure dual enrollment with group policy
You configure Windows to support dual enrollment using the computer configuration portion of a Group Policy object:
1. Using the Group Policy Management Console (GPMC), create a new domain-based Group Policy object and link it to an organizational Unit that contains Active Directory computer objects used by privileged users
1. Edit the Group Policy object from step 1
1. Enable the **Allow enumeration of emulated smart cards for all users** policy setting located under **Computer Configuration->Administrative Templates->Windows Components->Windows Hello for Business**
1. Close the Group Policy Management Editor to save the Group Policy object. Close the GPMC
1. Restart computers targeted by this Group Policy object
The computer is ready for dual enrollment. Sign in as the privileged user first and enroll for Windows Hello for Business. Once completed, sign out and sign in as the nonprivileged user and enroll for Windows Hello for Business. You can now use your privileged credential to perform privileged tasks without using your password and without needing to switch users.

64
windows/security/identity-protection/hello-for-business/hello-feature-dual-enrollment.md
View File

@ -1,64 +0,0 @@
---
title: Dual Enrollment
description: Learn how to configure Windows Hello for Business dual enrollment and how to configure Active Directory to support Domain Administrator enrollment.
ms.date: 07/05/2023
ms.topic: how-to
---
# Dual Enrollment
**Requirements**
- Hybrid and On-premises Windows Hello for Business deployments
- Enterprise joined or Hybrid Azure joined devices
- Certificate trust
> [!IMPORTANT]
> Dual enrollment does not replace or provide the same security as Privileged Access Workstations feature. Microsoft encourages enterprises to use the Privileged Access Workstations for their privileged credential users. Enterprises can consider Windows Hello for Business dual enrollment in situations where the Privileged Access feature cannot be used. Read [Privileged Access Workstations](/windows-server/identity/securing-privileged-access/privileged-access-workstations) for more information.
Dual enrollment enables administrators to perform elevated, administrative functions by enrolling both their non-privileged and privileged credentials on their device.
By design, Windows does not enumerate all Windows Hello for Business users from within a user's session. Using the computer Group Policy setting, **Allow enumeration of emulated smart card for all users**, you can configure a device to enumerate all enrolled Windows Hello for Business credentials on selected devices.
With this setting, administrative users can sign in to Windows 10, version 1709 or later using their non-privileged Windows Hello for Business credentials for normal work flow such as email, but can launch Microsoft Management Consoles (MMCs), Remote Desktop Services clients, and other applications by selecting **Run as different user** or **Run as administrator**, selecting the privileged user account, and providing their PIN. Administrators can also take advantage of this feature with command-line applications by using **runas.exe** combined with the **/smartcard** argument. This enables administrators to perform their day-to-day operations without needing to sign in and out, or use fast user switching when alternating between privileged and non-privileged workloads.
> [!IMPORTANT]
> You must configure a Windows computer for Windows Hello for Business dual enrollment before either user (privileged or non-privileged) provisions Windows Hello for Business. Dual enrollment is a special setting that is configured on the Windows Hello container during creation.
## Configure Windows Hello for Business Dual Enrollment
In this task, you will
* Configure Active Directory to support Domain Administrator enrollment
* Configure Dual Enrollment using Group Policy
### Configure Active Directory to support Domain Administrator enrollment
The designed Windows Hello for Business configuration gives the **Key Admins** (or **KeyCredential Admins** when using domain controllers prior to Windows Server 2016) group read and write permissions to the msDS-KeyCredentialsLink attribute. You provided these permissions at root of the domain and use object inheritance to ensure the permissions apply to all users in the domain regardless of their location within the domain hierarchy.
Active Directory Domain Services uses AdminSDHolder to secure privileged users and groups from unintentional modification by comparing and replacing the security on privileged users and groups to match those defined on the AdminSDHolder object on an hourly cycle. For Windows Hello for Business, your domain administrator account may receive the permissions but they will disappear from the user object unless you give the AdminSDHolder read and write permissions to the msDS-KeyCredential attribute.
Sign in to a domain controller or management workstation with access equivalent to _domain administrator_.
1. Type the following command to add the **allow** read and write property permissions for msDS-KeyCredentialLink attribute for the **Key Admins** (or **KeyCredential Admins**) group on the AdminSDHolder object.</br>
```dsacls "CN=AdminSDHolder,CN=System,DC=domain,DC=com" /g "[domainName\keyAdminGroup]":RPWP;msDS-KeyCredentialLink```</br>
where **DC=domain,DC=com** is the LDAP path of your Active Directory domain and **domainName\keyAdminGroup]** is the NetBIOS name of your domain and the name of the group you use to give access to keys based on your deployment. For example:</br>
```dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=mstepdemo,DC=net" /g "mstepdemo\Key Admins":RPWP;msDS-KeyCredentialLink```
2. To trigger security descriptor propagation, open **ldp.exe**.
3. Click **Connection** and select **Connect...** Next to **Server**, type the name of the domain controller that holds the PDC role for the domain. Next to **Port**, type **389** and click **OK**.
4. Click **Connection** and select **Bind...** Click **OK** to bind as the currently signed-in user.
5. Click **Browser** and select **Modify**. Leave the **DN** text box blank. Next to **Attribute**, type **RunProtectAdminGroupsTask**. Next to **Values**, type **1**. Click **Enter** to add this to the **Entry List**.
6. Click **Run** to start the task.
7. Close LDP.
### Configuring Dual Enrollment using Group Policy
You configure Windows 10 or Windows 11 to support dual enrollment using the computer configuration portion of a Group Policy object.
1. Using the Group Policy Management Console (GPMC), create a new domain-based Group Policy object and link it to an organizational Unit that contains Active Directory computer objects used by privileged users.
2. Edit the Group Policy object from step 1.
3. Enable the **Allow enumeration of emulated smart cards for all users** policy setting located under **Computer Configuration->Administrative Templates->Windows Components->Windows Hello for Business**.
4. Close the Group Policy Management Editor to save the Group Policy object. Close the GPMC.
5. Restart computers targeted by this Group Policy object.
The computer is ready for dual enrollment. Sign in as the privileged user first and enroll for Windows Hello for Business. Once completed, sign out and sign in as the non-privileged user and enroll for Windows Hello for Business. You can now use your privileged credential to perform privileged tasks without using your password and without needing to switch users.

2
windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md
View File

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

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

File diff suppressed because it is too large Load Diff

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

@ -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,14 +25,14 @@ 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.
![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png)
:::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).
To resolve this issue, the CRL distribution point must be a location accessible by Microsoft Entra joined devices that don't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first, in the list of distribution points.
@ -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)
@ -216,6 +217,7 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**
1. Select the **Details** tab. Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list. Select **CRL Distribution Point**
1. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**
![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png)
## Deploy the root CA certificate to Microsoft Entra joined devices

56
windows/security/identity-protection/hello-for-business/how-it-works-authentication.md
View File

@ -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,11 +19,11 @@ 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.|
|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.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|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.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
## Microsoft Entra join authentication to Active Directory using cloud Kerberos trust
@ -31,7 +31,7 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller.
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller.
|B | After locating a domain controller, the Kerberos provider sends a partial TGT that it received from Microsoft Entra ID from a previous Microsoft Entra authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.|
## Microsoft Entra join authentication to Active Directory using a key
@ -40,9 +40,9 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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.|
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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 might have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Microsoft Entra joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins.
@ -53,12 +53,12 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
| Phase | Description |
| :----: | :----------- |
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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.|
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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
@ -66,11 +66,11 @@ 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 queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.
|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 queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.
|B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Microsoft Entra ID.
|C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Microsoft Entra Kerberos and returns them to Cloud AP.
|D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT.
|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After locating an active domain controller, the Kerberos provider sends the partial TGT that it received from Microsoft Entra ID to the domain controller. The partial TGT contains only the user SID and is signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a domain controller. After locating an active domain controller, the Kerberos provider sends the partial TGT that it received from Microsoft Entra ID to the domain controller. The partial TGT contains only the user SID and is signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
## Microsoft Entra hybrid join authentication using a key
@ -78,13 +78,13 @@ 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 Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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.
|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 Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT]
> In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time.
@ -95,13 +95,13 @@ 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 Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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.
|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 Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|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.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT]
> In the above deployment model, a **newly provisioned** user will not be able to sign in using Windows Hello for Business unless the device has line of sight to the domain controller.

2
windows/security/identity-protection/hello-for-business/how-it-works-provisioning.md
View File

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

8
windows/security/identity-protection/hello-for-business/how-it-works.md
View File

@ -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
---
@ -78,7 +78,7 @@ All devices included in the Windows Hello for Business deployment must go throug
- For cloud and hybrid deployments, the identity provider is Microsoft Entra ID, and the device registers with the *Device Registration Service*
- For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the *Enterprise Device Registration Service* hosted on AD FS
When a device is registered, the IdP provides the device with an identity that is used to authenticate the device when a user signs-in.
When a device is registered, the IdP provides the device with an identity that is used to authenticate the device when a user signs in.
There are different registration types, which are identified as *join type*. For more information, see [What is a device identity][ENTRA-1].
@ -156,8 +156,8 @@ Access to the key material stored in the container, is enabled only by the PIN o
A container can contain several types of key material:
- An *authentication key*, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key is generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key
- One or multiple *user ID keys*. These keys can be either symmetric or asymmetric, depending on which IdP you use. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the user ID key or key pair can request access. User ID keys are used to sign or encrypt authentication requests or tokens sent from this device to the IdP. User ID keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IdP (which stores it for later verification), and securely stores the private key. For organizatrons, the user ID keys can be generated in two ways:
- The user ID key pair can be associated with an organization's Certificate Authority (CA). This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the organization to store other certificates in the protected container. For example, certificates that allows the user to authenticate via RDP
- One or multiple *user ID keys*. These keys can be either symmetric or asymmetric, depending on which IdP you use. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the user ID key or key pair can request access. User ID keys are used to sign or encrypt authentication requests or tokens sent from this device to the IdP. User ID keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IdP (which stores it for later verification), and securely stores the private key. For organizations, the user ID keys can be generated in two ways:
- The user ID key pair can be associated with an organization's Certificate Authority (CA). This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the organization to store other certificates in the protected container. For example, certificates that allow the user to authenticate via RDP
- The IdP can generate the user ID key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI
User ID keys are used to authenticate the user to a service. For example, by signing a nonce to prove possession of the private key, which corresponds to a registered public key. Users with an Active Directory, Microsoft Entra ID or Microsoft account have a key associated with their account. The key can be used to sign into their Windows device by authenticating to a domain controller (Active Directory scenario), or to the cloud (Microsoft Entra ID and MSA scenarios).

2
windows/security/identity-protection/hello-for-business/index.md
View File

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

2
windows/security/identity-protection/hello-for-business/multifactor-unlock.md
View File

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

3
windows/security/identity-protection/hello-for-business/pin-reset.md
View File

@ -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
---
@ -121,7 +121,6 @@ GET https://graph.microsoft.com/v1.0/organization?$select=id
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
| Group policy path | Group policy setting | Value |

2
windows/security/identity-protection/hello-for-business/policy-settings.md
View File

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

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

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

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

@ -20,7 +20,7 @@ items:
- name: Configure PIN reset
href: pin-reset.md
- name: Configure dual enrollment
href: hello-feature-dual-enrollment.md
href: dual-enrollment.md
- name: Configure dynamic lock
href: hello-feature-dynamic-lock.md
- name: Configure multi-factor unlock

24
windows/security/identity-protection/hello-for-business/webauthn-apis.md
View File

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

2
windows/security/identity-protection/web-sign-in/index.md
View File

@ -1,7 +1,7 @@
---
title: Web sign-in for Windows
description: Learn how Web sign-in in Windows works, key scenarios, and how to configure it.
ms.date: 03/12/2023
ms.date: 04/10/2024
ms.topic: how-to
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>