merge conflict

Author: v-thepet

appgw-waf-metrics-1-expanded.png

@@ -1,17 +1,17 @@
 ---
-title: Use additional context in multifactor authentication (MFA) notifications (Preview) - Azure Active Directory
+title: Use additional context in Microsoft Authenticator notifications (Preview) - Azure Active Directory
 description: Learn how to use additional context in MFA notifications
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 02/11/2022
+ms.date: 03/18/2022
 ms.author: justinha
 author: mjsantani
 ms.collection: M365-identity-device-management
 
 # Customer intent: As an identity administrator, I want to encourage users to use the Microsoft Authenticator app in Azure AD to improve and secure user sign-in events.
 ---
-# How to use additional context in multifactor authentication (MFA) notifications (Preview) - Authentication Methods Policy
+# How to use additional context in Microsoft Authenticator notifications (Preview) - Authentication Methods Policy
 
 This topic covers how to improve the security of user sign-in by adding application location based on IP address in Microsoft Authenticator push notifications.  
 
@@ -34,6 +34,9 @@ The additional context can be combined with [number matching](how-to-mfa-number-
 
 ### Policy schema changes 
 
+>[!NOTE]
+>In Graph Explorer, ensure you've consented to the **Policy.Read.All** and **Policy.ReadWrite.AuthenticationMethod** permissions. 
+
 Identify a single target group for the schema configuration. Then use the following API endpoint to change the displayAppInformationRequiredState property to **enabled**:
 
 https://graph.microsoft.com/beta/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator

appgw-waf-metrics-2-expanded.png

@@ -4,7 +4,7 @@ description: Learn how to use number matching in MFA notifications
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 02/28/2022
+ms.date: 03/18/2022
 ms.author: justinha
 author: mjsantani
 ms.collection: M365-identity-device-management
@@ -38,7 +38,7 @@ Number matching is available for the following scenarios. When enabled, all scen
 - [NPS extension](howto-mfa-nps-extension.md)
 
 >[!NOTE]
->For passwordless users, enabling number matching has no impact because it's already part of the passwordless experience. 
+>For passwordless users, enabling or disabling number matching has no impact because it's already part of the passwordless experience. 
 
 ### Multifactor authentication
 
@@ -126,7 +126,7 @@ You will need to change the **numberMatchingRequiredState** from **default** to
 Note that the value of Authentication Mode can be either **any** or **push**, depending on whether or not you also want to enable passwordless phone sign-in. In these examples, we will use **any**, but if you do not want to allow passwordless, use **push**. 
 
 >[!NOTE]
->For passwordless users, enabling number matching has no impact because it's already part of the passwordless experience. 
+>For passwordless users, enabling or disabling number matching has no impact because it's already part of the passwordless experience. 
 
 You might need to patch the entire includeTarget to prevent overwriting any previous configuration. In that case, do a GET first, update only the relevant fields, and then PATCH. The following example only shows the update to the **numberMatchingRequiredState**. 
 

appgw-waf-metrics-2.png

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 07/17/2020
+ms.date: 03/18/2022
 
 ms.author: justinha
 author: justinha
@@ -66,7 +66,7 @@ To configure a Windows 10 device for SSPR at the sign-in screen, review the foll
     - Not unique to using SSPR from the Windows sign-in screen, all users must provide the authentication contact information before they can reset their password.
 - Network proxy requirements:
     - Port 443 to `passwordreset.microsoftonline.com` and `ajax.aspnetcdn.com`
-    - Windows 10 devices only support machine-level proxy configuration.
+    - Windows 10 devices require a machine-level proxy configuration or scoped proxy configuration for the temporary defaultuser1 account used to perform SSPR (see [Troubleshooting](#proxy-configurations-for-windows-password-reset) section for more details).
 - Run at least Windows 10, version April 2018 Update (v1803), and the devices must be either:
     - Azure AD joined
     - Hybrid Azure AD joined
@@ -112,7 +112,7 @@ To enable SSPR at the sign-in screen using a registry key, complete the followin
        "AllowPasswordReset"=dword:00000001
     ```
 
-#### Troubleshooting Windows 10 password reset
+### Troubleshooting Windows 10 password reset
 
 If you have problems with using SSPR from the Windows sign-in screen, the Azure AD audit log includes information about the IP address and *ClientType* where the password reset occurred, as shown in the following example output:
 
@@ -122,6 +122,25 @@ When users reset their password from the sign-in screen of a Windows 10 device,
 
 The account itself has a randomly generated password, which is validated against an organizations password policy, doesn't show up for device sign-in, and is automatically removed after the user resets their password. Multiple `defaultuser` profiles may exist but can be safely ignored.
 
+#### Proxy configurations for Windows password reset
+
+During the password reset, SSPR creates a temporary local user account to connect to `https://passwordreset.microsoftonline.com/n/passwordreset`. When a proxy is configured for user authentication, it may fail with the error **"Something went wrong. Please, try again later."** This is because the local user account is not authorized to use the authenticated proxy. 
+
+In this case, you can use one of the following workarounds:
+
+- Configure a machine-wide proxy setting that doesn't depend on the type of user logged into the machine. For example, you can enable the Group Policy **Make proxy settings per-machine (rather than per-user)** for the workstations.
+- You can also use Per-User proxy configuration for SSPR if you modify the registry template for the Default Account. The commands are as follows:
+    
+    ```cmd
+    reg load "hku\Default" "C:\Users\Default\NTUSER.DAT"
+    reg add "hku\Default\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d "1" /f
+    reg add "hku\Default\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer /t REG_SZ /d "<your proxy:port>" /f
+    reg unload "hku\Default"
+    ```
+
+- The error **"Something went wrong"** can also occur when anything interrupts connectivity to URL `https://passwordreset.microsoftonline.com/n/passwordreset`. For example, this error can occur when antivirus software runs on the workstation without exclusions for URLs `passwordreset.microsoftonline.com`, `ajax.aspnetcdn.com`, and `ocsp.digicert.com`. Disable this software temporarily to test if the issue is resolved or not.
+
+
 ## Windows 7, 8, and 8.1 password reset
 
 To configure a Windows 7, 8, or 8.1 device for SSPR at the sign-in screen, review the following prerequisites and configuration steps.

articles/active-directory/authentication/how-to-mfa-additional-context.md

@@ -233,6 +233,9 @@ One of these error messages are displayed: "A verified publisher can’t be adde
 
 First, verify you've met the [publisher verification requirements](publisher-verification-overview.md#requirements).
 
+> [!NOTE]
+> If you've met the publisher verification requirements and are still having issues, try using an existing or newly created user with similar permissions.
+
 When a request to add a verified publisher is made, many signals are used to make a security risk assessment. If the request is determined to be risky an error will be returned. For security reasons, Microsoft doesn't disclose the specific criteria used to determine whether a request is risky or not. If you received this error and believe the "risky" assessment is incorrect, try waiting and resubmitting the verification request. Some customers have reported success after multiple attempts.
 
 ## Next steps

articles/active-directory/authentication/how-to-mfa-number-match.md

@@ -178,7 +178,7 @@ The following table provides details on support for these on-premises AD UPNs in
 | ----- | ----- | ----- | ----- |
 | Routable | Federated | From 1703 release | Generally available |
 | Non-routable | Federated | From 1803 release | Generally available |
-| Routable | Managed | From 1803 release | Generally available, Azure AD SSPR on Windows lock screen isn't supported. The on-premises UPN must be synced to the `onPremisesUserPrincipalName` attribute in Azure AD |
+| Routable | Managed | From 1803 release | Generally available, Azure AD SSPR on Windows lock screen isn't supported in environments where the on-premises UPN is different from the Azure AD UPN. The on-premises UPN must be synced to the `onPremisesUserPrincipalName` attribute in Azure AD |
 | Non-routable | Managed | Not supported | |
 
 ## Next steps

articles/active-directory/authentication/howto-sspr-windows.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: B2B
 ms.topic: conceptual
-ms.date: 02/07/2022
+ms.date: 03/21/2022
 
 ms.author: mimart
 author: msmimart
@@ -17,13 +17,13 @@ ms.collection: M365-identity-device-management
 
 # Authentication and Conditional Access for External Identities
 
-When an external user accesses resources in your organization, the authentication flow is determined by the user's identity provider (an external Azure AD tenant, social identity provider, etc.), Conditional Access policies, and the [cross-tenant access settings](cross-tenant-access-overview.md) configured both in the user's home tenant and the tenant hosting resources.
+When an external user accesses resources in your organization, the authentication flow is determined by the collaboration method (B2B collaboration or B2B direct connect), user's identity provider (an external Azure AD tenant, social identity provider, etc.), Conditional Access policies, and the [cross-tenant access settings](cross-tenant-access-overview.md) configured both in the user's home tenant and the tenant hosting resources.
 
 This article describes the authentication flow for external users who are accessing resources in your organization. Organizations can enforce multiple Conditional Access policies for their external users, which can be enforced at the tenant, app, or individual user level in the same way that they're enabled for full-time employees and members of the organization.
 
 ## Authentication flow for external Azure AD users
 
-The following diagram illustrates the authentication flow when an Azure AD organization shares resources with users from other Azure AD organizations. This diagram shows how cross-tenant access settings work with Conditional Access policies, such as multi-factor authentication (MFA), to determine if the user can access resources.
+The following diagram illustrates the authentication flow when an Azure AD organization shares resources with users from other Azure AD organizations. This diagram shows how cross-tenant access settings work with Conditional Access policies, such as multi-factor authentication (MFA), to determine if the user can access resources. This flow applies to both B2B collaboration and B2B direct connect, except as noted in step 6.
 
 ![Diagram illustrating the cross-tenant authentication process](media/authentication-conditional-access/cross-tenant-auth.png)
 
@@ -34,7 +34,7 @@ The following diagram illustrates the authentication flow when an Azure AD organ
 |**3**     | Azure AD checks Contoso’s inbound trust settings to see if Contoso trusts MFA and device claims (device compliance, hybrid Azure AD joined status) from Fabrikam. If not, skip to step 6.         |
 |**4**     | If Contoso trusts MFA and device claims from Fabrikam, Azure AD checks the user’s credentials for an indication the user has completed MFA. If Contoso trusts device information from Fabrikam, Azure AD uses the device ID to look up the device object in Fabrikam to determine its state (compliant or hybrid Azure AD joined).         |
 |**5**     | If MFA is required but not completed or if a device ID isn't provided, Azure AD issues MFA and device challenges in the user's home tenant as needed. When MFA and device requirements are satisfied in Fabrikam, the user is allowed access to the resource in Contoso. If the checks can’t be satisfied, access is blocked.        |
-|**6**     | When no trust settings are configured and MFA is required, B2B collaboration users are prompted for MFA, which they need to satisfy in the resource tenant. If device compliance is required, access is blocked.             |
+|**6**     | When no trust settings are configured and MFA is required, B2B collaboration users are prompted for MFA, which they need to satisfy in the resource tenant. Access is blocked for B2B direct connect users. If device compliance is required but can't be evaluated, access is blocked for both B2B collaboration and B2B direct connect users.             |
 
 For more information, see the [Conditional Access for external users](#conditional-access-for-external-users) section.
 
@@ -70,7 +70,7 @@ The following diagram illustrates the flow when email one-time passcode authenti
 
 ## Conditional Access for external users
 
-Organizations can enforce Conditional Access policies for external B2B collaboration users in the same way that they're enabled for full-time employees and members of the organization. This section describes important considerations for applying Conditional Access to users outside of your organization.
+Organizations can enforce Conditional Access policies for external B2B collaboration and B2B direct connect users in the same way that they're enabled for full-time employees and members of the organization. This section describes important considerations for applying Conditional Access to users outside of your organization.
 
 ### Azure AD cross-tenant trust settings for MFA and device claims