Update authentication requirements for Microsoft Entra ID

windows/security/identity-protection/hello-for-business/deploy/index.md

@@ -106,20 +106,26 @@ Cloud Kerberos trust is the only hybrid deployment option that doesn't require t
 |    **🔲** | **On-premises** | Key | yes |
 |    **🔲** | **On-premises** | Certificate | yes |
 
-## Authentication
+## Authentication to Microsoft Entra ID
 
-Here's a list of requirements for federated and nonfederated deployments.
+Users can authenticate to Microsoft Entra ID using federated authentication or cloud (nonfederated) authentication. Requirements vary based on trust type and authentication type:
 
 || Deployment model | Trust type | Authentication to Microsoft Entra ID | Requirements |
 |--|--|--|--|--|
 |    **🔲** | **Cloud-only** | n/a | Cloud authentication | n/a |
 |    **🔲** | **Cloud-only** | n/a | Federated authentication | third-party federation service |
 |    **🔲** | **Hybrid** | Cloud Kerberos trust | Cloud authentication | Microsoft Entra Kerberos |
-|    **🔲** | **Hybrid** | Key trust | Cloud authentication | PHS or PTA|
+|    **🔲** | **Hybrid** | Key trust | Cloud authentication | Password hash sync (PHS) or Pass-through authentication (PTA)|
 |    **🔲** | **Hybrid** | Key trust | Federated authentication | AD FS or third-party federation service. Key trust with federated authentication doesn't support PTA or PHS |
 |    **🔲** | **Hybrid** | Certificate trust | non-federated | AD FS |
 |    **🔲** | **Hybrid** | Certificate trust | federated | AD FS |
 
+To learn more:
+
+- [Federation with Microsoft Entra ID](/entra/identity/hybrid/connect/whatis-fed)
+- [Password hash synchronization (PHS)][ENTRA-6]
+- [Pass-through authentication (PTA)][ENTRA-7]
+
 ### Device registration
 
 For on-premises deployments, the server running the Active Directory Federation Services (AD FS) role is responsible for device registration. For cloud-only and hybrid deployments, devices must register in Microsoft Entra ID.

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

@@ -59,47 +59,6 @@ For more information, read [how device registration works](/azure/active-directo
 
 Provisioning is when the user uses one form of authentication to request a new Windows Hello for Business credential. Typically the user signs in to Windows using user name and password. The provisioning flow requires a second factor of authentication before it can create a strong, two-factor Windows Hello for Business credential.
 
-### Authentication to Microsoft Entra ID and MFA
-
-Here are some core concepts regarding authentication to Microsoft Entra ID:
-
-:::row:::
-    :::column span="1":::
-        **Password hash sync (PHS)**
-    :::column-end:::
-    :::column span="3":::
-        Password hash sync is the simplest way to enable authentication for on-premises directory objects in Microsoft Entra ID. With PHS, you synchronize your on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Microsoft Entra ID so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Microsoft Entra ID so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Microsoft Entra ID or stored in Microsoft Entra ID in clear text. Some premium features of Microsoft Entra ID, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
-
-        Learn more: [password hash synchronization (PHS)][ENTRA-6]
-    :::column-end:::
-:::row-end:::
-:::row:::
-    :::column span="1":::
-        **Pass-through authentication (PTA)**
-    :::column-end:::
-    :::column span="3":::
-        Pass-through authentication provides a simple password validation for Microsoft Entra authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Allows your users to sign in to both on-premises and Microsoft cloud resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Microsoft Entra ID. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
-
-        Learn more: [pass-through authentication (PTA)][ENTRA-7]
-    :::column-end:::
-:::row-end:::
-:::row:::
-    :::column span="1":::
-        **Cloud authentication**
-    :::column-end:::
-    :::column span="3":::
-        Cloud authentication is for environments where Microsoft Entra ID manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication, rather than a federation service like Active Directory Federation Services (AD FS).
-    :::column-end:::
-:::row-end:::
-:::row:::
-    :::column span="1":::
-        **Federated authentication**
-    :::column-end:::
-    :::column span="3":::
-        Federated authentication is for environments where Microsoft Entra ID hands off the authentication process to a separate trusted authentication system, such as on-premises Active Directory Federation Services (AD FS), to validate the user's credential. The authentication system can provide other advanced authentication requirements, for example, third-party multifactor authentication.
-    :::column-end:::
-:::row-end:::
-
 ### Use gesture and key generation in TPM
 
 #### Attestation identity keys

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

@@ -59,6 +59,10 @@ Windows stores biometric data that is used to implement Windows Hello securely o
 
 > [!VIDEO https://learn-video.azurefd.net/vod/player?id=fb5ceb53-d82b-4997-bde1-d473b620038a]
 
+The biometric data used to support Windows Hello is stored on the local device only. It doesn't roam and is never sent to external devices or servers. This separation helps to stop potential attackers by providing no single collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an attacker was able to get the biometric data from a device, it cannot be converted back into a raw biometric sample that could be recognized by the biometric sensor.
+
+Each sensor on a device has its own biometric database file where template data is stored. Each database has a unique, randomly generated key that is encrypted to the system. The template data for the sensor is encrypted with this per-database key using AES with CBC chaining mode. The hash is SHA256. Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors store biometric data on the fingerprint module instead of in the database file.
+
 ## Benefits of Windows Hello
 
 When an identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services.
@@ -199,24 +203,8 @@ Keys can be generated in hardware (TPM 1.2 or 2.0) or software, based on configu
 
 Authentication is the two factor authentication with combination of a device (key or certificate) and something that the user sknows (a PIN), or something that person is (biometric). We refer to PIN and biometrics as *Windows Hello gestures*. Windows Hello gestures don't roam between devices and aren't shared with the server; they are stored locally on the device.
 
-The private key never leaves a device. The authenticating server has a public key mapped to user account during the registration process
+
 PIN entry and biogesture both trigger Windows to verify the user's identity and authenticate using Windows Hello keys or certificates
-Personal (Microsoft account) and corporate (Microsoft Entra ID/Active Directory) accounts use separate containers for keys, separated by domains, to ensure user privacy
-
-
-The biometric data used to support Windows Hello is stored on the local device only. It doesn't roam and is never sent to external devices or servers. This separation helps to stop potential attackers by providing no single collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an attacker was able to get the biometric data from a device, it cannot be converted back into a raw biometric sample that could be recognized by the biometric sensor.
-
-Each sensor on a device has its own biometric database file where template data is stored. Each database has a unique, randomly generated key that is encrypted to the system. The template data for the sensor is encrypted with this per-database key using AES with CBC chaining mode. The hash is SHA256. Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors store biometric data on the fingerprint module instead of in the database file.
-
-PIN is better than password:
-Tied to the device
-- Pin is useless to anyone without the specific device
-Local to the device
-- Pin isn't transmitted anywhere, and it isn't stored on the server
-Backed by hardware
-- Protect PIN against brute-force and other potentials known attacks
-Can be complex
-
 
 *The Windows Hello for Business Container (NGC) can be used to protect keys from many sources.
 *Each key is generated and bound to the TPM if the hardware is capable.
@@ -224,19 +212,24 @@ Can be complex
 *Can also contain generic passkey credentials
 
 
+-->
 
+There are 5 phases related to Windows Hello for Business:
 
-Deployment steps:
-Device Registration
-- Device is joined to AD and/or AAD
-Provisioning
-    *Enable WHfB using Group Policy or Intune
-    *When the policy is received, if all the prerequisites are met, the user will be able to configure WHfB
-    *The dsregcmd tool is critical to solve registration and provisioning issues
-- WHFB is enrolled on the client: During enrollment: the user is required to perform MFA
-- Keys are registered with AD and/or AAD
-Authentication
-- WHfB is used to authenticate user against AAD and/or AD
+1. Device registration
+1. Provisioning
+    1. When the policy is received, if all the prerequisites are met, the user will be able to configure WHfB
+    > [!TIP]
+    > The `dsregcmd.exe` tool is critical to solve registration and provisioning issues
+    1. The device receives a policy that enables WHfB and passes all the pre-requisites (based on  the deployment type). A user provisions, or *enrolls*, Windows Hello by authenticating to the IdP with MFA.
+    1. After successful MFA, the user must provide a gesture and PIN which will trigger a key pair generation in TPM    
+    1. Key registration: the public key is registered with the IdP and the private key is stored in the TPM. The private key is protected by the TPM and can't be exported.
+1. Authentication
+    In this phase, WHfB is used to authenticate user against the IdP. The user provides a gesture (PIN or biometric) and the IdP validates the user identity by mapping the user account to the public key used during the key registration step
+1. Key synchronization
+    In this phase, applicable only to hybrid deploments, the user's public key is synchronized from Microsoft Entra ID to Active Directory.
+1. Certificate enrollment
+    This phase occurs only in certificate trust deployments. A user certificate is issued by an internal PKI and the public key stored in the Windows Hello container