[BULK] - DocuTune - Rebranding of Azure Active Dir

windows/security/identity-protection/hello-for-business/hello-planning-guide.md

@@ -52,9 +52,9 @@ The cloud only deployment model is for organizations who only have cloud identit
 
 The hybrid deployment model is for organizations that: 
 
-- Are federated with Azure Active Directory
-- Have identities synchronized to Azure Active Directory using Azure Active Directory Connect
-- Use applications hosted in Azure Active Directory, and want a single sign-in user experience for both on-premises and Azure Active Directory resources
+- Are federated with Microsoft Entra ID
+- Have identities synchronized to Microsoft Entra ID using Microsoft Entra Connect
+- Use applications hosted in Microsoft Entra ID, and want a single sign-in user experience for both on-premises and Microsoft Entra resources
 
 > [!Important]
 > Hybrid deployments support non-destructive PIN reset that works with both the certificate trust and key trust models.
@@ -64,7 +64,7 @@ The hybrid deployment model is for organizations that:
 > - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
 
 ##### On-premises
-The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Azure Active Directory.
+The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Microsoft Entra ID.
 
 > [!Important]
 > On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
@@ -81,7 +81,7 @@ It's fundamentally important to understand which deployment model to use for a s
 A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory.  There are two trust types: key trust and certificate trust.
 
 > [!NOTE]
-> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business 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). For more information, see [Hybrid Cloud Kerberos Trust Deployment](hello-hybrid-cloud-kerberos-trust.md).
+> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Microsoft Entra hybrid joined devices and on-premises resource access on Microsoft Entra joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). For more information, see [Hybrid Cloud Kerberos Trust Deployment](hello-hybrid-cloud-kerberos-trust.md).
 
 The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
 
@@ -92,33 +92,33 @@ The certificate trust type issues authentication certificates to end users.  Use
 
 #### Device registration
 
-All devices included in the Windows Hello for Business deployment must go through device registration.  Device registration enables devices to authenticate to identity providers.  For cloud only and hybrid deployment, the identity provider is Azure Active Directory.  For on-premises deployments, the identity provider is the on-premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
+All devices included in the Windows Hello for Business deployment must go through device registration.  Device registration enables devices to authenticate to identity providers.  For cloud only and hybrid deployment, the identity provider is Microsoft Entra ID.  For on-premises deployments, the identity provider is the on-premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
 
 #### Key registration
 
-The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key).  The provisioning experience registers the user's public key with the identity provider.  For cloud only and hybrid deployments, the identity provider is Azure Active Directory.  For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
+The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key).  The provisioning experience registers the user's public key with the identity provider.  For cloud only and hybrid deployments, the identity provider is Microsoft Entra ID.  For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
 
 #### Multifactor authentication
 
 > [!IMPORTANT]
-> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multi-factor authentication for their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure AD Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
+> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multifactor authentication for their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
 
 The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication.  The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.  
 
-Cloud only and hybrid deployments provide many choices for multi-factor authentication.  On-premises deployments must use a multi-factor authentication that provides an AD FS multi-factor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure AD Multi-Factor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
+Cloud only and hybrid deployments provide many choices for multifactor authentication.  On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-Factor Authentication Server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
 > [!NOTE]
-> Azure AD Multi-Factor Authentication is available through:
+> Microsoft Entra multifactor authentication is available through:
 > * Microsoft Enterprise Agreement
 > * Open Volume License Program
 > * Cloud Solution Providers program
 > * Bundled with
->    * Azure Active Directory Premium
+>    * Microsoft Entra ID P1 or P2
 >    * Enterprise Mobility Suite
 >    * Enterprise Cloud Suite
 
 #### Directory synchronization
 
-Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose.  Hybrid deployments use Azure Active Directory Connect to synchronize Active Directory identities or credentials between itself and Azure Active Directory. This helps enable single sign-on to Azure Active Directory and its federated components. On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
+Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose.  Hybrid deployments use Microsoft Entra Connect to synchronize Active Directory identities or credentials between itself and Microsoft Entra ID. This helps enable single sign-on to Microsoft Entra ID and its federated components. On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
 
 ### Management
 
@@ -149,7 +149,7 @@ The Windows Hello for Business deployment depends on an enterprise public key in
 
 ### Cloud
 
-Some deployment combinations require an Azure account, and some require Azure Active Directory for user identities.  These cloud requirements may only need an Azure account while other features need an Azure Active Directory Premium subscription. The planning process identifies and differentiates the components that are needed from those that are optional.
+Some deployment combinations require an Azure account, and some require Microsoft Entra ID for user identities.  These cloud requirements may only need an Azure account while other features need a Microsoft Entra ID P1 or P2 subscription. The planning process identifies and differentiates the components that are needed from those that are optional.
 
 ## Planning a Deployment
 
@@ -173,13 +173,13 @@ If your organization does not have cloud resources, write **On-Premises** in box
 
 ### Trust type
 
-Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates.  Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
+Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates.  Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
 
 Choose a trust type that is best suited for your organizations.  Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
 
 One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).  
 
-Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision.  Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority.  In a federated environment, you need to activate the Device Writeback option in Azure AD Connect.
+Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision.  Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority.  In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
 
 If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
 
@@ -203,17 +203,17 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
 
 ### Directory Synchronization
 
-Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair).  Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multi-factor authentication during provisioning or writing the user's public key.
+Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair).  Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
 
-If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**.  User information is written directly to Azure Active Directory and there is not another directory with which the information must be synchronized.
+If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**.  User information is written directly to Microsoft Entra ID and there is not another directory with which the information must be synchronized.
 
-If box **1a** on your planning worksheet reads **hybrid**, then write **Azure AD Connect** in box **1e** on your planning worksheet.
+If box **1a** on your planning worksheet reads **hybrid**, then write **Microsoft Entra Connect** in box **1e** on your planning worksheet.
 
-If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**.  This deployment exclusively uses Active Directory for user information with the exception of the multi-factor authentication.  The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multi-factor authentication while the user's credentials remain on the on-premises network.
+If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**.  This deployment exclusively uses Active Directory for user information with the exception of the multifactor authentication.  The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multifactor authentication while the user's credentials remain on the on-premises network.
 
-### Multifactor Authentication
+### Multifactor authentication
 
-The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication.  Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business.  To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multi-factor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
+The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication.  Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business.  To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
 
 If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service.  Write **Azure MFA** in box **1f** on your planning worksheet.
 
@@ -225,7 +225,7 @@ If box **1a** on your planning worksheet reads **hybrid**, then you have a few o
 
 You can directly use the Azure MFA cloud service for the second factor of authentication. Users contacting the service must authenticate to Azure prior to using the service.
 
-If your Azure AD Connect is configured to synchronize identities (usernames only), then your users are redirected to your local on-premises federation server for authentication and then redirected back to the Azure MFA cloud service.  Otherwise, your Azure AD Connect is configured to synchronize credentials (username and passwords), which enables your users to authenticate to Azure Active Directory and use the Azure MFA cloud service.  If you choose to use the Azure MFA cloud service directly, write **Azure MFA** in box **1f** on your planning worksheet.
+If your Microsoft Entra Connect is configured to synchronize identities (usernames only), then your users are redirected to your local on-premises federation server for authentication and then redirected back to the Azure MFA cloud service.  Otherwise, your Microsoft Entra Connect is configured to synchronize credentials (username and passwords), which enables your users to authenticate to Microsoft Entra ID and use the Azure MFA cloud service.  If you choose to use the Azure MFA cloud service directly, write **Azure MFA** in box **1f** on your planning worksheet.
 
 You can configure your on-premises Windows Server 2016 AD FS role to use the Azure MFA service adapter. In this configuration, users are redirected to the on premises AD FS server (synchronizing identities only). The AD FS server uses the MFA adapter to communicate to the Azure MFA service to perform the second factor of authentication.  If you choose to use AD FS with the Azure MFA cloud service adapter, write **AD FS with Azure MFA cloud adapter** in box **1f** on your planning worksheet.
 
@@ -241,10 +241,10 @@ If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with
 
 Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users.  The type of policy management you can use depends on your selected deployment and trust models.
 
-If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet.  You have the option to manage non-domain joined devices.  If you choose to manage Azure Active Directory-joined devices, write **modern management** in box **2b** on your planning worksheet.  Otherwise, write** N/A** in box **2b**.
+If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet.  You have the option to manage non-domain joined devices.  If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet.  Otherwise, write** N/A** in box **2b**.
 
 > [!NOTE]
-> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings.  Use modern management to adjust policy settings to match the business needs of your organization.
+> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings.  Use modern management to adjust policy settings to match the business needs of your organization.
 
 If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
 
@@ -260,7 +260,7 @@ Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11.
 
 If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet.  Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
 > [!NOTE]
-> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings.  Use modern management to adjust policy settings to match the business needs of your organization.
+> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings.  Use modern management to adjust policy settings to match the business needs of your organization.
 
 Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true. 
 * Box **2a** on your planning worksheet read **modern management**. 
@@ -288,7 +288,7 @@ If box **1a** on your planning worksheet reads **cloud only**, ignore the public
 
 If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
 
-The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices.  Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates.  Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates. 
+The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices.  Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates.  Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates. 
 
 If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet.  In box **5c**, write the following certificate templates names and issuances:
 
@@ -323,15 +323,15 @@ If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, wri
 
 If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments do not use the cloud directory.
 
-Windows Hello for Business does not require an Azure AD premium subscription.  However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
+Windows Hello for Business does not require a Microsoft Entra ID P1 or P2 subscription.  However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
 
 If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
 
-If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the Azure Active Directory free tier. All Azure Active Directory free accounts can use Azure AD Multi-Factor Authentication through the use of security defaults. Some Azure AD Multi-Factor Authentication features require a license. For more details, see [Features and licenses for Azure AD Multi-Factor Authentication](/azure/active-directory/authentication/concept-mfa-licensing).
+If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the Microsoft Entra ID Free tier. All Microsoft Entra ID Free accounts can use Microsoft Entra multifactor authentication through the use of security defaults. Some Microsoft Entra multifactor authentication features require a license. For more details, see [Features and licenses for Microsoft Entra multifactor authentication](/azure/active-directory/authentication/concept-mfa-licensing).
 
-If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet.  Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, an Azure AD Premium feature.
+If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet.  Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature.
 
-Modern managed devices do not require an Azure AD premium subscription.  By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
+Modern managed devices do not require a Microsoft Entra ID P1 or P2 subscription.  By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
 
 If boxes **2a** or **2b** read **modern management** and you want devices to automatically enroll in your modern management software, write **Yes** in box **6c** on your planning worksheet.  Otherwise, write **No** in box **6c**.
 

windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md

@@ -10,7 +10,7 @@ When you set a policy to require Windows Hello for Business in the workplace, yo
 
 After enrollment in Hello, users should use their gesture (such as a PIN or fingerprint) for access to corporate resources. Their gesture is only valid on the enrolled device.
 
-Although the organization may require users to change their Active Directory or Azure Active Directory (AD) account password at regular intervals, changes to their passwords have no effect on Hello.
+Although the organization may require users to change their Active Directory or Microsoft Entra account password at regular intervals, changes to their passwords have no effect on Hello.
 
 People who are currently using virtual or physical smart cards for authentication can use their virtual smart card to verify their identity when they set up Hello.
 
@@ -52,4 +52,3 @@ If your policy allows it, people can use biometrics (fingerprint, iris, and faci
 - [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
 - [Event ID 300 - Windows Hello successfully created](/windows/security/identity-protection/hello-for-business/hello-faq)
 - [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
-

windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md

@@ -3,4 +3,4 @@ ms.date: 12/08/2022
 ms.topic: include
 ---
 
-[cloud :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM")
+[cloud :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-deployment "For organizations using Microsoft Entra-only identities. Device management is usually done via Intune/MDM")

windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md

@@ -3,4 +3,4 @@ ms.date: 12/08/2022
 ms.topic: include
 ---
 
-[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
+[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Microsoft Entra ID. Device management is usually done via Group Policy or Intune/MDM")

windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md

@@ -3,4 +3,4 @@ ms.date: 12/08/2022
 ms.topic: include
 ---
 
-[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
+[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Microsoft Entra ID. Device management is usually done via Group Policy")

windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md

@@ -3,4 +3,4 @@ ms.date: 12/08/2022
 ms.topic: include
 ---
 
-[Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Azure AD joined do not have any dependencies on Active Directory. Only local users accounts and Azure AD users can sign in to these devices")
+[Microsoft Entra join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Microsoft Entra joined do not have any dependencies on Active Directory. Only local users accounts and Microsoft Entra users can sign in to these devices")

windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md

@@ -3,4 +3,4 @@ ms.date: 12/08/2022
 ms.topic: include
 ---
 
-[hybrid Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
+[Microsoft Entra hybrid join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are Microsoft Entra hybrid joined don't have any dependencies on Microsoft Entra ID. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Microsoft Entra ID will have single-sign on to both Active Directory and Microsoft Entra protected resources")

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

@@ -25,7 +25,7 @@ Windows Hello lets users authenticate to:
 
 - A Microsoft account.
 - An Active Directory account.
-- A Microsoft Azure Active Directory (Azure AD) account.
+- A Microsoft Entra account.
 - Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication.
 
 After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.
@@ -71,7 +71,7 @@ Windows Hello helps protect user identities and user credentials. Because the us
 
 - Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
 
-- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Azure AD, or a Microsoft account.
+- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Microsoft Entra ID, or a Microsoft account.
 
 - Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy.
 
@@ -81,7 +81,7 @@ Windows Hello helps protect user identities and user credentials. Because the us
 
 - PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
 
-- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
+- Personal (Microsoft account) and corporate (Active Directory or Microsoft Entra ID) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
 
 - Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture.
 
@@ -89,7 +89,7 @@ For details, see [How Windows Hello for Business works](hello-how-it-works.md).
 
 ## Comparing key-based and certificate-based authentication
 
-Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Azure AD as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
+Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Microsoft Entra ID as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
 
 Windows Hello for Business with a key, including cloud Kerberos trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Remote Credential Guard](../remote-credential-guard.md).
 

windows/security/identity-protection/hello-for-business/passwordless-strategy.md

@@ -17,7 +17,7 @@ Over the past few years, Microsoft has continued their commitment to enabling a
 
 ### 1. Develop a password replacement offering
 
-Before you move away from passwords, you need something to replace them. With Windows 10 and Windows 11, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single sign-on to Azure Active Directory and Active Directory.
+Before you move away from passwords, you need something to replace them. With Windows 10 and Windows 11, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single sign-on to Microsoft Entra ID and Active Directory.
 
 Deploying Windows Hello for Business is the first step towards a password-less environment. Windows Hello for Business coexists nicely with existing password-based security. Users are likely to use Windows Hello for Business because of its convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative and getting users used to it.
 
@@ -147,7 +147,7 @@ After successfully moving a work persona to password freedom, you can prioritize
 
 ### Password-less replacement offering (step 1)
 
-The first step to password freedom is providing an alternative to passwords. Windows 10 and Windows 11 provide an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Azure Active Directory and Active Directory.
+The first step to password freedom is providing an alternative to passwords. Windows 10 and Windows 11 provide an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Microsoft Entra ID and Active Directory.
 
 #### Identify test users that represent the targeted work persona
 
@@ -160,7 +160,7 @@ Next, you'll want to plan your Windows Hello for Business deployment. Your test
 With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you'll only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You'll use the first work persona to validate your Windows Hello for Business deployment.
 
 > [!NOTE]
-> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Azure Active Directory. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices.
+> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Microsoft Entra ID. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices.
 
 #### Validate that passwords and Windows Hello for Business work
 
@@ -206,7 +206,7 @@ Start mitigating password usages based on the workflows of your targeted persona
 
 Mitigating password usage with applications is one of the more challenging obstacles in the password-less journey. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS).
 
-The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Azure Active Directory or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
+The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
 
 Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to use federated identities or Windows integrated authentication. Work with third-party software vendors to update their software to support federated identities or Windows integrated authentication.
 

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

@@ -41,7 +41,7 @@ items:
       - name: Configure and provision Windows Hello for Business
         href: hello-hybrid-key-trust-provision.md
         displayName: key trust
-      - name: Configure SSO for Azure AD joined devices
+      - name: Configure SSO for Microsoft Entra joined devices
         href: hello-hybrid-aadj-sso.md
         displayName: key trust
     - name: Certificate trust deployment
@@ -58,10 +58,10 @@ items:
       - name: Configure and provision Windows Hello for Business
         href: hello-hybrid-cert-whfb-provision.md
         displayName: certificate trust
-      - name: Configure SSO for Azure AD joined devices
+      - name: Configure SSO for Microsoft Entra joined devices
         href: hello-hybrid-aadj-sso.md
         displayName: certificate trust
-      - name: Deploy certificates to Azure AD joined devices
+      - name: Deploy certificates to Microsoft Entra joined devices
         href: hello-hybrid-aadj-sso-cert.md
         displayName: certificate trust
   - name: On-premises deployments

windows/security/identity-protection/passwordless-experience/index.md

@@ -24,7 +24,7 @@ With Windows passwordless experience, users who sign in with Windows Hello or a
   >[!NOTE]
   >Users can reset their password using <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>DEL</kbd> > **Manage your account**
 
-Windows passwordless experience doesn't affect the initial sign-in experience and local accounts. It only applies to subsequent sign-ins for Microsoft Entra ID accounts. It also doesn't prevent a user from signing in with a password when using the *Other user* option in the lock screen.\
+Windows passwordless experience doesn't affect the initial sign-in experience and local accounts. It only applies to subsequent sign-ins for Microsoft Entra accounts. It also doesn't prevent a user from signing in with a password when using the *Other user* option in the lock screen.\
 The password credential provider is hidden only for the last signed in user who signed in Windows Hello or a FIDO2 security key. Windows passwordless experience isn't about preventing users from using passwords, rather to guide and educate them to not use passwords.
 
 This article explains how to enable Windows passwordless experience and describes the user experiences.
@@ -122,7 +122,7 @@ Here's a list of recommendations to consider before enabling Windows passwordles
 - If Windows Hello for Business is enabled, configure the [PIN reset](../hello-for-business/hello-feature-pin-reset.md) feature to allow users to reset their PIN from the lock screen. The PIN reset experience is improved starting in Windows 11, version 22H2 with [KB5030310][KB-1]
 - Don't configure the security policy *Interactive logon: Don't display last signed-in*, as it prevents Windows passwordless experience from working
 - Don't disable the password credential provider using the *Exclude credential providers* policy. The key differences between the two policies are:
-  - The Exclude credential providers policy disables passwords for *all accounts*, including local accounts. Windows passwordless experience only applies to Microsoft Entra ID accounts that sign in with Windows Hello or a FIDO2 security key. It also excludes *Other User* from the policy, so users have a backup sign in option
+  - The Exclude credential providers policy disables passwords for *all accounts*, including local accounts. Windows passwordless experience only applies to Microsoft Entra accounts that sign in with Windows Hello or a FIDO2 security key. It also excludes *Other User* from the policy, so users have a backup sign in option
   - Exclude credential providers policy prevents the use of passwords for RDP and *Run as* authentication scenarios
 - To facilitate helpdesk support operations, consider enabling the local administrator account or create a separate one, randomizing its password using the [Windows Local Administrator Password Solution (LAPS)][SERV-1]
 

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

@@ -211,8 +211,8 @@ For more information about LAPS, see [What is Windows LAPS][LEARN-1].
 Here are some additional considerations for Remote Credential Guard:
 
 - Remote Credential Guard doesn't support compound authentication. For example, if you're trying to access a file server from a remote host that requires a device claim, access will be denied
-- Remote Credential Guard can be used only when connecting to a device that is joined to an Active Directory domain. It can't be used when connecting to remote devices joined to Azure Active Directory (Azure AD)
-- Remote Credential Guard can be used from an Azure AD joined client to connect to an Active Directory joined remote host, as long as the client can authenticate using Kerberos
+- Remote Credential Guard can be used only when connecting to a device that is joined to an Active Directory domain. It can't be used when connecting to remote devices joined to Microsoft Entra ID
+- Remote Credential Guard can be used from a Microsoft Entra joined client to connect to an Active Directory joined remote host, as long as the client can authenticate using Kerberos
 - Remote Credential Guard only works with the RDP protocol
 - No credentials are sent to the target device, but the target device still acquires Kerberos Service Tickets on its own
 - The server and client must authenticate using Kerberos

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

@@ -128,7 +128,7 @@ For more information, see [Use a Temporary Access Pass][AAD-3].
 
 :::row:::
   :::column span="3":::
-  If the Microsoft Entra ID tenant is federated with a third-party SAML-P identity provider (IdP), federated users can sign using the Web sign-in credential provider.
+  If the Microsoft Entra tenant is federated with a third-party SAML-P identity provider (IdP), federated users can sign using the Web sign-in credential provider.
   :::column-end:::
   :::column span="1":::
   :::image type="content" source="images/web-sign-in-federated-auth.png" border="false" lightbox="images/web-sign-in-federated-auth.gif" alt-text="Animation of the sign in experience with a federated user.":::
@@ -138,7 +138,7 @@ For more information, see [Use a Temporary Access Pass][AAD-3].
 > [!TIP]
 > To improve the user experience for federated identities:
 >
-> - Configure the *preferred Azure AD tenant name* feature, which allows users to select the domain name during the sign-in process. The users are then automatically redirected to the identity provider sign-in page.
+> - Configure the *preferred Microsoft Entra tenant name* feature, which allows users to select the domain name during the sign-in process. The users are then automatically redirected to the identity provider sign-in page.
 > - Enable Windows Hello for Business. Once the user signs in, the user can enroll in Windows Hello for Business and then use it to sign in to the device
 
 For more information about preferred tenant name, see [Authentication CSP - PreferredAadTenantDomainName][WIN-1].