Merge pull request #184383 from MicrosoftDocs/master

1/06 PM Publish

Author: huypub

.openpublishing.publish.config.json

@@ -843,8 +843,11 @@
     "articles/iot-accelerators/.openpublishing.redirection.iot-accelerators.json",
     "articles/iot-develop/.openpublishing.redirection.iot-develop.json",
     "articles/iot-edge/.openpublishing.redirection.iot-edge.json",
+    "articles/mariadb/.openpublishing.redirection.mariadb.json",
     "articles/marketplace/.openpublishing.redirection.marketplace.json",
+    "articles/mysql/.openpublishing.redirection.mysql.json",
     "articles/object-anchors/.openpublishing.redirection.object-anchors.json",
+    "articles/postgresql/.openpublishing.redirection.postgresql.json",
     "articles/purview/.openpublishing.redirection.purview.json",
     "articles/service-bus-messaging/.openpublishing.redirection.service-bus-messaging.json",
     "articles/stream-analytics/.openpublishing.redirection.stream-analytics.json",

.openpublishing.redirection.json

@@ -5,7 +5,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: tutorial
-ms.date: 06/01/2021
+ms.date: 1/05/2022
 ms.author: justinha
 author: justinha
 ms.reviewer: rhicock
@@ -53,8 +53,8 @@ In this tutorial, set up SSPR for a set of users in a test group. Use the *SSPR-
 
 1. Sign in to the [Azure portal](https://portal.azure.com) using an account with *global administrator* permissions.
 1. Search for and select **Azure Active Directory**, then select **Password reset** from the menu on the left side.
-1. From the **Properties** page, under the option *Self service password reset enabled*, select **Select group**
-1. Browse for and select your Azure AD group, like *SSPR-Test-Group*, then choose *Select*.
+1. From the **Properties** page, under the option *Self service password reset enabled*, choose **Selected**.
+1. If your group isn't visible, choose **No groups selected**, browse for and select your Azure AD group, like *SSPR-Test-Group*, and then choose *Select*.
 
     [![Select a group in the Azure portal to enable for self-service password reset](media/tutorial-enable-sspr/enable-sspr-for-group-cropped.png)](media/tutorial-enable-sspr/enable-sspr-for-group.png#lightbox)
 
@@ -64,7 +64,7 @@ In this tutorial, set up SSPR for a set of users in a test group. Use the *SSPR-
 
 When users need to unlock their account or reset their password, they're prompted for another confirmation method. This extra authentication factor makes sure that Azure AD finished only approved SSPR events. You can choose which authentication methods to allow, based on the registration information the user provides.
 
-1. From the menu on the left side of the **Authentication methods** page, set the **Number of methods required to reset** to *1*.
+1. From the menu on the left side of the **Authentication methods** page, set the **Number of methods required to reset** to *2*.
 
     To improve security, you can increase the number of authentication methods required for SSPR.
 
@@ -96,12 +96,12 @@ To keep users informed about account activity, you can set up Azure AD to send e
 
 1. From the menu on the left side of the **Notifications** page, set up the following options:
 
-   * Set **Notify users on password resets** option to *Yes*.
-   * Set **Notify all admins when other admins reset their password** to *Yes*.
+   * Set **Notify users on password resets?** option to *Yes*.
+   * Set **Notify all admins when other admins reset their password?** to *Yes*.
 
 1. To apply the notification preferences, select **Save**.
 
-If users need more help with the SSPR process, you can customize the "Contact your administrator" link. The user can select this link in the SSPR registration process and when they unlock their account or resets their password. To make sure your users get the support needed, we highly recommend you provide a custom helpdesk email or URL.
+If users need more help with the SSPR process, you can customize the "Contact your administrator" link. The user can select this link in the SSPR registration process and when they unlock their account or resets their password. To make sure your users get the support needed, we recommend you provide a custom helpdesk email or URL.
 
 1. From the menu on the left side of the **Customization** page, set **Customize helpdesk link** to *Yes*.
 1. In the **Custom helpdesk email or URL** field, provide an email address or web page URL where your users can get more help from your organization, like *https:\//support.contoso.com/*

articles/active-directory/authentication/media/tutorial-enable-sspr/enable-sspr-for-group-cropped.png

@@ -10,21 +10,21 @@ ms.service: active-directory
 ms.subservice: fundamentals
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 09/15/2020
+ms.date: 01/06/2022
 ms.custom: "it-pro, seodec18"
 ms.collection: M365-identity-device-management
 ---
 
 # Identity data storage for European customers in Azure Active Directory
-Identity data is stored by Azure AD in a geographical location  based on the address provided by your organization when subscribing for a Microsoft Online service such as Microsoft 365 and Azure. For information on where your identity data is stored, you can use the [Where is your data located?](https://www.microsoft.com/trustcenter/privacy/where-your-data-is-located) section of the Microsoft Trust Center.
+Identity data is stored by Azure AD in a geographical location based on the address provided by your organization when it subscribed for a Microsoft Online service such as Microsoft 365 and Azure. For information on where your identity data is stored, you can use the [Where is your data located?](https://www.microsoft.com/trustcenter/privacy/where-your-data-is-located) section of the Microsoft Trust Center.
 
 For customers who provided an address in Europe, Azure AD keeps most of the identity data within European datacenters. This document provides information on any data that is stored outside of Europe by Azure AD services.
 
 ## Microsoft Azure AD Multi-Factor Authentication
 
 For cloud-based Azure AD Multi-Factor Authentication, authentication is complete in the closest datacenter to the user. Datacenters for Azure AD Multi-Factor Authentication exist in North America, Europe, and Asia Pacific.
 
-* Multi-factor authentication using phone calls originate from US datacenters and are routed by global providers.
+* Multi-factor authentication using phone calls originate from datacenters in the customer's region and are routed by global providers.
 * Multi-factor authentication using SMS is routed by global providers.
 * Multi-factor authentication requests using the Microsoft Authenticator app push notifications that originate from EU datacenters are processed in EU datacenters.
     * Device vendor-specific services, such as Apple Push Notifications, may be outside Europe.
@@ -34,11 +34,11 @@ For more information about what user information is collected by Azure Multi-Fac
 
 ## Password-based Single Sign-On for Enterprise Applications
 
-If a customer creates a new enterprise application (whether through Azure AD Gallery or non-Gallery) and enables password-based SSO, the Application sign in URL, and custom capture sign in fields are stored in the United States. For more information on this feature, please refer to [Configure password-based single sign-on](../manage-apps/configure-password-single-sign-on-non-gallery-applications.md)
+If a customer creates a new enterprise application (whether through Azure AD Gallery or non-Gallery) and enables password-based SSO, the Application sign in URL, and custom capture sign in fields are stored in the United States. For more information, see [Configure password-based single sign-on](../manage-apps/configure-password-single-sign-on-non-gallery-applications.md)
 
 ## Microsoft Azure Active Directory B2C (Azure AD B2C)
 
-Azure AD B2C policy configuration data and Key Containers are stored in U.S. datacenters. These do not contain any user personal data. For more info about policy configurations, see the [Azure Active Directory B2C: Built-in policies](../../active-directory-b2c/user-flow-overview.md) article.
+Azure AD B2C policy configuration data and Key Containers are stored in U.S. datacenters, which do not contain any user personal data. For more info about policy configurations, see the [Azure Active Directory B2C: Built-in policies](../../active-directory-b2c/user-flow-overview.md) article.
 
 ## Microsoft Azure Active Directory B2B (Azure AD B2B) 
 

articles/active-directory/authentication/media/tutorial-enable-sspr/password-reset-page.png

@@ -136,7 +136,7 @@ It's possible to have more than one staging server when you want to have multipl
 ## Multiple Azure AD tenants
 We recommend having a single tenant in Azure AD for an organization. Before you plan to use multiple Azure AD tenants, see the article [Administrative units management in Azure AD](../roles/administrative-units.md). It covers common scenarios where you can use a single tenant.
 
-### (Public preview) Each object multiple times in an Azure AD tenant
+### (Public preview) Sync AD objects to multiple Azure AD tenants
 
 ![Diagram that shows a topology of multiple Azure A D tenants.](./media/plan-connect-topologies/multi-tenant-1.png)
 

articles/active-directory/authentication/tutorial-enable-sspr.md

@@ -41,7 +41,7 @@ Having a BIG-IP in front of the application enables us to overlay the service wi
 
 The secure hybrid access solution for this scenario is made up of the following:
 
-**Application:** Backend service protected by Azure AD and BIG-IP SHA. The application host is domain-joined and so is integrated with Active Directory (AD).
+**Application:** BIG-IP published service to be protected by and Azure AD SHA. The application host is domain-joined and so is integrated with Active Directory (AD).
 
 **Azure AD:** Security Assertion Markup Language (SAML) Identity Provider (IdP) responsible for verification of user credentials, Conditional Access (CA), and SSO to the BIG-IP APM.
 
@@ -55,8 +55,8 @@ Secure hybrid access for this scenario supports both SP and IdP initiated flows.
 
 | Steps| Description|
 | -------- |-------|
-| 1| User connects to application endpoint (BIG-IP) |
-| 2| BIG-IP access policy redirects user to Azure AD (SAML IdP) |
+| 1| User connects to SAML SP endpoint for application (BIG-IP APM) |
+| 2| APM access policy redirects user to Azure AD (SAML IdP) |
 | 3| Azure AD pre-authenticates user and applies any enforced CA policies |
 | 4| User is redirected to BIG-IP (SAML SP) and SSO is performed using issued SAML token |
 | 5| BIG-IP requests Kerberos ticket from KDC |
@@ -92,7 +92,7 @@ Prior BIG-IP experience isn’t necessary, but you will need:
 
 There are many methods to configure BIG-IP for this scenario, including two template-based options and an advanced configuration. This tutorial covers latest Guided Configuration 16.1 offering an Easy button template.
 
-With the **Easy Button**, admins no longer go back and forth between Azure AD and a BIG-IP to enable services for SHA. The end-to-end deployment and policy management is handled directly between the APM’s Guided Configuration wizard and Microsoft Graph. This rich integration between BIG-IP APM and Azure AD ensures applications can quickly, easily support identity federation, SSO, and Azure AD MFA, without management overhead of having to do on a per app basis.
+With the **Easy Button**, admins no longer go back and forth between Azure AD and a BIG-IP to enable services for SHA. The end-to-end deployment and policy management is handled directly between the APM’s Guided Configuration wizard and Microsoft Graph. This rich integration between BIG-IP APM and Azure AD ensures applications can quickly, easily support identity federation, SSO, and Azure AD Conditional Access, reducing administrative overhead.
 
 The advanced approach provides a more flexible way of implementing SHA by manually creating all BIG-IP configuration objects. You would also use this approach for scenarios not covered by the guided configuration templates.
 
@@ -101,7 +101,7 @@ The advanced approach provides a more flexible way of implementing SHA by manual
 
 ## Register Easy Button
 
-Before a client or service can access Microsoft Graph, it must be trusted by the Microsoft identity platform. Registering with Azure AD establishes a trust relationship between your application and the IdP. BIG-IP must also be registered as a client in Azure AD, before the Easy Button wizard is trusted to access Microsoft Graph.
+Before a client or service can access Microsoft Graph, it must be trusted by the Microsoft identity platform by being registered with Azure AD. A BIG-IP must also be registered as a client in Azure AD, before the Easy Button wizard is trusted to access Microsoft Graph.
 
 1. Sign-in to the [Azure AD portal](https://portal.azure.com/) using an account with Application Administrative rights
 

articles/active-directory/fundamentals/active-directory-data-storage-eu.md

@@ -31,21 +31,21 @@ To learn about all of the benefits, see the article on [F5 BIG-IP and Azure AD i
 
 For this scenario, we have a legacy application using HTTP authorization headers to control access to protected content. Azure AD pre-authentication provides the user identifier, while other attributes fetched from an LDAP connected Human Resource (HR) system provide fine grained application permissions.
 
-Ideally, Azure AD should manage the application, but being legacy it does not support any form of modern authentication protocol. Modernization would take considerable effort, introducing inevitable costs and risk of potential downtime.
+Ideally, application access should be managed directly by Azure AD but being legacy it lacks any form of modern authentication protocol. Modernization would take considerable effort and time, introducing inevitable costs and risk of potential downtime.
 
-Instead, a BIG-IP Virtual Edition (VE) deployed between the public internet and the internal Azure VNet application is connected and will be used to gate inbound access to the application, along with Azure AD for its extensive choice of authentication and authorization capabilities.
+Instead, a BIG-IP deployed between the public internet and the internal application will be used to gate inbound access to the application.
 
-Having a BIG-IP in front of the application enables us to overlay the service with Azure AD pre-authentication and header-based SSO. It significantly improves the overall security posture of the application, and allows the business to continue operating at pace, without interruption.
+Having a BIG-IP in front of the application enables us to overlay the service with Azure AD pre-authentication and header-based SSO, significantly improving the overall security posture of the application.
 
 ## Scenario architecture
 
 The secure hybrid access solution for this scenario is made up of:
 
-**Application:** Backend header-based service to be protected by Azure AD and BIG-IP secure hybrid access.
+**Application:** BIG-IP published service to be protected by and Azure AD SHA.
 
-**Azure AD:** Security Assertion Markup Language (SAML) Identity Provider (IdP) responsible for verification of user credentials, Conditional Access (CA), and SSO to the BIG-IP APM.
+**Azure AD:** Security Assertion Markup Language (SAML) Identity Provider (IdP) responsible for verification of user credentials, Conditional Access (CA), and SSO to the BIG-IP APM. Trough SSO, Azure AD provides the BIG-IP with any required session attributes.
 
-**HR system:** Legacy employee database acting as source of truth for application authorization
+**HR system:** Legacy employee database acting as source of truth for fine grained application permissions.
 
 **BIG-IP:** Reverse proxy and SAML service provider (SP) to the application, delegating authentication to the SAML IdP before performing header-based SSO to the backend application.
 
@@ -106,7 +106,7 @@ For scenarios where the Guided Configuration lacks the flexibility to achieve a
 
 ## Register Easy Button
 
-Before a client or service can access Microsoft Graph, it must be trusted by the Microsoft identity platform. Registering with Azure AD establishes a trust relationship between your application and the identity provider. BIG-IP must also be registered as a client in Azure AD, before the Easy Button wizard is trusted to access Microsoft Graph.
+Before a client or service can access Microsoft Graph, it must be trusted by the Microsoft identity platform by being registered with Azure AD. A BIG-IP must also be registered as a client in Azure AD, before the Easy Button wizard is trusted to access Microsoft Graph.
 
 1. Sign-in to the [Azure AD portal](https://portal.azure.com) using an account with Application Administrative rights
 

articles/active-directory/hybrid/plan-connect-topologies.md

@@ -172,7 +172,7 @@
             href: f5-big-ip-ldap-header-easybutton.md
         - name: Advanced configuration
           items:
-            - name: Header
+            - name: Headers
               href: f5-big-ip-header-advanced.md
             - name: Kerberos
               href: f5-big-ip-kerberos-advanced.md