Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into app-articles-batch-15

Author: paulth1

.openpublishing.redirection.defender-for-iot.json

@@ -1,5 +1,10 @@
 {
     "redirections": [
+        {
+            "source_path_from_root": "/articles/defender-for-iot/organizations/how-to-install-software.md",
+            "redirect_url": "/azure/defender-for-iot/organizations/ot-deploy/install-software-ot-sensor",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/defender-for-iot/organizations/how-to-create-and-manage-users.md",
             "redirect_url": "/azure/defender-for-iot/organizations/manage-users-overview",
@@ -117,7 +122,7 @@
         },
         {
             "source_path_from_root": "/articles/defender-for-iot/how-to-install-software.md",
-            "redirect_url": "/azure/defender-for-iot/organizations/how-to-install-software",
+            "redirect_url": "/azure/defender-for-iot/organizations/ot-deploy/install-software-ot-sensor",
             "redirect_document_id": false
         },
         {

.openpublishing.redirection.json

@@ -18333,6 +18333,11 @@
             "redirect_url": "/azure/sentinel/normalization-schema-dns",
             "redirect_document_id": true
         },
+        {
+            "source_path_from_root": "/articles/sentinel/file-event-normalization-schema.md",
+            "redirect_url": "/azure/sentinel/normalization-schema-file-event",
+            "redirect_document_id": true
+        },
         {
             "source_path_from_root": "/articles/service-bus/index.md",
             "redirect_url": "/azure/service-bus-messaging/index",

articles/active-directory-b2c/TOC.yml

@@ -70,13 +70,13 @@
     items:
       - name: Global identity solutions
         href: azure-ad-b2c-global-identity-solutions.md
-      - name: Funnel-based design considerations
+      - name: Funnel-based design
         href: azure-ad-b2c-global-identity-funnel-based-design.md
-      - name: Region-based design considerations
+      - name: Region-based design
         href: azure-ad-b2c-global-identity-region-based-design.md
       - name: Funnel-based proof of concept 
         href: azure-ad-b2c-global-identity-proof-of-concept-funnel.md
-      - name: Regional-based proof of concept 
+      - name: Region-based proof of concept 
         href: azure-ad-b2c-global-identity-proof-of-concept-regional.md
   - name: Azure AD B2C best practices
     href: best-practices.md

articles/active-directory-b2c/azure-ad-b2c-global-identity-funnel-based-design.md

@@ -22,14 +22,14 @@ The designs account for:
 
 * Local Account sign up and sign in
 * Federated account sign up and sign in
-* Authenticating local accounts for users signing in from outside their registered region, supported by cross tenant API based authentication.
+* Authenticating local accounts for users signing in from outside their registered region, supported by cross tenant API based authentication
 * Authenticating federated accounts for users signing in from outside their registered region, supported by cross tenant API based look up
 * Prevents sign up from multiple different regions
 * Applications in each region have a single endpoint to connect with
 
 ## Local account sign-in use cases
 
-The following use cases are typical in a global Azure AD B2C environment. The local account use cases also cover accounts where the user travels. Each provides a diagram and workflow steps for each use case.
+The following use cases are typical in a global Azure AD B2C environment. The local account use cases also cover accounts where the user travels. We provide a diagram and workflow steps for each use case.
 
 ### Local user sign-up
 
@@ -99,8 +99,7 @@ This use case demonstrates how a user can travel across regions and maintain the
 
 1. The EMEA Azure AD B2C tenant performs an Azure AD ROPC flow against the NOAM Azure AD B2C tenant to verify credentials.
    >[!NOTE]
-   >This call will also fetch a token for the user to perform a Graph API call.
-   The EMEA Azure AD B2C tenant performs a Graph API call to the NOAM Azure AD B2C tenant to fetch the user's profile. This call is authenticated by the access token for Graph API acquired in the last step.
+   >This call will also fetch a token for the user to perform a Graph API call. The EMEA Azure AD B2C tenant performs a Graph API call to the NOAM Azure AD B2C tenant to fetch the user's profile. This call is authenticated by the access token for Graph API acquired in the last step.
 
 1. The regional tenant issues a token back to the funnel tenant.
 
@@ -312,6 +311,6 @@ This use case demonstrates how non-local users are able to perform account linki
 
 - [Build a global identity solution with region-based approach](azure-ad-b2c-global-identity-region-based-design.md)
 
-- [Azure AD B2C global identity proof of concept regional-based configuration](azure-ad-b2c-global-identity-proof-of-concept-regional.md)
+- [Azure AD B2C global identity proof of concept region-based configuration](azure-ad-b2c-global-identity-proof-of-concept-regional.md)
 
 - [Azure AD B2C global identity proof of concept funnel-based configuration](azure-ad-b2c-global-identity-proof-of-concept-funnel.md)

articles/active-directory-b2c/azure-ad-b2c-global-identity-proof-of-concept-regional.md

@@ -1,5 +1,5 @@
 ---
-title: Azure Active Directory B2C global identity framework proof of concept for regional based configuration
+title: Azure Active Directory B2C global identity framework proof of concept for region-based configuration
 description: Learn how to create a proof of concept regional based approach for Azure AD B2C to provide customer identity and access management for global customers.
 services: active-directory-b2c
 author: gargi-sinha
@@ -13,11 +13,11 @@ ms.author: gasinh
 ms.subservice: B2C
 ---
 
-# Azure Active Directory B2C global identity framework proof of concept regional based configuration
+# Azure Active Directory B2C global identity framework proof of concept for region-based configuration
 
-The following section describes how to create proof of concept implementations for regional-based orchestration. The completed Azure Active Directory B2C (Azure AD B2C) custom policies can be found [here](https://github.com/azure-ad-b2c/samples/tree/master/policies/global-architecture-model/region-based-approach).
+The following section describes how to create proof of concept implementations for region-based orchestration. The completed Azure Active Directory B2C (Azure AD B2C) custom policies can be found [here](https://github.com/azure-ad-b2c/samples/tree/master/policies/global-architecture-model/region-based-approach).
 
-## Regional-based approach
+## Region-based approach
 
 Each regional Azure AD B2C tenant will require an Azure AD B2C Custom policy, which contains the following capabilities:
 

articles/active-directory-b2c/azure-ad-b2c-global-identity-region-based-design.md

@@ -108,9 +108,7 @@ This use case demonstrates how a user can reset their password when they are wit
 
 ![Screenshot shows the local user forgot password flow.](media/azure-ad-b2c-global-identity-regional-design/local-user-forgot-password.png)
 
-1. User from EMEA attempts to sign in at **myapp.fr**.
-
-   If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
+1. User from EMEA attempts to sign in at **myapp.fr**. If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
 
 1. The user arrives at the EMEA Azure AD B2C tenant and selects **forgot password**. The user enters and verifies their email.
 
@@ -128,9 +126,7 @@ This use case demonstrates how a user can reset their password when they're trav
 
 ![Screenshot shows the traveling user forgot password flow.](media/azure-ad-b2c-global-identity-regional-design/traveling-user-forgot-password.png)
 
-1. User from NOAM attempts to sign in at **myapp.fr**, since they are on holiday in France.
-
-   If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
+1. User from NOAM attempts to sign in at **myapp.fr**, since they are on holiday in France. If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
 
 1. The user arrives at the EMEA Azure AD B2C tenant and selects **forgot password**. The user enters and verifies their email.
 
@@ -204,9 +200,7 @@ This use case demonstrates how a user from their local region signs into the ser
 
 ![Screenshot shows the sign in flow.](media/azure-ad-b2c-global-identity-regional-design/social-account-sign-in.png)
 
-1. User from EMEA attempts to sign in at **myapp.fr**.
-
-   If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
+1. User from EMEA attempts to sign in at **myapp.fr**. If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
 
 1. User lands at the EMEA tenant.
 
@@ -222,15 +216,13 @@ This scenario demonstrates how a user located away from the region in which they
 
 ![Screenshot shows the sign in for traveling user flow.](media/azure-ad-b2c-global-identity-regional-design/traveling-user-social-account-sign-in.png)
 
-1. User from NOAM attempts to sign in at **myapp.fr**.
-
-   If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
+1. User from NOAM attempts to sign in at **myapp.fr**. If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
 
 1. User lands at the EMEA tenant.
 
 1. User selects to sign in with a federated identity provider.
 
-    >[!NOTE]
+   >[!NOTE]
    >Use the same App Id from the App Registration at the Social IdP across all Azure AD B2C regional tenants. This ensures that the ID coming back from the Social IdP is always the same.
 
 1. Perform a lookup into the global lookup table and determine the user's federated ID is registered in NOAM.
@@ -245,9 +237,7 @@ This scenario demonstrates how users will be able to perform account linking whe
 
 ![Screenshot shows the merge/link accounts flow.](media/azure-ad-b2c-global-identity-regional-design/merge-link-account.png)
 
-1. User from EMEA attempts to sign in at **myapp.fr**.
-
-   If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
+1. User from EMEA attempts to sign in at **myapp.fr**. If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
 
 1. User lands at the EMEA tenant.
 
@@ -269,15 +259,13 @@ This scenario demonstrates how users will be able to perform  account linking wh
 
 ![Screenshot shows the traveling user merge/link accounts flow.](media/azure-ad-b2c-global-identity-regional-design/traveling-user-merge-link-account.png)
 
-1. User from NOAM attempts to sign in at **myapp.fr**.
-
-   If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
+1. User from NOAM attempts to sign in at **myapp.fr**. If the user isn't being sent to their local hostname, the traffic manager will enforce a redirect.
 
 1. User lands at the EMEA tenant.
 
 1. User selects to sign in with a federated identity provider/social IdP.
 
-1. A lookup is performed into the global lookup table for the ID     returned from the federated IdP.
+1. A lookup is performed into the global lookup table for the ID returned from the federated IdP.
 
 1. Where the ID doesn't exist, and the email from the federated IdP exists in another region, it's a traveling user account linking scenario.
 

articles/active-directory-b2c/configure-authentication-sample-python-web-app.md

@@ -216,7 +216,7 @@ Open the *app_config.py* file. This file contains information about your Azure A
 
 |Key  |Value  |
 |---------|---------|
-|`ENDPOINT`| The URI of your web API (for example, `https://localhost:44332/hello`).|
+|`ENDPOINT`| The URI of your web API (for example, `https://localhost:5000/getAToken`).|
 |`SCOPE`| The web API [scopes](#step-62-configure-scopes) that you created.|
 | | |
 
@@ -238,7 +238,7 @@ CLIENT_SECRET = "xxxxxxxxxxxxxxxxxxxxxxxx" # Placeholder - for use ONLY during t
 ### More code here
 
 # This is the API resource endpoint
-ENDPOINT = 'https://localhost:44332' 
+ENDPOINT = 'https://localhost:5000' 
 
 
 SCOPE = ["https://contoso.onmicrosoft.com/api/demo.read", "https://contoso.onmicrosoft.com/api/demo.write"] 

articles/active-directory/authentication/howto-authentication-use-email-signin.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 06/17/2022
+ms.date: 01/03/2023
 
 ms.author: justinha
 author: calui
@@ -66,7 +66,6 @@ In the current preview state, the following limitations apply to email as an alt
     * [Resource Owner Password Credentials (ROPC)](../develop/v2-oauth-ropc.md)
     * Legacy authentication such as POP3 and SMTP
     * Skype for Business
-    * Microsoft 365 Admin Portal
 
 * **Unsupported apps** - Some third-party applications may not work as expected if they assume that the `unique_name` or `preferred_username` claims are immutable or will always match a specific user attribute, such as UPN.
 

articles/active-directory/cloud-sync/how-to-configure.md

@@ -43,6 +43,10 @@ To configure provisioning, follow these steps.
  7. Enter a **Notification email**. This email will be notified when provisioning isn't healthy.  It is recommended that you keep **Prevent accidental deletion** enabled and set the **Accidental deletion threshold** to a number that you wish to be notified about.  For more information, see [accidental deletes](#accidental-deletions) below.
  8. Move the selector to Enable, and select Save.
 
+ >[!NOTE]
+ >  During the configuration process the synchronization service account will be created with the format **ADToAADSyncServiceAccount@[TenantID].onmicrosoft.com** and you may get an error if multi-factor authentication is enabled for the synchronization service account, or other interactive authentication policies are accidentally enabled for the synchronization account. Removing multi-factor authentication or any interactive authentication policies for the synchronization service account should resolve the error and you can complete the configuration smoothly.
+
+
 ## Scope provisioning to specific users and groups
 You can scope the agent to synchronize specific users and groups by using on-premises Active Directory groups or organizational units. You can't configure groups and organizational units within a configuration. 
  >[!NOTE]

articles/active-directory/develop/msal-migration.md

@@ -29,7 +29,7 @@ If any of your applications use the Azure Active Directory Authentication Librar
 
 ## Why switch to MSAL?
 
-To understand 'Why MSAL?', it's important to first understand the differences between Microsoft identity platform (v2.0) and Azure Active Directory (v1.0) endpoints. The v1.0 endpoint is used by Azure AD Authentication Library (ADAL) while the v2.0 endpoint is used by Microsoft Authentication Library (MSAL). If you've developed apps against the v1.0 endpoint in the past, you're likely using ADAL. Since the v2.0 endpoint has changed significantly enough, the new library (MSAL) was built for the new endpoint entirely. 
+If you've developed apps against Azure Active Directory (v1.0) endpoint in the past, you're likely using ADAL. Since Microsoft identity platform (v2.0) endpoint has changed significantly enough, the new library (MSAL) was built for the new endpoint entirely.
 
 The following diagram shows the v2.0 vs v1.0 endpoint experience at a high level, including the app registration experience, SDKs, endpoints, and supported identities.