Merge pull request #227616 from MicrosoftDocs/main

2/16 AM Publish

Author: huypub

articles/active-directory/app-provisioning/user-provisioning.md

@@ -7,7 +7,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.topic: overview
 ms.workload: identity
-ms.date: 02/15/2023
+ms.date: 02/16/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -26,16 +26,16 @@ App provisioning lets you:
 
 - **Automate provisioning**: Automatically create new accounts in the right systems for new people when they join your team or organization.
 - **Automate deprovisioning**: Automatically deactivate accounts in the right systems when people leave the team or organization.
-- **Synchronize data between systems**: Ensure that the identities in your apps and systems are kept up to date based on changes in the directory or your human resources system.
+- **Synchronize data between systems**: Keep the identities in apps and systems up to date based on changes in the directory or human resources system.
 - **Provision groups**: Provision groups to applications that support them.
-- **Govern access**: Monitor and audit who has been provisioned into your applications.
+- **Govern access**: Monitor and audit users provisioned in applications.
 - **Seamlessly deploy in brown field scenarios**: Match existing identities between systems and allow for easy integration, even when users already exist in the target system.
 - **Use rich customization**: Take advantage of customizable attribute mappings that define what user data should flow from the source system to the target system.
 - **Get alerts for critical events**: The provisioning service provides alerts for critical events and allows for Log Analytics integration where you can define custom alerts to suit your business needs.
 
 ## What is SCIM?
 
-To help automate provisioning and deprovisioning, apps expose proprietary user and group APIs. User management in more than one app is a challenge because every app tries to perform the same actions. For example, creating or updating users, adding users to groups, or deprovisioning users. Yet, all these actions are implemented slightly differently by using different endpoint paths, different methods to specify user information, and a different schema to represent each element of information.
+To help automate provisioning and deprovisioning, apps expose proprietary user and group APIs. User management in more than one app is a challenge because every app tries to perform the same actions. For example, creating or updating users, adding users to groups, or deprovisioning users. Often, developers implement these actions slightly different. For example, using different endpoint paths, different methods to specify user information, and different schema to represent each element of information.
 
 To address these challenges, the System for Cross-domain Identity Management (SCIM) specification provides a common user schema to help users move into, out of, and around apps. SCIM is becoming the de facto standard for provisioning and, when used with federation standards like Security Assertions Markup Language (SAML) or OpenID Connect (OIDC), provides administrators an end-to-end standards-based solution for access management.
 
@@ -74,7 +74,7 @@ Azure AD features pre-integrated support for many popular SaaS apps and human re
 
    ![Image that shows logos for DropBox, Salesforce, and others.](./media/user-provisioning/gallery-app-logos.png)
 
-   If you want to request a new application for provisioning, you can [request that your application be integrated with our app gallery](../manage-apps/v2-howto-app-gallery-listing.md). For a user provisioning request, we require the application to have a SCIM-compliant endpoint. Request that the application vendor follow the SCIM standard so we can onboard the app to our platform quickly.
+   If you want to request a new application for provisioning, you can [request that your application be integrated with our app gallery](../manage-apps/v2-howto-app-gallery-listing.md). For a user provisioning request, we require the application to have a SCIM-compliant endpoint. Request that the application vendor follows the SCIM standard so we can onboard the app to our platform quickly.
 
 * **Applications that support SCIM 2.0**: For information on how to generically connect applications that implement SCIM 2.0-based user management APIs, see [Build a SCIM endpoint and configure user provisioning](use-scim-to-provision-users-and-groups.md).
 

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

@@ -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/15/2023
+ms.date: 02/16/2023
 ms.author: justinha
 author: justinha
 ms.collection: M365-identity-device-management
@@ -87,12 +87,12 @@ Prior to the release of NPS extension version 1.2.2216.1 after May 8, 2023, orga
 >[!NOTE] 
 >NPS extensions versions earlier than 1.0.1.40 don't support OTP enforced by number matching. These versions will continue to present users with **Approve**/**Deny**.
 
-To create the registry key to override the **Approve**/**Deny** options in push notifications and require an OTP instead:
+To create the registry entry to override the **Approve**/**Deny** options in push notifications and require an OTP instead:
 
 1. On the NPS Server, open the Registry Editor.
 1. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa.
-1. Set the following Key Value Pair:
-   Key: OVERRIDE_NUMBER_MATCHING_WITH_OTP
+1. Create the following String/Value pair:
+   Name: OVERRIDE_NUMBER_MATCHING_WITH_OTP
    Value = TRUE
 1. Restart the NPS Service. 
 
@@ -330,12 +330,12 @@ Here are differences in sign-in scenarios that Microsoft Authenticator users wil
 - AD FS adapter will require number matching on [supported versions of Windows Server](#ad-fs-adapter). On earlier versions, users will continue to see the **Approve**/**Deny** experience and won’t see number matching until you upgrade. 
 - NPS extension versions beginning 1.2.2131.2 will require users to do number matching. Because the NPS extension can’t show a number, the user will be asked to enter a One-Time Passcode (OTP). The user must have an OTP authentication method such as Microsoft Authenticator or software OATH tokens registered to see this behavior. If the user doesn’t have an OTP method registered, they’ll continue to get the **Approve**/**Deny** experience.  
 
-  To create a registry key that overrides this behavior and prompts users with **Approve**/**Deny**: 
+  To create a registry entry that overrides this behavior and prompts users with **Approve**/**Deny**: 
 
   1. On the NPS Server, open the Registry Editor.
   1. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa.
-  1. Set the following Key Value Pair:
-     Key: OVERRIDE_NUMBER_MATCHING_WITH_OTP
+  1. Create the following String/Value:
+     Name: OVERRIDE_NUMBER_MATCHING_WITH_OTP
      Value = FALSE
   1. Restart the NPS Service. 
 
@@ -376,6 +376,16 @@ If a user is running an older version of Microsoft Authenticator that doesn't su
 
 Older versions of Microsoft Authenticator prompt users to tap and select a number rather than enter the number in Microsoft Authenticator. These authentications won't fail, but Microsoft highly recommends that users upgrade to the latest version of Microsoft Authenticator if they use Android versions prior to 6.2108.5654, or iOS versions prior to 6.5.82, so they can use number match.
 
+Minimum Microsoft Authenticator version supporting number matching:
+
+- Android: 6.2006.4198
+- iOS: 6.4.12
+
+Minimum Microsoft Authenticator version for number matching which prompts to enter a number:
+
+- Android 6.2111.7701
+- iOS 6.5.85
+
 ## Next steps
 
 [Authentication methods in Azure Active Directory](concept-authentication-authenticator-app.md)

articles/active-directory/authentication/howto-mfa-mfasettings.md

@@ -26,7 +26,7 @@ The following Azure AD Multi-Factor Authentication settings are available in the
 | ------- | ----------- |
 | [Account lockout](#account-lockout) | Temporarily lock accounts from using Azure AD Multi-Factor Authentication if there are too many denied authentication attempts in a row. This feature applies only to users who enter a PIN to authenticate. (MFA Server only) |
 | [Block/unblock users](#block-and-unblock-users) | Block specific users from being able to receive Azure AD Multi-Factor Authentication requests. Any authentication attempts for blocked users are automatically denied. Users remain blocked for 90 days from the time that they're blocked or until they're manually unblocked. |
-| [Fraud alert](#fraud-alert) | Configure settings that allow users to report fraudulent verification requests. |
+| [Report suspicious activity](#report-suspicious-activity) | Configure settings that allow users to report fraudulent verification requests. |
 | [Notifications](#notifications) | Enable notifications of events from MFA Server. |
 | [OATH tokens](concept-authentication-oath-tokens.md) | Used in cloud-based Azure AD Multi-Factor Authentication environments to manage OATH tokens for users. |
 | [Phone call settings](#phone-call-settings) | Configure settings related to phone calls and greetings for cloud and on-premises environments. |
@@ -76,33 +76,38 @@ To unblock a user, complete the following steps:
 1. Enter a comment in the **Reason for unblocking** box.
 1. Select **OK** to unblock the user.
 
-## Fraud alert
+## Report suspicious activity
 
-The fraud alert feature lets users report fraudulent attempts to access their resources. When an unknown and suspicious MFA prompt is received, users can report the fraud attempt by using the Microsoft Authenticator app or through their phone.
+A preview of **Report Suspicious Activity**, the updated MFA **Fraud Alert** feature, is now available. When an unknown and suspicious MFA prompt is received, users can report the fraud attempt by using Microsoft Authenticator or through their phone. These alerts are integrated with [Identity Protection](/azure/active-directory/identity-protection/overview-identity-protection) for more comprehensive coverage and capability. 
 
-The following fraud alert configuration options are available:
+Users who report an MFA prompt as suspicious are set to **High User Risk**. Administrators can use risk-based policies to limit access for these users, or enable self-service password reset (SSPR) for users to remediate problems on their own. If you previously used the **Fraud Alert** automatic blocking feature and don't have an Azure AD P2 license for risk-based policies, you can use risk detection events to identify and disable impacted users and automatically prevent their sign-in. For more information about using risk-based policies, see [Risk-based access policies](/azure/active-directory/identity-protection/concept-identity-protection-policies).  
 
-* **Automatically block users who report fraud**. If a user reports fraud, the Azure AD Multi-Factor Authentication attempts for the user  account are blocked for 90 days or until an administrator unblocks the account. An administrator can review sign-ins by using the sign-in report, and take appropriate action to prevent future fraud. An administrator can then [unblock](#unblock-a-user) the user's account.
-* **Code to report fraud during initial greeting**. When users receive a phone call to perform multi-factor authentication, they normally press **#** to confirm their sign-in. To report fraud, the user enters a code before pressing **#**. This code is **0** by default, but you can customize it. If automatic blocking is enabled, after the user presses **0#** to report fraud, they need to press **1** to confirm the account blocking.
+To enable **Report Suspicious Activity** from the Authentication Methods Settings:   
 
-   > [!NOTE]
-   > The default voice greetings from Microsoft instruct users to press **0#** to submit a fraud alert. If you want to use a code other than **0**, record and upload your own custom voice greetings with appropriate instructions for your users.
+1. In the Azure portal, click **Azure Active Directory** > **Security** > **Authentication Methods** > **Settings**. 
+1. Set **Report Suspicious Activity** to **Enabled**. 
+1. Select **All users** or a specific group. 
 
-To enable and configure fraud alerts, complete the following steps:
+### View suspicious activity events 
 
-1. Go to **Azure Active Directory** > **Security** > **Multifactor authentication** > **Fraud alert**.
-1. Set **Allow users to submit fraud alerts** to **On**.
-1. Configure the **Automatically block users who report fraud** or **Code to report fraud during initial greeting** setting as needed.
-1. Select **Save**.
+When a user reports a MFA prompt as suspicious, the event shows up in the Sign-ins report (as a sign-in that was rejected by the user), in the Audit logs, and in the Risk detections report.   
+
+- To view the risk detections report, select **Azure Active Directory** > **Security** > **Identity Protection** > **Risk detection**.  The risk event is part of the standard **Risk Detections** report, and will appear as Detection Type **User Reported Suspicious Activity**, Risk level **High**, Source **End user reported**. 
+
+- To view fraud reports in the Sign-ins report, select **Azure Active Directory** > **Sign-in logs** > **Authentication Details**. The fraud report is part of the standard **Azure AD Sign-ins** report and appears in the Result Detail as MFA denied, Fraud Code Entered. 
+
+- To view fraud reports in the Audit logs, select **Azure Active Directory** > **Audit logs**. The fraud report appears under Activity type Fraud reported - user is blocked for MFA or Fraud reported - no action taken based on the tenant-level settings for fraud report.  
+
+### Manage suspicious activity events 
+
+Once a user has reported a prompt as suspicious, the risk should be investigated and remediated with [Identity Protection](/azure/active-directory/identity-protection/howto-identity-protection-remediate-unblock). 
 
-### View fraud reports
+### Report suspicious activity and fraud alert 
 
-When a user reports fraud, the event shows up in the Sign-ins report (as a sign-in that was rejected by the user) and in the Audit logs.
+**Report Suspicious Activity** and the legacy **Fraud Alert** implementation can operate in parallel. You can keep your tenant-wide **Fraud Alert** functionality in place while you start to use **Report Suspicious Activity** with a targeted test group. 
 
-- To view fraud reports in the Sign-ins report, select **Azure Active Directory** > **Sign-in logs** > **Authentication Details**. The fraud report is part of the standard Azure AD Sign-ins report and appears in the **Result Detail** as **MFA denied, Fraud Code Entered**.
+If **Fraud Alert** is enabled with Automatic Blocking, and **Report Suspicious Activity** is enabled, the user will be added to the blocklist and set as high-risk and in-scope for any other policies configured. These users will need to be removed from the blocklist and have their risk remediated to enable them to sign in with MFA. 
 
-- To view fraud reports in the Audit logs, select **Azure Active Directory** > **Audit logs**. The fraud report appears under Activity type **Fraud reported - user is blocked for MFA** or **Fraud reported - no action taken** based on the tenant-level settings for fraud report.
- 
 ## Notifications
 
 You can configure Azure AD to send email notifications when users report fraud alerts. These notifications are typically sent to identity administrators, because the user's account credentials are likely compromised. The following example shows what a fraud alert notification email looks like:

articles/active-directory/develop/workload-identity-federation-considerations.md

@@ -9,9 +9,9 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 09/27/2022
+ms.date: 02/15/2022
 ms.author: ryanwi
-ms.reviewer: shkhalid, udayh, vakarand, cbrooks
+ms.reviewer: shkhalid, udayh, cbrooks
 ms.custom: aaddev, references_regions
 
 ---
@@ -52,7 +52,7 @@ Resources in these regions can still use federated identity credentials created
 
 *Applies to: applications and user-assigned managed identities (public preview)*
 
-Only issuers that provide tokens signed using the RS256 algorithm are supported for token exchange using workload identity federation.  Exchanging tokens signed with other algorithms may work, but have not been tested.
+Only issuers that provide tokens signed using the RS256 algorithm are supported for token exchange using workload identity federation.  Exchanging tokens signed with other algorithms may work, but haven't been tested.
 
 ## Azure Active Directory issuers aren't supported
 
@@ -81,9 +81,13 @@ To avoid this issue, wait a short time after adding the federated identity crede
 
 Creating multiple federated identity credentials under the same user-assigned managed identity concurrently triggers concurrency detection logic, which causes requests to fail with 409-conflict HTTP status code.  
 
+[Terraform Provider for Azure (Resource Manager)](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs) version 3.40.0 introduces an [update](https://github.com/hashicorp/terraform-provider-azurerm/pull/20003) which creates multiple federated identity credentials sequentially instead of concurrently.  Versions earlier than 3.40.0 can cause failures in pipelines when multiped federated identities are created. We recommend you use [Terraform Provider for Azure (Resource Manager) v3.40.0](https://github.com/hashicorp/terraform-provider-azurerm/tree/main) or later so that multiple federated identity credentials are created sequentially.
+
 When you use automation or Azure Resource Manager templates (ARM templates) to create federated identity credentials under the same parent identity, create the federated credentials sequentially. Federated identity credentials under different managed identities can be created in parallel without any restrictions.
 
-The following Azure Resource Manager template (ARM template) example creates three new federated identity credentials sequentially on a user-assigned managed identity by using the *dependsOn* property: 
+If federated identity credentials are provisioned in a loop, you can [provision them serially](/azure/azure-resource-manager/templates/copy-resources#serial-or-parallel) by setting *"mode": "serial"*.
+
+You can also provision multiple new federated identity credentials sequentially using the *dependsOn* property. The following Azure Resource Manager template (ARM template) example creates three new federated identity credentials sequentially on a user-assigned managed identity by using the *dependsOn* property:
 
 ```json
 { 
@@ -158,7 +162,7 @@ The following Azure Resource Manager template (ARM template) example creates thr
 
 *Applies to: applications and user-assigned managed identities (public preview)*
 
-It is possible to use a deny [Azure Policy](../../governance/policy/overview.md) as in the following ARM template example:
+It's possible to use a deny [Azure Policy](../../governance/policy/overview.md) as in the following ARM template example:
 
 ```json
 { 
@@ -196,7 +200,7 @@ The following error codes may be returned when creating, updating, getting, list
 | HTTP code         | Error message    | Comments    |
 |-------------------|----------------|----------------|
 | 405 | The request format was unexpected: Support for federated identity credentials not enabled. | Federated identity credentials aren't enabled in this region. Refer to “Currently Supported regions”. |
-| 400 | Federated identity credentials must have exactly 1 audience.| Currently, federated identity credentials support a single audience “api://AzureADTokenExchange”.| 
+| 400 | Federated identity credentials must have exactly one audience.| Currently, federated identity credentials support a single audience “api://AzureADTokenExchange”.| 
 | 400 | Federated Identity Credential from HTTP body has empty properties | All federated identity credential properties are mandatory. |
 | 400 | Federated Identity Credential name '{ficName}' is invalid. | Alphanumeric, dash, underscore, no more than 3-120 symbols. First symbol is alphanumeric. |
 | 404 | The parent user-assigned identity doesn't exist. | Check user assigned identity name in federated identity credentials resource path. |