Merging main into branch

Author: KennedyDMSFT

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

@@ -37,9 +37,6 @@ There are multiple scenarios that organizations can now enable using filter for
 
 Filter for devices is an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.
 
-> [!IMPORTANT]
-> Device state and filter for devices cannot be used together in Conditional Access policy.
-
 The following steps will help create two Conditional Access policies to support the first scenario under [Common scenarios](#common-scenarios). 
 
 Policy 1: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -194,7 +194,7 @@ When user risk is detected, administrators can employ the user risk policy condi
 When a user is prompted to change a password, they'll first be required to complete multifactor authentication. Make sure all users have registered for multifactor authentication, so they're prepared in case risk is detected for their account.  
 
 > [!WARNING]
-> Users must have previously registered for self-service password reset before triggering the user risk policy.
+> Users must have previously registered for multifactor authentication before triggering the user risk policy.
 
 The following restrictions apply when you configure a policy by using the password change control:  
 

articles/active-directory/conditional-access/concept-conditional-access-policies.md

@@ -83,10 +83,6 @@ The software the user is employing to access the cloud app. For example, 'Browse
 
 The behavior of the client apps condition was updated in August 2020. If you have existing Conditional Access policies, they'll remain unchanged. However, if you select on an existing policy, the configure toggle has been removed and the client apps the policy applies to are selected.
 
-#### Device state
-
-This control is used to exclude devices that are hybrid Azure AD joined, or marked a compliant in Intune. This exclusion can be done to block unmanaged devices. 
-
 #### Filter for devices
 
 This control allows targeting specific devices based on their attributes in a policy.

articles/active-directory/conditional-access/resilience-defaults.md

@@ -73,7 +73,7 @@ When resilience defaults are disabled, the Backup Authentication Service won't u
 
 ## Testing resilience defaults
 
-It isn't possible to conduct a dry run using the Backup Authentication Service or simulate the result of a policy with resilience defaults enabled or disabled at this time. Azure AD will conduct monthly exercises using the Backup Authentication Service. The sign-in logs will display if the Backup Authentication Service was used to issue the access token.
+It isn't possible to conduct a dry run using the Backup Authentication Service or simulate the result of a policy with resilience defaults enabled or disabled at this time. Azure AD will conduct monthly exercises using the Backup Authentication Service. The sign-in logs will display if the Backup Authentication Service was used to issue the access token. In **Azure portal** > **Monitoring** > **Sign-in Logs** blade, you can add the filter "Token issuer type == Azure AD Backup Auth" to display the logs processed by Azure AD Backup Authentication service. 
 
 ## Configuring resilience defaults
 

articles/active-directory/fundamentals/10-secure-local-guest.md

@@ -1,11 +1,11 @@
 ---
-title: Convert local guests into Azure AD B2B guest accounts
-description: Learn how to convert local guests into Azure AD B2B guest accounts 
+title: Convert local guest accounts to Azure AD B2B guest accounts
+description: Learn to convert local guests into Azure AD B2B guest accounts by identifying apps and local guest accounts, migration, and more. 
 services: active-directory 
 author: gargi-sinha
 ms.author: gasinh
 manager: martinco
-ms.date: 11/03/2022
+ms.date: 02/22/2023
 ms.topic: how-to
 ms.service: active-directory
 ms.subservice: enterprise-users
@@ -14,62 +14,52 @@ ms.custom: it-pro
 ms.collection: M365-identity-device-management
 ---
 
-# Convert local guests into Azure Active Directory B2B guest accounts
+# Convert local guest accounts to Azure Active Directory B2B guest accounts
 
-Azure Active Directory (Azure AD B2B) allows external users to collaborate using their own identities. However, it isn't uncommon for organizations to issue local usernames and passwords to external users. This approach isn't recommended as the bring-your-own-identity (BYOI) capabilities provided
-by Azure AD B2B to provide better security, lower cost, and reduce
-complexity when compared to local account creation. Learn more
-[here.](./secure-external-access-resources.md)
+With Azure Active Directory (Azure AD B2B), external users collaborate with their identities. Although organizations can issue local usernames and passwords to external users, this approach isn't recommended. Azure AD B2B has improved security, lower cost, and less complexity, compared to creating local accounts. In addition, if your organization issues local credentials that external users manage, you can use Azure AD B2B instead. Use the guidance in this document to make the transition.
 
-If your organization currently issues local credentials that external users have to manage and would like to migrate to using Azure AD B2B instead, this document provides a guide to make the transition as seamlessly as possible.
+Learn more: [Plan an Azure AD B2B collaboration deployment](secure-external-access-resources.md)
 
 ## Identify external-facing applications
 
-Before migrating local accounts to Azure AD B2B, admins should understand what applications and workloads these external users need to access. For example, if external users need access to an application that is hosted on-premises, admins will need to validate that the application is integrated with Azure AD and that a provisioning process is implemented to provision the user from Azure AD to the application.
-The existence and use of on-premises applications could be a reason why local accounts are created in the first place. Learn more about
-[provisioning B2B guests to on-premises
-applications.](../external-identities/hybrid-cloud-to-on-premises.md)
+Before migrating local accounts to Azure AD B2B, confirm the applications and workloads external users can access. For example, for applications hosted on-premises, validate the application is integrated with Azure AD. On-premises applications are a good reason to create local accounts. 
 
-All external-facing applications should have single-sign on (SSO) and provisioning integrated with Azure AD for the best end user experience.
+Learn more: [Grant B2B users in Azure AD access to your on-premises applications](../external-identities/hybrid-cloud-to-on-premises.md)
+
+We recommend that external-facing applications have single-sign on (SSO) and provisioning integrated with Azure AD for the best end user experience.
 
 ## Identify local guest accounts
 
-Admins will need to identify which accounts should be migrated to Azure AD B2B. External identities in Active Directory should be easily identifiable, which can be done with an attribute-value pair. For example, making ExtensionAttribute15 = `External` for all external users. If these users are being provisioned via Azure AD Connect or Cloud Sync, admins can optionally configure these synced external users
-to have the `UserType` attributes set to `Guest`. If these users are being
-provisioned as cloud-only accounts, admins can directly modify the
-users' attributes. What is most important is being able to identify the
-users who you want to convert to B2B.
+Identify the accounts to be migrated to Azure AD B2B. External identities in Active Directory are identifiable with an attribute-value pair. For example, making ExtensionAttribute15 = `External` for external users. If these users are set up with Azure AD Connect or Cloud Sync, configure synced external users to have the `UserType` attributes set to `Guest`. If the users are set up as cloud-only accounts, you can modify user attributes. Primarily, identify users to convert to B2B.
 
 ## Map local guest accounts to external identities
 
-Once you've identified which external user accounts you want to
-convert to Azure AD B2B, you need to identify the BYOI identities or external emails for each user. For example, admins will need to identify that the local account ([email protected]) is a user whose home identity/email address is [email protected]. How to identify the home identities is up to the organization, but some examples include:
-
-- Asking the external user's sponsor to provide the information.
-
-- Asking the external user to provide the information.
+Identify user identities or external emails. Confirm that the local account ([email protected]) is a user with the home identity and email address: [email protected]. To identify home identities:
 
-- Referring to an internal database if this information is already known and stored by the organization.
+- The external user's sponsor provides the information
+- The external user provides the information
+- Refer to an internal database, if the information is known and stored
 
-Once the mapping of each external local account to the BYOI identity is done, admins will need to add the external identity/email to the user.mail attribute on each local account.
+After mapping external local accounts to identities, add external identities or email to the user.mail attribute on local accounts.
 
 ## End user communications
 
-External users should be notified that the migration will be taking place and when it will happen. Ensure you communicate the expectation that external users will stop using their existing password and post-migration will authenticate with their own home/corporate credentials going forward. Communications can include email campaigns, posters, and announcements.
+Notify external users about migration timing. Communicate expectations, such as when external users must stop using a current password to enable authenticate by home and corporate credentials. Communications can include email campaigns and announcements.
 
 ## Migrate local guest accounts to Azure AD B2B
 
-Once the local accounts have their user.mail attributes populated with the external identity/email that they're mapped to, admins can [convert the local accounts to Azure AD B2B by inviting the local account.](../external-identities/invite-internal-users.md)
-This can be done in the UX or programmatically via PowerShell or the Microsoft Graph API. Once complete, the users will no longer
-authenticate with their local password, but will instead authenticate with their home identity/email that was populated in the user.mail attribute. You've successfully migrated to Azure AD B2B.
+After local accounts have user.mail attributes populated with the external identity and email, convert local accounts to Azure AD B2B by inviting the local account. You can use PowerShell or the Microsoft Graph API.
 
-## Post-migration considerations
+Learn more: [Invite internal users to B2B collaboration](../external-identities/invite-internal-users.md)
 
-If local accounts for external users were being synced from on-premises, admins should take steps to reduce their on-premises footprint and use cloud-native B2B guest accounts moving forward. Some possible actions can include:
+## Post-migration considerations
 
-- Transition existing local accounts for external users to Azure AD B2B and stop creating local accounts. Post-migration, admins should invite external users natively in Azure AD.
+If external user local accounts were synced from on-premises, reduce their on-premises footprint and use B2B guest accounts. You can:
 
-- Randomize the passwords of existing local accounts for external users to ensure they can't authenticate locally to on-premises resources. This will increase security by ensuring that authentication and user lifecycle is tied to the external user's home identity.
+- Transition external user local accounts to Azure AD B2B and stop creating local accounts
+  - Invite external users in Azure AD
+- Randomize external user's local-account passwords to prevent authentication to on-premises resources 
+  - This action ensures authentication and user lifecycle is connected to the external user home identity
 
 ## Next steps
 
@@ -84,4 +74,4 @@ See the following articles on securing external access to resources. We recommen
 1. [Secure access with Conditional Access policies](7-secure-access-conditional-access.md) 
 1. [Secure access with Sensitivity labels](8-secure-access-sensitivity-labels.md)
 1. [Secure access to Microsoft Teams, OneDrive, and SharePoint](9-secure-access-teams-sharepoint.md)
-1. [Convert local guest accounts to B2B](10-secure-local-guest.md) (You’re here)
+1. [Convert local guest accounts to B2B](10-secure-local-guest.md) (You’re here)

articles/active-directory/identity-protection/howto-identity-protection-configure-notifications.md

@@ -24,7 +24,8 @@ Azure AD Identity Protection sends two types of automated notification emails to
 
 This article provides you with an overview of both notification emails.
 
-We don't support sending emails to users in group-assigned roles.
+   > [!Note]
+   > **We don't support sending emails to users in group-assigned roles.**
 
 ## Users at risk detected email
 

articles/active-directory/identity-protection/howto-identity-protection-configure-risk-policies.md

@@ -34,23 +34,23 @@ Configured trusted [network locations](../conditional-access/location-condition.
 
 ### Risk remediation
 
-Organizations can choose to block access when risk is detected. Blocking sometimes stops legitimate users from doing what they need to. A better solution is to allow self-remediation using Azure AD multifactor authentication (MFA) and secure self-service password reset (SSPR).
+Organizations can choose to block access when risk is detected. Blocking sometimes stops legitimate users from doing what they need to. A better solution is to allow self-remediation using Azure AD multifactor authentication (MFA) and secure password change.
 
 > [!WARNING]
-> Users must register for Azure AD MFA and SSPR before they face a situation requiring remediation. Users not registered are blocked and require administrator intervention.
+> Users must register for Azure AD MFA before they face a situation requiring remediation. For hybrid users that are synced from on-premises to cloud, password writeback must have been enabled on them. Users not registered are blocked and require administrator intervention.
 > 
-> Password change (I know my password and want to change it to something new) outside of the risky user policy remediation flow does not meet the requirement for secure password reset.
+> Password change (I know my password and want to change it to something new) outside of the risky user policy remediation flow does not meet the requirement for secure password change.
 
 ### Microsoft's recommendation
 
 Microsoft recommends the below risk policy configurations to protect your organization:
 
 - User risk policy
-   - Require a secure password reset when user risk level is **High**. Azure AD MFA is required before the user can create a new password with SSPR to remediate their risk. 
+   - Require a secure password change when user risk level is **High**. Azure AD MFA is required before the user can create a new password with password writeback to remediate their risk. 
 - Sign-in risk policy
    - Require Azure AD MFA when sign-in risk level is **Medium** or **High**, allowing users to prove it's them by using one of their registered authentication methods, remediating the sign-in risk. 
 
-Requiring access control when risk level is low will introduce more user interrupts. Choosing to block access rather than allowing self-remediation options, like secure password reset and multifactor authentication, will impact your users and administrators. Weigh these choices when configuring your policies.
+Requiring access control when risk level is low will introduce more user interrupts. Choosing to block access rather than allowing self-remediation options, like secure password change and multifactor authentication, will impact your users and administrators. Weigh these choices when configuring your policies.
 
 ## Exclusions
 

articles/active-directory/manage-apps/grant-admin-consent.md

@@ -73,13 +73,13 @@ When granting tenant-wide admin consent using either method described above, a w
 The tenant-wide admin consent URL follows the following format:
 
 ```http
-https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}
+https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}
 ```
 
 where:
 
 - `{client-id}` is the application's client ID (also known as app ID).
-- `{tenant-id}` is your organization's tenant ID or any verified domain name.
+- `{organization}` is the tenant ID or any verified domain name of the tenant you want to consent the application in. You can use the value `common`, which will cause the consent to happen in the home tenant of the user you sign in with.
 
 As always, carefully review the permissions an application requests before granting consent.