Merge pull request #190039 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/active-directory-b2c/configure-authentication-in-sample-node-web-app-with-api.md

@@ -151,10 +151,10 @@ Open your web app in a code editor such as Visual Studio Code. Under the `call-p
 |---------|---------|
 |`APP_CLIENT_ID`|The **Application (client) ID** for the web app you registered in [step 2.3](#step-23-register-the-web-app). |
 |`APP_CLIENT_SECRET`|The client secret for the web app you created in [step 2.4](#step-24-create-a-client-secret) |
-|`SIGN_UP_SIGN_IN_POLICY_AUTHORITY`|The **Sign in and sign up** user flow authority for the user flow you created in [step 1](#step-1-configure-your-user-flow) such as `https://<your-tenant-name>.b2clogin.com/<your-tenant-name>.onmicrosoft.com/<sign-in-sign-up-user-flow-name>`. Replace `<your-tenant-name>` with the name of your tenant and `<sign-in-sign-up-user-flow-name>` with the name of your Sign in and Sign up user flow such as `B2C_1_susi_node_app`. Learn how to [Get your tenant name](tenant-management.md#get-your-tenant-name). |
+|`SIGN_UP_SIGN_IN_POLICY_AUTHORITY`|The **Sign in and sign up** user flow authority for the user flow you created in [step 1](#step-1-configure-your-user-flow) such as `https://<your-tenant-name>.b2clogin.com/<your-tenant-name>.onmicrosoft.com/<sign-in-sign-up-user-flow-name>`. Replace `<your-tenant-name>` with the name of your tenant and `<sign-in-sign-up-user-flow-name>` with the name of your Sign in and Sign up user flow such as `B2C_1_susi`. Learn how to [Get your tenant name](tenant-management.md#get-your-tenant-name). |
 |`AUTHORITY_DOMAIN`| The Azure AD B2C authority domain such as `https://<your-tenant-name>.b2clogin.com`. Replace `<your-tenant-name>` with the name of your tenant.|
 |`APP_REDIRECT_URI`| The application redirect URI where Azure AD B2C will return authentication responses (tokens). It matches the **Redirect URI** you set while registering your app in Azure portal. This URL need to be publicly accessible. Leave the value as is.|
-|`LOGOUT_ENDPOINT`| The Azure AD B2C sign out endpoint such as `https://<your-tenant-name>.b2clogin.com/<your-tenant-name>.onmicrosoft.com/<sign-in-sign-up-user-flow-name>/oauth2/v2.0/logout?post_logout_redirect_uri=http://localhost:3000`. Replace `<your-tenant-name>` with the name of your tenant and `<sign-in-sign-up-user-flow-name>` with the name of your Sign in and Sign up user flow such as `B2C_1_susi_node_app`.|
+|`LOGOUT_ENDPOINT`| The Azure AD B2C sign out endpoint such as `https://<your-tenant-name>.b2clogin.com/<your-tenant-name>.onmicrosoft.com/<sign-in-sign-up-user-flow-name>/oauth2/v2.0/logout?post_logout_redirect_uri=http://localhost:3000`. Replace `<your-tenant-name>` with the name of your tenant and `<sign-in-sign-up-user-flow-name>` with the name of your Sign in and Sign up user flow such as `B2C_1_susi`.|
 
 After the update, your final configuration file should look similar to the following sample:
 
@@ -186,7 +186,7 @@ To get the web API sample code, do one of the following:
     
     - For `clientID`, use the **Application (Client) ID** for the web API you created in [step 2.1](#step-21-register-the-web-api-application).
     
-    - For `policyName`, use the name of the **Sing in and sign up** user flow you created in [step 1](#step-1-configure-your-user-flow) such as `B2C_1_susi_node_app`.
+    - For `policyName`, use the name of the **Sing in and sign up** user flow you created in [step 1](#step-1-configure-your-user-flow) such as `B2C_1_susi`.
    
    After the update, your code should look similar to the following sample: 
     

articles/active-directory-b2c/partner-experian.md

@@ -47,7 +47,7 @@ The Experian integration includes the following components:
 
 - Experian – The Experian service takes inputs provided by the user and verifies the user's identity
 
-- Custom Rest API – This API implements the integration between Azure AD B2C and the Experian service.
+- Custom REST API – This API implements the integration between Azure AD B2C and the Experian service.
 
 The following architecture diagram shows the implementation.
 
@@ -87,7 +87,7 @@ The Experian API call is protected by a client certificate. This client certific
 
 ### Part 3 - Configure the API
 
-Application settings can be [configured in the App service in Azure](../app-service/configure-common.md#configure-app-settings). With this method,  settings can be securely configured without checking them into a repository. You'll need to provide the following settings to the Rest API:
+Application settings can be [configured in the App service in Azure](../app-service/configure-common.md#configure-app-settings). With this method,  settings can be securely configured without checking them into a repository. You'll need to provide the following settings to the REST API:
 
 | Application settings | Source | Notes |
 | :-------- | :------------| :-----------|

articles/active-directory-b2c/partner-hypr.md

@@ -27,7 +27,7 @@ To get started, you'll need:
 
 - A HYPR cloud tenant, get a free [trial account](https://get.hypr.com/free-trial).
 
-- A user's mobile device registered using the HYPR Rest APIs or the HYPR Device Manager in your HYPR tenant. For example, you can use the [HYPR Java SDK](https://docs.hypr.com/integratinghypr/docs/hypr-java-web-sdk) to accomplish this task.
+- A user's mobile device registered using the HYPR REST APIs or the HYPR Device Manager in your HYPR tenant. For example, you can use the [HYPR Java SDK](https://docs.hypr.com/integratinghypr/docs/hypr-java-web-sdk) to accomplish this task.
 
 ## Scenario description
 
@@ -39,7 +39,7 @@ The HYRP integration includes the following components:
 
 - The HYPR mobile app - The HYPR mobile app can be used to execute this sample if prefer not to use the mobile SDKs in your own mobile applications.
 
-- HYPR Rest APIs - You can use the HYPR APIs to do both user device registration and authentication. These APIs can be found [here](https://apidocs.hypr.com).
+- HYPR REST APIs - You can use the HYPR APIs to do both user device registration and authentication. These APIs can be found [here](https://apidocs.hypr.com).
 
 The following architecture diagram shows the implementation.
 

articles/active-directory-b2c/partner-idology.md

@@ -31,7 +31,7 @@ The IDology integration includes the following components:
 
 - Azure AD B2C – The authorization server responsible for verifying the user’s credentials. It's also known as the identity provider.
 - IDology – The IDology service takes input provided by the user and verifies the user’s identity.
-- Custom Rest API – This API implements the integration between Azure AD and the IDology service.
+- Custom REST API – This API implements the integration between Azure AD and the IDology service.
 
 The following architecture diagram shows the implementation.
 
@@ -69,7 +69,7 @@ You'll need the URL of the deployed service to configure Azure AD with the requi
 
 ### Part 2 - Configure the API 
 
-Application settings can be [configured in App Service in Azure](../app-service/configure-common.md#configure-app-settings). With this method, settings can be securely configured without checking them into a repository. You'll need to provide the following settings to the Rest API:
+Application settings can be [configured in App Service in Azure](../app-service/configure-common.md#configure-app-settings). With this method, settings can be securely configured without checking them into a repository. You'll need to provide the following settings to the REST API:
 
 | Application settings | Source | Notes |
 | :-------- | :------------| :-----------|

articles/active-directory-b2c/partner-jumio.md

@@ -34,7 +34,7 @@ The Jumio integration includes the following components:
 
 - Jumio: The service that takes the ID details provided by the user and verifies them.
 
-- Intermediate Rest API: The API that implements the integration between Azure AD B2C and the Jumio service.
+- Intermediate REST API: The API that implements the integration between Azure AD B2C and the Jumio service.
 
 - Azure Blob storage: The service that supplies custom UI files to the Azure AD B2C policies.
 
@@ -98,7 +98,7 @@ Use the following PowerShell script to create the string:
 
 ### Configure the API
 
-You can [configure application settings in Azure App Service](../app-service/configure-common.md#configure-app-settings). With this method, you can securely configure settings without checking them into a repository. You'll need to provide the following settings to the Rest API:
+You can [configure application settings in Azure App Service](../app-service/configure-common.md#configure-app-settings). With this method, you can securely configure settings without checking them into a repository. You'll need to provide the following settings to the REST API:
 
 | Application settings | Source | Notes |
 | :-------- | :------------| :-----------|

articles/active-directory-b2c/partner-lexisnexis.md

@@ -38,7 +38,7 @@ The ThreatMetrix integration includes the following components:
 
 - ThreatMetrix – The ThreatMetrix service takes inputs provided by the user and combines it with profiling information gathered from the user's machine to verify the security of the user interaction.
 
-- Custom Rest API – This API implements the integration between Azure AD B2C and the ThreatMetrix service.
+- Custom REST API – This API implements the integration between Azure AD B2C and the ThreatMetrix service.
 
 The following architecture diagram shows the implementation.
 
@@ -75,7 +75,7 @@ Deploy the provided [API code](https://github.com/azure-ad-b2c/partner-integrati
 
 ### Part 2 - Configure the API
 
-Application settings can be [configured in the App service in Azure](../app-service/configure-common.md#configure-app-settings).  With this method,  settings can be securely configured without checking them into a repository. You'll need to provide the following settings to the Rest API:
+Application settings can be [configured in the App service in Azure](../app-service/configure-common.md#configure-app-settings).  With this method,  settings can be securely configured without checking them into a repository. You'll need to provide the following settings to the REST API:
 
 | Application settings | Source | Notes |
 | :-------- | :------------| :-----------|

articles/active-directory-b2c/partner-onfido.md

@@ -37,7 +37,7 @@ The Onfido integration includes the following components:
 
 - Onfido client – A configurable JavaScript client document collection utility deployed within other webpages. Collects the documents and does preliminary checks like document size and quality.
 
-- Intermediate Rest API – Provides endpoints for the Azure AD B2C tenant to communicate with the Onfido API service, handling data processing and adhering to the security requirements of both.
+- Intermediate REST API – Provides endpoints for the Azure AD B2C tenant to communicate with the Onfido API service, handling data processing and adhering to the security requirements of both.
 
 - Onfido API service – The backend service provided by Onfido, which saves and verifies the documents provided by the user.
 
@@ -77,7 +77,7 @@ For more information about Onfido, see [Onfido API documentation](https://docume
 
 #### Adding sensitive configuration settings
 
-Application settings can be configured in the [App service in Azure](../app-service/configure-common.md#configure-app-settings). The App service allows for settings to be securely configured without checking them into a repository. The Rest API needs the following settings:
+Application settings can be configured in the [App service in Azure](../app-service/configure-common.md#configure-app-settings). The App service allows for settings to be securely configured without checking them into a repository. The REST API needs the following settings:
 
 | Application setting name | Source | Notes |
 |:-------------------------|:-------|:-------|

articles/active-directory-b2c/phone-authentication-user-flows.md

@@ -79,7 +79,7 @@ Here's an example showing how to add phone sign-up to a new user flow.
 1. Under **Social identity providers**, select any other identity providers you want to allow for this user flow.
 
    > [!NOTE]
-   > Multi-factor authentication (MFA) is disabled by default for sign-up user flows. You can enable MFA for a phone sign-up user flow, but because a phone number is used as the primary identifier, email one-time passcode is the only option available for the second authentication factor.
+   > [Multi-factor authentication (MFA)](multi-factor-authentication.md) is disabled by default for sign-up user flows. You can enable MFA for a phone sign-up user flow, but because a phone number is used as the primary identifier, email one-time passcode and Authenticator app - TOTP (preview) are the only options available for the second authentication factor.
 
 1. In the **User attributes and token claims** section, choose the claims and attributes that you want to collect and send from the user during sign-up. For example, select **Show more**, and then choose attributes and claims for **Country/Region**, **Display Name**, and **Postal Code**. Select **OK**.
 

articles/active-directory/cloud-infrastructure-entitlement-management/cloudknox-howto-create-alert-trigger.md

@@ -51,7 +51,7 @@ This article describes how you can create and view activity alerts and alert tri
 1. From the **Alert Name** dropdown, select an alert.
 1. From the **Date** dropdown, select **Last 24 Hours**, **Last 2 Days**, **Last Week**, or **Custom Range**.
 
-    If you select **Custom range**, select date and time settings, and then select **Apply**.
+    If you select **Custom Range**, select date and time settings, and then select **Apply**.
 1. To view the alert, select **Apply**
 
     The **Alerts** table displays information about your alert.
@@ -61,7 +61,7 @@ This article describes how you can create and view activity alerts and alert tri
 ## View activity alert triggers
 
 1. In the CloudKnox home page, select **Activity triggers** (the bell icon).
-1. In the **Activity** tab, select the **Alert triggers** subtab.
+1. In the **Activity** tab, select the **Alert Triggers** subtab.
 1. From the **Status** dropdown, select **All**, **Activated** or **Deactivated**, then select **Apply**.
 
     The **Triggers** table displays the following information:
@@ -71,9 +71,9 @@ This article describes how you can create and view activity alerts and alert tri
 
         - Select a number in this column to view information about the user.
 
-    - **Created by**: The email address of the user who created the alert trigger.
-    - **Modified by**: The email address of the user who last modified the alert trigger.
-    - **Last updated**: The date and time the alert trigger was last updated.
+    - **Created By**: The email address of the user who created the alert trigger.
+    - **Modified By**: The email address of the user who last modified the alert trigger.
+    - **Last Updated**: The date and time the alert trigger was last updated.
     - **Subscription**: A switch that displays if the alert is **On** or **Off**.
 
          - If the column displays **Off**, the current user isn't subscribed to that alert. Switch the toggle to **On** to subscribe to the alert.
@@ -94,12 +94,12 @@ This article describes how you can create and view activity alerts and alert tri
     - **Rename**: Enter the new name of the query, and then select **Save.**
     - **Deactivate**: The alert will still be listed, but will no longer send emails to subscribed users.
     - **Activate**: Activate the alert trigger and start sending emails to subscribed users.
-    - **Notification settings**: View the **Email** of users who are subscribed to the alert trigger and their **User status**. 
+    - **Notification Settings**: View the **Email** of users who are subscribed to the alert trigger and their **User Status**. 
     - **Delete**: Delete the alert.
 
     If the **Subscription** is **Off**, the following options are available:
     - **View**: View  details of the alert trigger.
-    - **Notification settings**: View the **Email** of users who are subscribed to the alert trigger and their **User status**. 
+    - **Notification Settings**: View the **Email** of users who are subscribed to the alert trigger and their **User Status**. 
     - **Duplicate**: Create a duplicate copy of the selected alert trigger.
 
 

articles/active-directory/cloud-infrastructure-entitlement-management/cloudknox-howto-create-rule.md

@@ -27,30 +27,30 @@ This article describes how to create a rule in the CloudKnox Permissions Managem
 
 1. In the CloudKnox home page, select the **Autopilot** tab.
 1. In the **Autopilot** dashboard, from the **Authorization system types** dropdown, select Amazon Web Services (**AWS**), Microsoft **Azure**, or Google Cloud Platform (**GCP**).
-1. From the **Authorization system** dropdown, in the **List** and **Folders** box, select the account and folder names that you want, and then select **Apply**.  
-1. In the **Autopilot** dashboard, select **New rule**.
-1. In the **Rule name** box, enter a name for your rule.
+1. From the **Authorization System** dropdown, in the **List** and **Folders** box, select the account and folder names that you want, and then select **Apply**.  
+1. In the **Autopilot** dashboard, select **New Rule**.
+1. In the **Rule Name** box, enter a name for your rule.
 1. Select **AWS**, **Azure**, **GCP**, and then select **Next**.
 
-1. Select **Authorization systems**, and then select **All** or the account names that you want.
+1. Select **Authorization Systems**, and then select **All** or the account names that you want.
 1. From the **Folders** dropdown, select a folder, and then select **Apply**.
 
     To change your folder settings, select **Reset**.
 
     - The **Status** column displays if the authorization system is **Online** or **Offline**.
-    - The **Controller** column displays if the controller is **Enabled** or **Not enabled**.
+    - The **Controller** column displays if the controller is **Enabled** or **Not Enabled**.
 
 
 1. Select **Configure** , and then select the following parameters for your rule:
 
-    - **Role created on is**: Select the duration in days.
-    - **Role last used on is**: Select the duration in days when the role was last used.
-    - **Cross account role**: Select **True** or **False**.
+    - **Role Created On Is**: Select the duration in days.
+    - **Role Last Used On Is**: Select the duration in days when the role was last used.
+    - **Cross Account Role**: Select **True** or **False**.
 
-1. Select **Mode**, and then, if you want recommendations to be generated and applied manually, select **On-demand**.
+1. Select **Mode**, and then, if you want recommendations to be generated and applied manually, select **On-Demand**.
 1. Select **Save**
 
-    The following information displays in the **Autopilot rules** table:
+    The following information displays in the **Autopilot Rules** table:
 
     - **Rule Name**: The name of the rule.
     - **State**: The status of the rule: idle (not being use) or active (being used).