Merge branch 'main' into pm-20231301-updates

.openpublishing.redirection.json

@@ -20434,6 +20434,21 @@
       "source_path": "windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md",
       "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always",
       "redirect_document_id": false
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-faq",
+      "redirect_document_id": true
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-feature-conditional-access.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-faq",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-event-300.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-faq",
+      "redirect_document_id": false
     }
   ]
 }

windows/security/identity-protection/credential-guard/credential-guard-considerations.md

@@ -1,7 +1,7 @@
 ---
 title: Considerations when using Windows Defender Credential Guard
-description: Considerations and recommendations for certain scenarios when using Windows Defender Credential Guard in Windows.
+description: Considerations and recommendations for certain scenarios when using Windows Defender Credential Guard.
-ms.date: 08/31/2017
+ms.date: 01/06/2023
 ms.topic: article
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
@@ -10,58 +10,72 @@ appliesto:
 
 # Considerations when using Windows Defender Credential Guard
 
-Passwords are still weak. We recommend that in addition to deploying Windows Defender Credential Guard, organizations move away from passwords to other authentication methods, such as physical smart cards, virtual smart cards, or Windows Hello for Business.
+It's recommended that in addition to deploying Windows Defender Credential Guard, organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys or smart cards.
 
-Windows Defender Credential Guard uses hardware security, so some features such as Windows To Go, aren't supported.
+## Wi-fi and VPN considerations
 
-## Wi-fi and VPN Considerations
+When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for single sign-on. You'll be forced to enter your credentials to use these protocols and can't save the credentials for future use.\
+If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1.
 
-When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for Single Sign-On. You'll be forced to enter your credentials to use these protocols and can't save the credentials for future use. If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1. For WiFi and VPN connections, Microsoft recommends that organizations move from MSCHAPv2-based connections such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication such as PEAP-TLS or EAP-TLS.
+For WiFi and VPN connections, it's recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).
 
-## Kerberos Considerations
+## Kerberos considerations
 
-When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process. Use constrained or resource-based Kerberos delegation instead.
+When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process.\
+Use constrained or resource-based Kerberos delegation instead.
 
-## 3rd Party Security Support Providers Considerations
+## Third party Security Support Providers considerations
 
-Some 3rd party Security Support Providers (SSPs and APs) might not be compatible with Windows Defender Credential Guard because it doesn't allow third-party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs aren't supported. We recommend that custom implementations of SSPs/APs are tested with Windows Defender Credential Guard. SSPs and APs that depend on any undocumented or unsupported behaviors fail. For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs. For more info, see [Restrictions around Registering and Installing a Security Package](/windows/win32/secauthn/restrictions-around-registering-and-installing-a-security-package) on MSDN.
+Some third party Security Support Providers (SSPs and APs) might not be compatible with Windows Defender Credential Guard because it doesn't allow third-party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs aren't supported.\
+It's recommended that custom implementations of SSPs/APs are tested with Windows Defender Credential Guard. SSPs and APs that depend on any undocumented or unsupported behaviors fail. For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs.
 
-## Upgrade Considerations
+For more information, see [Restrictions around Registering and Installing a Security Package](/windows/win32/secauthn/restrictions-around-registering-and-installing-a-security-package).
 
-As the depth and breadth of protections provided by Windows Defender Credential Guard are increased, subsequent releases of Windows 10 with Windows Defender Credential Guard running may impact scenarios that were working in the past. For example, Windows Defender Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities. Test scenarios required for operations in an organization before upgrading a device using Windows Defender Credential Guard.
+## Upgrade considerations
 
-### Saved Windows Credentials Protected
+As the depth and breadth of protections provided by Windows Defender Credential Guard are increased, new releases of Windows with Windows Defender Credential Guard running may affect scenarios that were working in the past. For example, Windows Defender Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities.
 
-Starting with Windows 10, version 1511, domain credentials that are stored with Credential Manager are protected with Windows Defender Credential Guard. Credential Manager allows you to store three types of credentials: Windows credentials, certificate-based credentials, and generic credentials. Generic credentials such as user names and passwords that you use to log on to websites aren't protected since the applications require your cleartext password. If the application doesn't need a copy of the password, they can save domain credentials as Windows credentials that are protected. Windows credentials are used to connect to other computers on a network. 
+Test scenarios required for operations in an organization before upgrading a device using Windows Defender Credential Guard.
+
+## Saved Windows credentials protected
+
+Domain credentials that are stored in *Credential Manager* are protected with Windows Defender Credential Guard. Credential Manager allows you to store three types of credentials:
+
+- Windows credentials
+- Certificate-based credentials
+- Generic credentials
+
+Generic credentials, such as user names and passwords that you use to sign in websites, aren't protected since the applications require your clear-text password. If the application doesn't need a copy of the password, they can save domain credentials as Windows credentials that are protected. Windows credentials are used to connect to other computers on a network.
 
 The following considerations apply to the Windows Defender Credential Guard protections for Credential Manager:
 
-* Windows credentials saved by Remote Desktop Client can't be sent to a remote host. Attempts to use saved Windows credentials fail, displaying the error message "Logon attempt failed."
+- Windows credentials saved by the Remote Desktop client can't be sent to a remote host. Attempts to use saved Windows credentials fail, displaying the error message *Logon attempt failed.*
-* Applications that extract Windows credentials fail.
+- Applications that extract Windows credentials fail
-* When credentials are backed up from a PC that has Windows Defender Credential Guard enabled, the Windows credentials can't be restored. If you need to back up your credentials, you must do this before you enable Windows Defender Credential Guard. Otherwise, you can't restore those credentials.
+- When credentials are backed up from a PC that has Windows Defender Credential Guard enabled, the Windows credentials can't be restored. If you need to back up your credentials, you must do so before you enable Windows Defender Credential Guard. Otherwise, you can't restore those credentials
 
-## Clearing TPM Considerations
+## Clearing TPM considerations
 
-Virtualization-based Security (VBS) uses the TPM to protect its key. So when the TPM is cleared then the TPM protected key used to encrypt VBS secrets is lost.
+Virtualization-based Security (VBS) uses the TPM to protect its key. When the TPM is cleared, the TPM protected key used to encrypt VBS secrets is lost.
 
 >[!WARNING]
-> Clearing the TPM results in loss of protected data for all features that use VBS to protect data.  <br>
+> Clearing the TPM results in loss of protected data for all features that use VBS to protect data.
-> When a TPM is cleared ALL features, which use VBS to protect data can no longer decrypt their protected data.
+>
+> When a TPM is cleared, **all** features that use VBS to protect data can no longer decrypt their protected data.
 
-As a result Credential Guard can no longer decrypt protected data. VBS creates a new TPM protected key for Credential Guard. Credential Guard uses the new key to protect new data. However, the previously protected data is lost forever.
+As a result, Credential Guard can no longer decrypt protected data. VBS creates a new TPM protected key for Credential Guard. Credential Guard uses the new key to protect new data. However, the previously protected data is lost forever.
 
 >[!NOTE]
-> Credential Guard obtains the key during initialization. So the data loss will only impact persistent data and occur after the next system startup.
+> Credential Guard obtains the key during initialization. The data loss will only impact persistent data and occur after the next system startup.
 
 ### Windows credentials saved to Credential Manager
 
 Since Credential Manager can't decrypt saved Windows Credentials, they're deleted. Applications should prompt for credentials that were previously saved. If saved again, then Windows credentials are protected Credential Guard.
 
-### Domain-joined device’s automatically provisioned public key
+### Domain-joined device's automatically provisioned public key
 
-Beginning with Windows 10 and Windows Server 2016, domain-devices automatically provision a bound public key, for more information about automatic public key provisioning, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
+Active Directory domain-joined devices automatically provision a bound public key, for more information about automatic public key provisioning, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
 
-Since Credential Guard can't decrypt the protected private key, Windows uses the domain-joined computer's password for authentication to the domain. Unless additional policies are deployed, there should not be a loss of functionality. If a device is configured to only use public key, then it can't authenticate with password until that policy is disabled. For more information on Configuring devices to only use public key, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
+Since Credential Guard can't decrypt the protected private key, Windows uses the domain-joined computer's password for authentication to the domain. Unless other policies are deployed, there shouldn't be a loss of functionality. If a device is configured to only use public key, then it can't authenticate with password until that policy is disabled. For more information on Configuring devices to only use public key, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
 
 Also if any access control checks including authentication policies require devices to have either the KEY TRUST IDENTITY (S-1-18-4) or FRESH PUBLIC KEY IDENTITY (S-1-18-3) well-known SIDs, then those access checks fail. For more information about authentication policies, see [Authentication Policies and Authentication Policy Silos](/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos). For more information about well-known SIDs, see [[MS-DTYP] Section 2.4.2.4 Well-known SID Structures](/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab).
 
@@ -70,29 +84,22 @@ Also if any access control checks including authentication policies require devi
 On domain-joined devices, DPAPI can recover user keys using a domain controller from the user's domain. If a domain-joined device has no connectivity to a domain controller, then recovery isn't possible.
 
 >[!IMPORTANT]
-> Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. This ensures DPAPI functions and the user does not experience strange behavior. <br>
+> Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. This ensures DPAPI functions and the user does not experience strange behavior.
-Auto VPN configuration is protected with user DPAPI. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.
 
+Auto VPN configuration is protected with user DPAPI. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.
 If you must clear the TPM on a domain-joined device without connectivity to domain controllers, then you should consider the following.
 
 Domain user sign-in on a domain-joined device after clearing a TPM for as long as there's no connectivity to a domain controller:
 
-|Credential Type | Windows version | Behavior
+|Credential Type | Behavior
 |---|---|---|
-| Certificate (smart card or Windows Hello for Business) | All | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
+| Certificate (smart card or Windows Hello for Business) | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
-| Password | Windows 10 v1709 or later | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected.
+| Password | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected. |
-| Password | Windows 10 v1703 | If the user signed in with a password prior to clearing the TPM, then they can sign-in with that password and are unaffected.
-| Password | Windows 10 v1607 or earlier | Existing user DPAPI protected data is unusable. User DPAPI is able to protect new data.
 
 Once the device has connectivity to the domain controllers, DPAPI recovers the user's key and data protected prior to clearing the TPM can be decrypted.
 
 #### Impact of DPAPI failures on Windows Information Protection
 
-When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection.  The impact includes: Outlook 2016 is unable to start and work protected documents can't be opened.  If DPAPI is working, then newly created work data is protected and can be accessed.
+When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection.  The impact includes: Outlook is unable to start and work protected documents can't be opened. If DPAPI is working, then newly created work data is protected and can be accessed.
 
 **Workaround:** Users can resolve the problem by connecting their device to the domain and rebooting or using their Encrypting File System Data Recovery Agent certificate. For more information about Encrypting File System Data Recovery Agent certificate, see [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](/windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate).
-
-
-## See also
-
-- [What is virtualization-based security?](https://www.linkedin.com/learning/microsoft-cybersecurity-stack-advanced-identity-and-endpoint-protection/what-is-virtualization-based-security)

windows/security/identity-protection/hello-for-business/hello-event-300.md

@@ -1,37 +0,0 @@
----
-title: Event ID 300 - Windows Hello successfully created (Windows)
-description: This event is created when a Windows Hello for Business is successfully created and registered with Azure Active Directory (Azure AD).
-ms.date: 07/27/2017
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-
-# Event ID 300 - Windows Hello successfully created
-
-This event is created when Windows Hello for Business is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request.
-
-## Event details
-
-| **Product:** |                                                                                                                                            Windows 10 or Windows 11 operating system                                                                                                                                            |
-|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| **Log:**     | Event Viewer > Applications and Service Logs\Microsoft\Windows\User Device Registration\Admin |
-|   **ID:**    |                                                                                                                                                        300                                                                                                                                                        |
-| **Source:**  |                                                                                                                                    Microsoft Azure Device Registration Service                                                                                                                                    |
-| **Version:** |                                                                                                                                                        10    or 11                                                                                                                                                     |
-| **Message:** | The NGC key was successfully registered. Key ID: {4476694e-8e3b-4ef8-8487-be21f95e6f07}. UPN:test@contoso.com. Attestation: ATT\_SOFT. Client request ID: . Server request ID: db2da6bd-3d70-4b9b-b26b-444f669902da.</br>Server response: {"kid":"4476694e-8e3b-4ef8-8487-be21f95e6f07","upn":"test@contoso.com"} |
- 
-## Resolve
-
-This is a normal condition. No further action is required.
-
-## Related topics
-
-- [Windows Hello for Business](hello-identity-verification.md)
-- [How Windows Hello for Business works](hello-how-it-works.md)
-- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
-- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
-- [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
-- [Windows Hello and password changes](hello-and-password-changes.md)
-- [Windows Hello errors during PIN creation](/troubleshoot/windows-client/user-profiles-and-logon/windows-hello-errors-during-pin-creation-in-windows-10)
-- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)

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

@@ -2,219 +2,99 @@
 metadata:
   title: Windows Hello for Business Frequently Asked Questions (FAQ)
   description: Use these frequently asked questions (FAQ) to learn important details about Windows Hello for Business.
-  keywords: identity, PIN, biometric, Hello, passport
-  ms.prod: windows-client
-  ms.technology: itpro-security
-  ms.sitesec: library
-  ms.pagetype: security, mobile
-  audience: ITPro
-  author: paolomatarazzo
-  ms.author: paoloma
-  manager: aaroncz
-  ms.reviewer: prsriva
   ms.collection:
     - highpri
   ms.topic: faq
-  localizationpriority: medium
+  ms.date: 01/06/2023
-  ms.date: 11/11/2022
   appliesto: 
     - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 
-title: Windows Hello for Business Frequently Asked Questions (FAQ)
+title: Common questions about Windows Hello for Business
-summary: |
+summary: Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This Frequently Asked Questions (FAQ) article is intended to help you learn more about Windows Hello for Business.
 
 sections:
-  - name: Ignored
+
+  - name: Concepts
     questions:
-    
+      - question: What's the difference between Windows Hello and Windows Hello for Business?
-      - question: What is Windows Hello for Business cloud Kerberos trust?
         answer: |
-          Windows Hello for Business *cloud Kerberos trust* is a **trust model** that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
+          Windows Hello represents the biometric framework provided in Windows. Windows Hello lets users use biometrics to sign in to their devices by securely storing their user name and password and releasing it for authentication when the user successfully identifies themselves using biometrics. Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate.
-
-
-      - question: What about virtual smart cards?
-        answer: |
-          Windows Hello for Business is the modern, two-factor credential for Windows. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows deployments use Windows Hello for Business.
-
-      - question: What about convenience PIN?
-        answer: |
-          While *convenience PIN* provides a convenient way to sign in to Windows, it stills uses a password for authentication. Customers using *convenience PINs* should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs. Microsoft will be deprecating convenience PINs in the future and will publish the date early to ensure customers have adequate lead time to deploy Windows Hello for Business.
-
-      - question: Can I use Windows Hello for Business key trust and RDP?
-        answer: |
-          Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.
-
-          
-      - question: Can I deploy Windows Hello for Business by using Microsoft Configuration Manager?
-        answer: |
-          Windows Hello for Business deployments using Configuration Manager should follow the hybrid deployment model that uses Active Directory Federation Services. Starting in Configuration Manager version 1910, certificate-based authentication with Windows Hello for Business settings isn't supported. Key-based authentication is still valid with Configuration Manager. For more information, see [Windows Hello for Business settings in Configuration Manager](/configmgr/protect/deploy-use/windows-hello-for-business-settings).
-
-      - question: Can I deploy Windows Hello for Business by using Microsoft Intune?
-        answer: |
-          Windows Hello for Business deployments using Intune allow for a great deal of flexibility in deployment. For more information, see [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello).
-          
-      - question: How many users can enroll for Windows Hello for Business on a single Windows 10 computer?
-        answer: |
-          The maximum number of supported enrollments on a single Windows 10 computer is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, we strongly encourage the use of FIDO2 security keys.
-          
-      - question: Can I use Windows Hello for Business credentials in private browser mode or "incognito" mode?
-        answer: |
-          Windows Hello for Business credentials need access to device state, which is not available in private browser mode or incognito mode. Hence it can't be used in private browser or Incognito mode.
-
       - question: How can a PIN be more secure than a password?
         answer: |
           When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
           The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
-
+      - question: How does Windows Hello for Business authentication work?
+        answer: |
+          When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
+          These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It's important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn't require explicit validation through a user gesture, and the key material isn't exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure an application to require re-authentication anytime a specific operation is performed, even though the same account and PIN or gesture were already used to unlock the device.
+          For more information about the different authentication flows used by Windows Hello for Business, see [Windows Hello for Business and Authentication](hello-how-it-works-authentication.md).
+      - question: What happens after a user registers a PIN during the Windows Hello for Business enrollment process?
+        answer: |
+          Windows Hello generates a new public-private key pair on the device. The TPM generates and protects this private key; if the device doesn't have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the *protector key*. It's associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. **Each unique gesture generates a unique protector key**. The protector key securely wraps the *authentication key*. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary (for example, when using the PIN reset service). In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
+          At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means the user is able to securely sign in to the device with the PIN and thus be able to establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using the PIN, and then registers the new biometric, after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures.
       - question: What's a container?
         answer: |
-          In the context of Windows Hello for Business, it's shorthand for a logical grouping of key material or data. Windows Hello uses a single container that holds user key material for personal accounts, including key material associated with the user's Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
+          In the context of Windows Hello for Business, a container is a logical grouping of *key material* or data. Windows Hello uses a single container that holds user key material for personal accounts, including key material associated with the user's Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
           The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD.
-          Note that there are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials of Windows Hello stores, are protected without the creation of actual containers or folders.
+          
+          > [!NOTE]
+          > There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders.
+
           The container contains a set of keys, some of which are used to protect other keys. The following image shows an example: the protector key is used to encrypt the authentication key, and the authentication key is used to encrypt the individual keys stored in the container. Each logical container holds one or more sets of keys.\
           :::image type="content" source="images/passport-fig3-logicalcontainer.png" alt-text="logical container with set of keys":::
 
-      - question: How do I delete a Windows Hello for Business container on a device?
+          Containers 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 will be 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.
+            - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD 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 enterprises, the IDP keys can be generated in two ways:
+              - The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. 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 enterprise to store additional certificates in the protected container.
+              - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI.
+      - question: How are keys protected?
         answer: |
-          You can effectively disable Windows Hello for Business by launching `certutil.exe -deleteHelloContainer` on the end device under a user account, and then restarting the device.
+          Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IDP before the IDP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
-
+      - question: How does PIN caching work with Windows Hello for Business?
-      - question: How does Windows Hello for Business work with Azure AD registered devices?
         answer: |
-          A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices  if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using their existing gestures.
+          Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key. 
           
-          If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources. 
+          Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN. 
           
-          It's possible to Azure AD register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business. 
+          The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. Windows 10 doesn't provide any Group Policy settings to adjust this caching.
-
+      - question: Where is Windows Hello biometrics data stored?
-          For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register).
-
-      - question: I have Windows Server 2016 domain controller(s), so why is the Key Admins group missing?
         answer: |
-          The **Key Admins** and **Enterprise Key Admins** groups are created when you install the first Windows Server 2016 domain controller into a domain. Domain controllers running previous versions of Windows Server can't translate the security identifier (SID) to a name. To resolve this issue, transfer the PDC emulator domain role to a domain controller running Windows Server 2016.
+            When you enroll in Windows Hello, a representation of your biometrics, called an enrollment profile, is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
-
+      - question: What is the format used to store Windows Hello biometrics data on the device?
-      - question: Can I use a convenience PIN with Azure Active Directory?
         answer: |
-          It's currently possible to set a convenience PIN on Azure Active Directory Joined or Hybrid Active Directory Joined devices. However, convenience PIN isn't supported for Azure Active Directory user accounts (synchronized identities included). It's only supported for on-premises Domain Joined users and local account users.
+          Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (like face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it's stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash. 
-
+      - question: Who has access on Windows Hello biometrics data? 
-      - question: Can I use an external Windows Hello compatible camera when my computer has a built-in Windows Hello compatible camera?
         answer: |
-          Yes. Starting with Windows 10, version 21H1 an external Windows Hello compatible camera can be used if a device already supports an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see [IT tools to support Windows 10, version 21H1](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/it-tools-to-support-windows-10-version-21h1/ba-p/2365103). However, using external Hello cameras and accessories is restricted if ESS is enabled, please see [Windows Hello Enhanced Sign-in Security](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#pluggableperipheral-biometric-sensors).
+          Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
-
-      - question: Can I use an external Windows Hello compatible camera or other Windows Hello compatible accessory when my laptop lid is closed or docked?
-        answer: |
-          Some laptops and tablets with keyboards that close may not use an external Windows Hello compatible camera or other Windows Hello compatible accessory when the computer is docked with the lid closed. The issue has been addressed in Windows 11, version 22H2.
-
-      - question: Why does authentication fail immediately after provisioning hybrid key trust?
-        answer: |
-          In a hybrid deployment, a user's public key must sync from Azure AD to AD before it can be used to authenticate against a domain controller. This sync is handled by Azure AD Connect and will occur during a normal sync cycle.
-
-      - question: What is the password-less strategy?
-        answer: |
-          Watch Principal Program Manager Karanbir Singh's **Microsoft's guide for going password-less** Ignite 2017 presentation.
-          
-          [Microsoft's password-less strategy](hello-videos.md#microsofts-passwordless-strategy)
-          
-      - question: What is the user experience for Windows Hello for Business?
-        answer: |
-          The user experience for Windows Hello for Business occurs after the user signs in, after you deploy Windows Hello for Business policy settings to your environment.
-          
-      - question: What happens when a user forgets their PIN?
-        answer: |
-          If the user can sign in with a password, they can reset their PIN by selecting the "I forgot my PIN" link in Settings. Beginning with Windows 10 1709, users can reset their PIN above the lock screen by selecting the "I forgot my PIN" link on the PIN credential provider.
-          
-          For on-premises deployments, devices must be well-connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid customers can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see [PIN reset](/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset).
-        
-      - question: What URLs do I need to allow for a hybrid deployment?
-        answer: |
-          Communicating with Azure Active Directory uses the following URLs:
-          - enterpriseregistration.windows.net
-          - login.microsoftonline.com
-          - login.windows.net
-          - account.live.com
-          - accountalt.azureedge.net
-          - secure.aadcdn.microsoftonline-p.com
-          
-          If your environment uses Microsoft Intune, you will also need these other URLs:
-          - enrollment.manage.microsoft.com
-          - portal.manage.microsoft.com
-          
       - question: What's the difference between non-destructive and destructive PIN reset?
         answer: |
           Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
           
           Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then  performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
-          
-      - question: |
-          Which is better or more secure, key trust or certificate trust?
-        answer: |
-          The trust models of your deployment determine how you authenticate to Active Directory (on-premises). Both key trust and certificate trust use the same hardware-backed, two-factor credential. The differences between the two trust types are:
-          - Required domain controllers 
-          - Issuing end entity certificates
-          
-          The **key trust** model authenticates to Active Directory by using a raw key. Windows Server 2016 domain controllers enable this authentication. Key trust authenticate doesn't require an enterprise issued certificate, therefore you don't need to issue certificates to users (domain controller certificates are still needed).
-          
-          The **certificate trust** model authenticates to Active Directory by using a certificate. Because this authentication uses a certificate, domain controllers running previous versions of Windows Server can authenticate the user. Therefore, you need to issue certificates to users, but you don't need Windows Server 2016 domain controllers. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise's issuing certificate authority. 
-          
-      - question: Do I need Windows Server 2016 domain controllers?
-        answer: |
-          There are many deployment options from which to choose. Some of those options require an adequate number of Windows Server 2016 domain controllers in the site where you've deployed Windows Hello for Business. There are other deployment options that use existing Windows Server 2008 R2 or later domain controllers. Choose the deployment option that best suits your environment.
-
-      - question: What attributes are synchronized by Azure AD Connect with Windows Hello for Business?
-        answer: |
-          Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
-          
-      - question: Is Windows Hello for Business multi-factor authentication?
-        answer: |
-          Windows Hello for Business is two-factor authentication based on the observed authentication factors of: something you have, something you know, and something that's part of you. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
-
-      - question: Where is Windows Hello biometrics data stored?
-        answer: |
-            When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
-      
-      - question: What is the format used to store Windows Hello biometrics data on the device?
-        answer: |
-          Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (like face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it’s stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash. 
-      
-      - question: Who has access on Windows Hello biometrics data? 
-        answer: |
-          Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
-      
       - question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
         answer: |
-          Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a pin. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start** > **Settings** > **Accounts** > **Sign-in** options. Or just select on **Go to Sign-in options**. To enroll into Windows Hello, user can go to **Start** > **Settings** > **Accounts** > **Sign-in** options, select the Windows Hello method that they want to set up, and then select **Set up**. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can by policy request users to enroll into Windows Hello during autopilot or during initial setup of the device. Admins can disallow users to enroll into biometrics via Windows hello for business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
+          Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start > Settings > Accounts > Sign-in** options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
-
       - question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication?
         answer: |
-            To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start** > **Settings** > **Accounts** > **Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will unenroll the user from Windows Hello biometrics auth and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
+            To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start > Settings > Accounts > Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will u-enroll the user from Windows Hello biometrics authentication and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
 
-      - question: What about any diagnostic data coming out when WHFB is enabled?
+  - name: Management and operations
+    questions:  
+      - question: Can I deploy and manage Windows Hello for Business using Microsoft Intune?
         answer: |
-          To help us keep things working properly, to help detect and prevent fraud, and to continue improving Windows Hello, we collect diagnostic data about how people use Windows Hello. For example, data about whether people sign in with their face, iris, fingerprint, or PIN; the number of times they use it; and whether it works or not is all valuable information that helps us build a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319). 
+          Yes, hybrid and cloud-only Windows Hello for Business deployments can use Microsoft Intune. For more information, see [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello).
-     
+      - question: Can I deploy and manage Windows Hello for Business by using Microsoft Configuration Manager?
-      - question: What are the biometric requirements for Windows Hello for Business?
         answer: |
-          Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information.
+          Starting in Configuration Manager, version 2203, Windows Hello for Business deployments using Configuration Manager are no longer supported.
-          
+      - question: How do I delete a Windows Hello for Business container on a device?
-      - question: Can I use both a PIN and biometrics to unlock my device?
         answer: |  
-          Starting in Windows 10, version 1709, you can use multi-factor unlock to require users to provide an extra factor to unlock their device. Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop. To learn more, see [Multifactor Unlock](feature-multifactor-unlock.md).
+          You can effectively disable Windows Hello for Business by launching `certutil.exe -deleteHelloContainer` on the end device under a user account, and then restarting the device.          
-
+      - question: What happens when a user forgets their PIN?
-      - question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
         answer: |
-          Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn’t allow you to remove a mask temporarily, consider unenrolling from face authentication and only using PIN or fingerprint.
+          If the user can sign in with a password, they can reset their PIN by selecting the *I forgot my PIN* link in the Settings app. Users can reset also their PIN from the lock screen by selecting the *I forgot my PIN* link on the PIN credential provider.
-
-      - question: What's the difference between Windows Hello and Windows Hello for Business?
-        answer: |
-          Windows Hello represents the biometric framework provided in Windows 10. Windows Hello lets users use biometrics to sign in to their devices by securely storing their user name and password and releasing it for authentication when the user successfully identifies themselves using biometrics. Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate.
-
-      - question: Why can't I enroll biometrics for my local, built-in administrator?
-        answer: |
-          Windows 10 doesn't allow the local administrator to enroll biometric gestures (face or fingerprint).
-
-      - question: I have extended Active Directory to Azure Active Directory. Can I use the on-premises deployment model?
-        answer: |
-          No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.
           
+          For on-premises deployments, devices must be connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid deployments can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see [PIN reset](/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset).
       - question: Does Windows Hello for Business prevent the use of simple PINs?
         answer: |
           Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next. The algorithm counts the number of steps required to reach the next digit, overflowing at 10 ('zero').
@@ -230,33 +110,37 @@ sections:
           - The PIN 1872 doesn't have a constant delta (7,9,5), so it's allowed
           
           This check prevents repeating numbers, sequential numbers, and simple patterns. It always results in a list of 100 disallowed PINs (independent of the PIN length). This algorithm doesn't apply to alphanumeric PINs.
-          
+      - question: Which diagnostic data is collected when Windows Hello for Business is enabled?
-      - question: How does PIN caching work with Windows Hello for Business?
         answer: |
-          Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key. 
+          To help Microsoft keep things working properly, to help detecting and preventing fraud, and to continue improving Windows Hello, diagnostic data about how people use Windows Hello is collected. For example:
-          
+          - Data about whether people sign in with their face, iris, fingerprint, or PIN
-          Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN. 
+          - The number of times they use it
-          
+          - Whether it works or not
-          The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. Windows 10 doesn't provide any Group Policy settings to adjust this caching.
+          All this is valuable information that helps Microsoft building a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319). 
-          
       - question: Can I disable the PIN while using Windows Hello for Business?
         answer: |
           No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.
-
+      - question: What is Event ID 300?
-      - question: How are keys protected?
         answer: |
-          Wherever possible, Windows Hello for Business takes advantage of Trusted Platform Module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business don't require a TPM. Administrators can choose to allow key operations in software.
+          This event is created when Windows Hello for Business is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required.
-          
-          Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against various known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they'll need to use MFA to reauthenticate to the IDP before the IDP allows them to re-register).
 
+  - name: Design and planning
+    questions:
       - question: Can Windows Hello for Business work in air-gapped environments?
         answer: |
           Yes. You can use the on-premises Windows Hello for Business deployment and combine it with a third-party MFA provider that doesn't require internet connectivity to achieve an air-gapped Windows Hello for Business deployment.
-
+      - question: How many users can enroll for Windows Hello for Business on a single Windows device?
-      - question: Can I use third-party authentication providers with Windows Hello for Business?
         answer: |
-          Yes, if you're using federated hybrid deployment, you can use any third-party that provides an Active Directory Federation Services (AD FS) multi-factor authentication adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
+          The maximum number of supported enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, or for users that sign-in to many devices (for example, a support technician), it's recommended the use of FIDO2 security keys.
-          
+      - question: I have extended Active Directory to Azure Active Directory. Can I use the on-premises deployment model?
+        answer: |
+          No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.
+      - question: What attributes are synchronized by Azure AD Connect with Windows Hello for Business?
+        answer: |
+          Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
+      - question: Can I use third-party MFA providers with Windows Hello for Business?
+        answer: |
+          Yes, if you're using federated hybrid deployment, you can use any third-party that provides an AD FS MFA adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
       - question: Does Windows Hello for Business work with third-party federation servers?
         answer: |
           Windows Hello for Business works with any third-party federation servers that support the protocols used during the provisioning experience.<br><br>
@@ -267,12 +151,100 @@ sections:
           | [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and log in hints. |  
           | [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](/openspecs/windows_protocols/ms-oapxbc/2f7d8875-0383-4058-956d-2fb216b44706) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (the OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
           | [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define other claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define more provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. |
-          
+      - question: Can I enroll local Windows accounts in Windows Hello for Business?
-      - question: Does Windows Hello for Business work with Mac and Linux clients?
         answer: |
-          Windows Hello for Business is a feature of Windows 10. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration).
+          Windows Hello for Business is not designed to work with local accounts.
-          Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms.
+      - question: What are the biometric requirements for Windows Hello for Business?
+        answer: |
+          Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information.
+      - question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
+        answer: |
+          Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint.
+      - question: How does Windows Hello for Business work with Azure AD registered devices?
+        answer: |
+          A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices  if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.
 
+          If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources. 
+
+          It's possible to Azure AD register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business. 
+
+          For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register).
+      - question: Does Windows Hello for Business work with non-Windows operating systems?
+        answer: |
+          Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration).
       - question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
         answer: |
           No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD DS.
+      - question: Is Windows Hello for Business considered multi-factor authentication?
+        answer: |
+          Windows Hello for Business is two-factor authentication based on the observed authentication factors of: *something you have*, *something you know*, and *something that's part of you*. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
+
+          > [!NOTE]
+          > The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources. For more information, see [What is a Primary Refresh Token](/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim).
+      - question: Which is a better or more secure for of authentication, key or certificate?
+        answer: |
+          Both types of authentication provide the same security; one is not more secure than the other.
+          The trust models of your deployment determine how you authenticate to Active Directory (on-premises). Both key trust and certificate trust use the same hardware-backed, two-factor credential. The differences between the two trust types is the issuance of end-entity certificates:
+          - The *key trust* model authenticates to Active Directory by using a raw key. Key trust doesn't require an enterprise-issued certificate, therefore you don't need to issue certificates to users (domain controller certificates are still needed)
+          - The *certificate trust* model authenticates to Active Directory by using a certificate. Therefore, you need to issue certificates to users. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise's issuing CA
+      - question: What is convenience PIN?
+        answer: |
+          *Convenience PIN* provides a simpler way to sign in to Windows than passwords, but it still uses a password for authentication. When the correct convenience PIN is provided to Windows, the password information is loaded from its cache and authenticates the user. Organizations using convenience PINs should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs.
+      - question: Can I use a convenience PIN with Azure Active Directory?
+        answer: |
+          No. While it's possible to set a convenience PIN on Azure AD joined and hybrid Azure AD joined devices, convenience PIN isn't supported for Azure AD user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.
+      - question: What about virtual smart cards?
+        answer: |
+          Windows Hello for Business is the modern, two-factor credential for Windows. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows deployments use Windows Hello for Business.
+      - question: What URLs do I need to allow for a hybrid deployment?
+        answer: |
+          For a list of required URLs, see [Microsoft 365 Common and Office Online](/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#microsoft-365-common-and-office-online).
+                    
+          If your environment uses Microsoft Intune, see [Network endpoints for Microsoft Intune](/mem/intune/fundamentals/intune-endpoints).
+
+  - name: Features
+    questions:      
+      - question: Can I use an external Windows Hello compatible camera when my computer has a built-in Windows Hello compatible camera?
+        answer: |
+          Yes. Starting with Windows 10, version 21H1 an external Windows Hello compatible camera can be used if a device already supports an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see [IT tools to support Windows 10, version 21H1](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/it-tools-to-support-windows-10-version-21h1/ba-p/2365103). However, using external Hello cameras and accessories is restricted if ESS is enabled, please see [Windows Hello Enhanced Sign-in Security](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#pluggableperipheral-biometric-sensors).
+      - question: Can I use an external Windows Hello compatible camera or other Windows Hello compatible accessory when my laptop lid is closed or docked?
+        answer: |
+          Some laptops and tablets with keyboards that close may not use an external Windows Hello compatible camera or other Windows Hello compatible accessory when the computer is docked with the lid closed. The issue has been addressed in Windows 11, version 22H2.
+      - question: Can I use Windows Hello for Business credentials in private browser mode or "incognito" mode?
+        answer: |
+          Windows Hello for Business credentials need access to device state, which is not available in private browser mode or incognito mode. Hence it can't be used in private browser or Incognito mode.
+      - question: Can I use both a PIN and biometrics to unlock my device?
+        answer: |
+          You can use *multi-factor unlock* to require users to provide an extra factor to unlock their device. Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop. To learn more, see [Multifactor Unlock](feature-multifactor-unlock.md).
+
+  - name: Cloud Kerberos trust
+    questions:
+      - question: What is Windows Hello for Business cloud Kerberos trust?
+        answer: |
+          Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
+      - question: Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment?
+        answer: |
+          This feature doesn't work in a pure on-premises AD domain services environment.
+      - question: Does Windows Hello for Business cloud Kerberos trust work in a Windows sign-in with RODC present in the hybrid environment?
+        answer: |
+          Windows Hello for Business cloud Kerberos trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud Kerberos trust will work.
+      - question: Do I need line of sight to a domain controller to use Windows Hello for Business cloud Kerberos trust?
+        answer: |
+          Windows Hello for Business cloud Kerberos trust requires line of sight to a domain controller when:
+          - a user signs-in for the first time or unlocks with Windows Hello for Business after provisioning
+          - attempting to access on-premises resources secured by Active Directory
+      - question: Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust?
+        answer: |
+          Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [remote credential guard][/windows/security/identity-protection/remote-credential-guard] or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
+      - question: Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust?
+        answer: |
+          No, only the number necessary to handle the load from all cloud Kerberos trust devices.
+
+  - name: Key trust
+    questions:
+      - question: Why does authentication fail immediately after provisioning hybrid key trust?
+        answer: |
+          In a hybrid deployment, a user's public key must sync from Azure AD to AD before it can be used to authenticate against a domain controller. This sync is handled by Azure AD Connect and will occur during a normal sync cycle.
+      - question: Can I use Windows Hello for Business key trust and RDP?
+        answer: |
+          Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.

windows/security/identity-protection/hello-for-business/hello-feature-conditional-access.md

@@ -1,38 +0,0 @@
----
-title: Conditional Access
-description: Ensure that only approved users can access your devices, applications, and services from anywhere by enabling single sign-on with Azure Active Directory.
-ms.date: 09/09/2019
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-
-# Conditional access
-
-**Requirements:**
-
-* Azure Active Directory
-* Hybrid Windows Hello for Business deployment
-
-In a mobile-first, cloud-first world, Azure Active Directory enables single sign-on to devices, applications, and services from anywhere. With the proliferation of devices (including BYOD), work off corporate networks, and 3rd party SaaS applications, IT professionals are faced with two opposing goals:
-
-* Empower the end users to be productive wherever and whenever
-* Protect the corporate assets at any time
-
-To improve productivity, Azure Active Directory provides your users with a broad range of options to access your corporate assets. With application access management, Azure Active Directory enables you to ensure that only the right people can access your applications. What if you want to have more control over how the right people are accessing your resources under certain conditions? What if you even have conditions under which you want to block access to certain applications even for the right people? For example, it might be OK for you if the right people are accessing certain applications from a trusted network; however, you might not want them to access these applications from a network you don't trust. You can address these questions using conditional access.
-
-> [!NOTE]
-> For more details about the way Windows Hello for Business interacts with Azure AD Multi-Factor Authentication and Conditional Access, see [this article](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/why-are-my-users-not-prompted-for-mfa-as-expected/ba-p/1449032).
-
-Read [Conditional access in Azure Active Directory](/azure/active-directory/active-directory-conditional-access-azure-portal) to learn more about Conditional Access.  Afterwards, read [Getting started with conditional access in Azure Active Directory](/azure/active-directory/active-directory-conditional-access-azure-portal-get-started) to start deploying Conditional access.
-
-## Related topics
-
-* [Windows Hello for Business](hello-identity-verification.md)
-* [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
-* [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
-* [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
-* [Windows Hello and password changes](hello-and-password-changes.md)
-* [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
-* [Event ID 300 - Windows Hello successfully created](hello-event-300.md)
-* [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md

@@ -10,13 +10,13 @@ ms.topic: article
 
 [!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cloudkerb-trust.md)]
 
-Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to successfully deploy Windows Hello for Business in a cloud Kerberos trust scenario.
+Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to successfully deploy Windows Hello for Business in a *cloud Kerberos trust* scenario.
 
 ## Introduction to cloud Kerberos trust
 
-The goal of **Windows Hello for Business cloud Kerberos trust** is to bring the simplified deployment experience of [*passwordless security key sign-in*][AZ-1] to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments.
+The goal of Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [*passwordless security key sign-in*][AZ-1] to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments.
 
-*Windows Hello for Business cloud Kerberos trust* uses **Azure AD Kerberos**, which enables a simpler deployment when compared to the *key trust model*:
+Windows Hello for Business cloud Kerberos trust uses *Azure AD Kerberos*, which enables a simpler deployment when compared to the *key trust model*:
 
 - No need to deploy a public key infrastructure (PKI) or to change an existing PKI
 - No need to synchronize public keys between Azure AD and Active Directory for users to access on-premises resources. This means that there isn't delay between the user's WHFB provisioning and being able to authenticate to Active Directory
@@ -146,7 +146,7 @@ You can configure the Enable Windows Hello for Business Group Policy setting for
 cloud Kerberos trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration.
 
 > [!NOTE]
-> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune][MEM-1] and [PassportForWork CSP][WIN-1]. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources).
+> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune][MEM-1] and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources).
 
 #### Update administrative templates
 
@@ -238,41 +238,20 @@ If you encounter issues or want to share feedback about Windows Hello for Busine
 
 ## Frequently Asked Questions
 
-### Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment?
+For a list of frequently asked questions about Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business Frequently Asked Questions](hello-faq.yml#cloud-kerberos-trust).
 
-This feature doesn't work in a pure on-premises AD domain services environment.
+<!--Links-->
-
-### Does Windows Hello for Business cloud Kerberos trust work in a Windows sign-in with RODC present in the hybrid environment?
-
-Windows Hello for Business cloud Kerberos trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud Kerberos trust will work.
-
-### Do I need line of sight to a domain controller to use Windows Hello for Business cloud Kerberos trust?
-
-Windows Hello for Business cloud Kerberos trust requires line of sight to a domain controller when:
-
-- a user signs-in for the first time or unlocks with Windows Hello for Business after provisioning. 
-- attempting to access on-premises resources secured by Active Directory. 
-
-### Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust?
-
-Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [remote credential guard][WIN-2] or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
-
-### Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust?
-
-No, only the number necessary to handle the load from all cloud Kerberos trust devices.
-
-<!--links-->
 
 [AZ-1]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises
 [AZ-2]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module
 [AZ-3]: /azure/active-directory/fundamentals/active-directory-how-to-find-tenant
 [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
 
-[SERV-1]: /windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services
-[TS-1]: /troubleshoot/windows-client/group-policy/create-and-manage-central-store
-
 [MEM-1]: /mem/intune/protect/identity-protection-windows-settings
-[WIN-1]: /windows/client-management/mdm/passportforwork-csp
+
-[WIN-2]: /windows/security/identity-protection/remote-credential-guard
+[SERV-1]: /windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services
+
 [SUP-1]: https://support.microsoft.com/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e
 [SUP-2]: https://support.microsoft.com/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f
+
+[TS-1]: /troubleshoot/windows-client/group-policy/create-and-manage-central-store

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

@@ -1,102 +0,0 @@
----
-title: How Windows Hello for Business works (Windows)
-description: Learn about registration, authentication, key material, and infrastructure for Windows Hello for Business.
-ms.date: 10/16/2017
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# How Windows Hello for Business works in Windows devices
-
-Windows Hello for Business requires a registered device. When the device is set up, its user can use the device to authenticate to services. This topic explains how device registration works, what happens when a user requests authentication, how key material is stored and processed, and which servers and infrastructure components are involved in different parts of this process.
-
-## Register a new user or device
-
-A goal of device registration is to allow a user to open a brand-new device, securely join an organizational network to download and manage organizational data, and create a new Windows Hello gesture to secure the device. Microsoft refers to the process of setting up a device for use with Windows Hello as registration.
- 
-> [!NOTE]
->This is separate from the organizational configuration required to use Windows Hello with Active Directory or Azure Active Directory (Azure AD); that configuration information is in [Manage Windows Hello for Business in your organization](../hello-manage-in-organization.md). Organizational configuration must be completed before users can begin to register.  
-
- The registration process works like this: 
- 
-1. The user configures an account on the device. This account can be a local account on the device, a domain account stored in the on-premises Active Directory domain, a Microsoft account, or an Azure AD account. For a new device, this step may be as simple as signing in with a Microsoft account. Signing in with a Microsoft account on a Windows 10 or Windows 11 device automatically sets up Windows Hello on the device; users don’t have to do anything extra to enable it. 
-2. To sign in using that account, the user has to enter the existing credentials for it. The identity provider (IDP) that “owns” the account receives the credentials and authenticates the user. This IDP authentication may include the use of an existing second authentication factor, or proof. For example, a user who registers a new device by using an Azure AD account will have to provide an SMS-based proof that Azure AD sends. 
-3. When the user has provided the proof to the IDP, the user enables PIN authentication. The PIN will be associated with this particular credential. When the user sets the PIN, it becomes usable immediately 
-
-The PIN chosen is associated with the combination of the active account and that specific device. The PIN must comply with whatever length and complexity policy the account administrator has configured; this policy is enforced on the device side. Other registration scenarios that Windows Hello supports are:
-
-- A user who upgrades from the Windows 8.1 operating system will sign in by using the existing enterprise password. That triggers a second authentication factor from the IDP side (if required); after receiving and returning a proof, such as a text message or voice code, the IDP authenticates the user to the upgraded Windows 10 device, and the user can set his or her PIN.
-- A user who typically uses a smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 or Windows 11 device the user has not previously signed in to.
-- A user who typically uses a virtual smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 and Windows 11 device the user has not previously signed in to.
-
-When the user has completed this process, Windows Hello generates a new public–private key pair on the device. The TPM generates and protects this private key; if the device doesn’t have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the protector key. It’s associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. Each unique gesture generates a unique protector key. The protector key securely wraps the authentication key. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
-
-At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means he or she is able to securely sign in to the device with the PIN and thus that he or she can establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using his or her PIN, and then registers the new biometric (“smile for the camera!”), after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures.
-
-## What’s a container?
-
-You’ll often hear the term *container* used in reference to mobile device management (MDM) solutions. Windows Hello uses the term, too, but in a slightly different way. Container in this context is shorthand for a logical grouping of key material or data. Windows 10 or Windows 11 Hello uses a single container that holds user key material for personal accounts, including key material associated with the user’s Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
-
-The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. 
-
-It’s important to keep in mind that there are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials Windows Hello stores are protected without the creation of actual containers or folders.
-
-The container actually contains a set of keys, some of which are used to protect other keys. The following image shows an example: the protector key is used to encrypt the authentication key, and the authentication key is used to encrypt the individual keys stored in the container.
- 
-![Each logical container holds one or more sets of keys.](../images/passport-fig3-logicalcontainer.png)
-
-Containers 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 previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be 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.
-- Virtual smart card keys are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked.
-- The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD 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 enterprises, the IDP keys can be generated in two ways:
-
-  - The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831498(v=ws.11)). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, 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 enterprise to store additional certificates in the protected container.
-  - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don’t have or need a PKI.
-
-## How keys are protected
-
-Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Work implementation takes advantage of onboard TPM hardware to generate and protect keys. However, Windows Hello and Windows Hello for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the device can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed.
-
-Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to reauthenticate to the IDP before the IDP allows him or her to re-register). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
-
-
-## Authentication
-
-When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
-
-These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Microsoft Store to require reauthentication anytime a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
-
-For example, the authentication process for Azure Active Directory works like this:
-
-1. The client sends an empty authentication request to the IDP. (This is merely for the handshake process.)
-2. The IDP returns a challenge, known as a nonce.
-3. The device signs the nonce with the appropriate private key.
-4. The device returns the original nonce, the signed nonce, and the ID of the key used to sign the nonce.
-5. The IDP fetches the public key that the key ID specified, uses it to verify the signature on the nonce, and verifies that the nonce the device returned matches the original.
-6. If all the checks in step 5 succeed, the IDP returns two data items: a symmetric key, which is encrypted with the device’s public key, and a security token, which is encrypted with the symmetric key.
-7. The device uses its private key to decrypt the symmetric key, and then uses that symmetric key to decrypt the token.
-8. The device makes a normal authentication request for the original resource, presenting the token from the IDP as its proof of authentication.
-
-When the IDP validates the signature, it is verifying that the request came from the specified user and device. The private key specific to the device signs the nonce, which allows the IDP to determine the identity of the requesting user and device so that it can apply policies for content access based on user, device type, or both together. For example, an IDP could allow access to one set of resources only from mobile devices and a different set from desktop devices.
-
-
-## The infrastructure
-
-Windows Hello depends on having compatible IDPs available to it. As of this writing, that means you have four deployment possibilities: 
-
-- Use an existing Windows-based PKI centered around Active Directory Certificate Services. This option requires additional infrastructure, including a way to issue certificates to users. You can use NDES to register devices directly, or Microsoft Intune where it’s available to manage mobile device participation in Windows Hello. 
-- The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Windows Hello IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 domain controllers required. 
-- Azure AD can act as an IDP either by itself or alongside an on-premises AD DS forest. Organizations that use Azure AD can register devices directly without having to join them to a local domain by using the capabilities the Azure AD Device Registration service provides. In addition to the IDP, Windows Hello requires an MDM system. This system can be the cloud-based Intune if you use Azure AD, or an on-premises Configuration Manager deployment that meets the system requirements described in the Deployment requirements section of this document.
-
-
-## Related topics
-
-- [Windows Hello for Business](../hello-identity-verification.md)
-- [Manage Windows Hello for Business in your organization](../hello-manage-in-organization.md)
-- [Why a PIN is better than a password](../hello-why-pin-is-better-than-password.md)
-- [Prepare people to use Windows Hello](../hello-prepare-people-to-use.md)
-- [Windows Hello and password changes](../hello-and-password-changes.md)
-- [Windows Hello errors during PIN creation](../hello-errors-during-pin-creation.md)
-- [Event ID 300 - Windows Hello successfully created](../hello-event-300.md)
-- [Windows Hello biometrics in the enterprise](../hello-biometrics-in-enterprise.md)

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

@@ -91,10 +91,10 @@
     href: hello-prepare-people-to-use.md
   - name: Manage Windows Hello for Business in your organization
     href: hello-manage-in-organization.md
+  - name: Windows Hello and password changes
+    href: hello-and-password-changes.md
 - name: Windows Hello for Business features
   items:
-  - name: Conditional access 
-    href: hello-feature-conditional-access.md
   - name: PIN Reset
     href: hello-feature-pin-reset.md
   - name: Dual Enrollment
@@ -111,10 +111,6 @@
     href: hello-deployment-issues.md
   - name: Errors during PIN creation
     href: hello-errors-during-pin-creation.md
-  - name: Event ID 300 - Windows Hello successfully created
-    href: hello-event-300.md
-  - name: Windows Hello and password changes
-    href: hello-and-password-changes.md
 - name: Reference
   items:
   - name: How Windows Hello for Business provisioning works

windows/security/threat-protection/windows-firewall/confirm-that-certificates-are-deployed-correctly.md

@@ -1,19 +1,12 @@
 ---
 title: Confirm That Certificates Are Deployed Correctly (Windows)
 description: Learn how to confirm that a Group Policy is being applied as expected and that the certificates are being properly installed on the workstations.
-ms.assetid: de0c8dfe-16b0-4d3b-8e8f-9282f6a65eee
-ms.reviewer: jekrynit
 ms.author: paoloma
 ms.prod: windows-client
-ms.mktglfcycl: deploy
-ms.sitesec: library
-ms.pagetype: securit
-ms.localizationpriority: medium
 author: paolomatarazzo
 manager: aaroncz
-audience: ITPro
 ms.topic: conceptual
-ms.date: 09/07/2021
+ms.date: 01/24/2023
 ms.technology: itpro-security
 appliesto: 
   - ✅ <b>Windows 10</b>
@@ -25,7 +18,6 @@ appliesto:
 
 # Confirm That Certificates Are Deployed Correctly
 
-
 After configuring your certificates and autoenrollment in Group Policy, you can confirm that the policy is being applied as expected, and that the certificates are being properly installed on the workstation devices.
 
 In these procedures, you refresh Group Policy on a client device, and then confirm that the certificate is deployed correctly.
@@ -37,23 +29,21 @@ To complete these procedures, you must be a member of the Domain Administrators
 In this topic:
 
 -   [Refresh Group Policy on a device](#to-refresh-group-policy-on-a-device)
-
 -   [Verify that a certificate is installed](#to-verify-that-a-certificate-is-installed)
 
 ## To refresh Group Policy on a device
 
  From an elevated command prompt, run the following command:
 
-``` syntax
+``` cmd
-gpupdate /target:computer /force
+gpupdate /target:computer /force
 ```
 
 After Group Policy is refreshed, you can see which GPOs are currently applied to the device.
 
 ## To verify that a certificate is installed
 
-1.  Open the Cerificates console.
+1.  Open the Certificates console
-
+1.  In the navigation pane, expand **Trusted Root Certification Authorities**, and then click **Certificates**
-2.  In the navigation pane, expand **Trusted Root Certification Authorities**, and then click **Certificates**.
 
     The CA that you created appears in the list.