Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr

Author: jpconnock

.openpublishing.redirection.json

@@ -141,19 +141,19 @@ To configure UI customization, you copy the **ContentDefinition** and its child
 
 1. Save the extensions file.
 
-## Upload your updated custom policy
+## Upload and test your updated custom policy
+
+### Upload the custom policy
 
 1. Make sure you're using the directory that contains your Azure AD B2C tenant by selecting the **Directory + subscription** filter in the top menu and choosing the directory that contains your tenant.
-1. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **Azure AD B2C**.
-1. Select **Identity Experience Framework**.
-1. Click **All Policies**.
-1. Click **Upload Policy**.
+1. Search for and select **Azure AD B2C**.
+1. Under **Policies**, select **Identity Experience Framework**.
+1. Select **Upload custom policy**.
 1. Upload the extensions file that you previously changed.
 
-## Test the custom policy by using **Run now**
+### Test the custom policy by using **Run now**
 
-1. On the **Azure AD B2C** page, go to **All policies**.
-1. Select the custom policy that you uploaded, and click the **Run now** button.
+1. Select the policy that you uploaded, and then select **Run now**.
 1. You should be able to sign up by using an email address.
 
 ## Reference

articles/active-directory-b2c/active-directory-b2c-ui-customization-custom.md

@@ -33,7 +33,7 @@ The following example shows the content definition identifier and the definition
   <Metadata>
     <Item Key="DisplayName">Local account sign up page</Item>
   </Metadata>
-  <LoalizedResourcesReferences MergeBehavior="Prepend">
+  <LocalizedResourcesReferences MergeBehavior="Prepend">
     <LocalizedResourcesReference Language="en" LocalizedResourcesReferenceId="api.localaccountsignup.en" />
     <LocalizedResourcesReference Language="es" LocalizedResourcesReferenceId="api.localaccountsignup.es" />
     ...

articles/active-directory-b2c/contentdefinitions.md

@@ -122,10 +122,10 @@ The technical profile also returns claims, that aren't returned by the identity
 | --------- | -------- | ----------- |
 | ServiceUrl | Yes | The URL of the REST API endpoint. |
 | AuthenticationType | Yes | The type of authentication being performed by the RESTful claims provider. Possible values: `None`, `Basic`, `Bearer`, or `ClientCertificate`. The `None` value indicates that the REST API is not anonymous. The `Basic` value indicates that the REST API is secured with HTTP basic authentication. Only verified users, including Azure AD B2C, can access your API. The `ClientCertificate` (recommended) value indicates that the REST API restricts access by using client certificate authentication. Only services that have the appropriate certificates, for example Azure AD B2C, can access your API. The `Bearer` value indicates that the REST API restricts access using client OAuth2 Bearer token. |
-| SendClaimsIn | No | Specifies how the input claims are sent to the RESTful claims provider. Possible values: `Body` (default), `Form`, `Header`, or `QueryString`. The `Body` value is the input claim that is sent in the request body in JSON format. The `Form` value is the input claim that is sent in the request body in an ampersand '&' separated key value format. The `Header` value is the input claim that is sent in the request header. The `QueryString` value is the input claim that is sent in the request query string. |
+| SendClaimsIn | No | Specifies how the input claims are sent to the RESTful claims provider. Possible values: `Body` (default), `Form`, `Header`, or `QueryString`. The `Body` value is the input claim that is sent in the request body in JSON format. The `Form` value is the input claim that is sent in the request body in an ampersand '&' separated key value format. The `Header` value is the input claim that is sent in the request header. The `QueryString` value is the input claim that is sent in the request query string. The HTTP verbs invoked by each are as follows:<br /><ul><li>`Body`: POST</li><li>`Form`: POST</li><li>`Header`: GET</li><li>`QueryString`: GET</li></ul> |
 | ClaimsFormat | No | Specifies the format for the output claims. Possible values: `Body` (default), `Form`, `Header`, or `QueryString`. The `Body` value is the output claim that is sent in the request body in JSON format. The `Form` value is the output claim that is sent in the request body in an ampersand '&' separated key value format. The `Header` value is the output claim that is sent in the request header. The `QueryString` value is the output claim that is sent in the request query string. |
 | ClaimUsedForRequestPayload| No | Name of a string claim that contains the payload to be sent to the REST API. |
-| DebugMode | No | Runs the technical profile in debug mode. In debug mode, the REST API can return more information. See the returning error message section. |
+| DebugMode | No | Runs the technical profile in debug mode. Possible values: `true`, or `false` (default). In debug mode, the REST API can return more information. See the [Returning error message](#returning-error-message) section. |
 
 ## Cryptographic keys
 
@@ -212,7 +212,7 @@ If the type of authentication is set to `Bearer`, the **CryptographicKeys** elem
 
 ## Returning error message
 
-Your REST API may need to return an error message, such as 'The user was not found in the CRM system'. In an error occurs, the REST API should return an HTTP 409 error message (Conflict response status code) with following attributes:
+Your REST API may need to return an error message, such as 'The user was not found in the CRM system'. If an error occurs, the REST API should return an HTTP 409 error message (Conflict response status code) with following attributes:
 
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |

articles/active-directory-b2c/restful-technical-profile.md

@@ -45,11 +45,11 @@ If your MFA provider is not linked to an Azure AD tenant, or you link the new MF
 > [!CAUTION]
 > There is no confirmation when deleting an authentication provider. Selecting **Delete** is a permanent process.
 
-Authentication providers can be found in the **Azure portal** > **Azure Active Directory** > **MFA** > **Providers**. Click on listed providers to see details and configurations associated with that provider.
+Authentication providers can be found in the **Azure portal** > **Azure Active Directory** > **Security** > **MFA** > **Providers**. Click on listed providers to see details and configurations associated with that provider.
 
 Before removing an authentication provider, take note of any customized settings configured in your provider. Decide what settings need to be migrated to general MFA settings from your provider and complete the migration of those settings. 
 
-Azure MFA Servers linked to providers will need to be reactivated using credentials generated under **Azure portal** > **Azure Active Directory** > **MFA** > **Server settings**. Before reactivating, the following files must be deleted from the `\Program Files\Multi-Factor Authentication Server\Data\` directory on Azure MFA Servers in your environment:
+Azure MFA Servers linked to providers will need to be reactivated using credentials generated under **Azure portal** > **Azure Active Directory** > **Security** > **MFA** > **Server settings**. Before reactivating, the following files must be deleted from the `\Program Files\Multi-Factor Authentication Server\Data\` directory on Azure MFA Servers in your environment:
 
 - caCert
 - cert
@@ -61,7 +61,7 @@ Azure MFA Servers linked to providers will need to be reactivated using credenti
 
 ![Delete an auth provider from the Azure portal](./media/concept-mfa-authprovider/authentication-provider-removal.png)
 
-When you have confirmed that all settings have been migrated, you can browse to the **Azure portal** > **Azure Active Directory** > **MFA** > **Providers** and select the ellipses **...** and select **Delete**.
+When you have confirmed that all settings have been migrated, you can browse to the **Azure portal** > **Azure Active Directory** > **Security** > **MFA** > **Providers** and select the ellipses **...** and select **Delete**.
 
 > [!WARNING]
 > Deleting an authentication provider will delete any reporting information associated with that provider. You may want to save activity reports before deleting your provider.

articles/active-directory/authentication/concept-mfa-authprovider.md

@@ -83,7 +83,7 @@ The first thing we need to do is to configure the AD FS claims. Create two claim
 Now that the claims are in place, we can configure trusted IPs.
 
 1. Sign in to the [Azure portal](https://portal.azure.com).
-2. Select **Azure Active Directory** > **Conditional Access** > **Named locations**.
+2. Select **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**.
 3. From the **Conditional Access - Named locations** blade, select **Configure MFA trusted IPs**
 
    ![Azure AD Conditional Access named locations Configure MFA trusted IPs](./media/howto-mfa-adfs/trustedip6.png)

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

@@ -82,18 +82,18 @@ We recommend that organizations use Conditional Access to define their network u
 ### Configuring a named location
 
 1. Open **Azure Active Directory** in the Azure portal
-2. Click **Conditional Access**
-3. Click **Named Locations**
-4. Click **New Location**
+2. Select **Security**
+3. Under **Manage**, choose **Named Locations**
+4. Select **New Location**
 5. In the **Name** field, provide a meaningful name
-6. Select whether you are defining the location using IP ranges or Countries/Regions
-   1. If using IP Ranges
-      1. Decide whether to mark the location as Trusted. Signing in from a trusted location lowers a user's sign-in risk. Only mark this location as trusted if you know the IP ranges entered are established and credible in your organization.
+6. Select whether you are defining the location using *IP ranges* or *Countries/Regions*
+   1. If using *IP Ranges*
+      1. Decide whether to *Mark as trusted location*. Signing in from a trusted location lowers a user's sign-in risk. Only mark this location as trusted if you know the IP ranges entered are established and credible in your organization.
       2. Specify the IP Ranges
-   2. If using Countries/Regions
+   2. If using *Countries/Regions*
       1. Expand the drop-down menu and select the countries or regions you wish to define for this named location.
-      2. Decide whether to Include unknown areas. Unknown areas are IP addresses that can't be mapped to a country/region.
-7. Click **Create**
+      2. Decide whether to *Include unknown areas*. Unknown areas are IP addresses that can't be mapped to a country/region.
+7. Select **Create**
 
 ## Plan authentication methods
 
@@ -218,7 +218,7 @@ It is important that you prevent being inadvertently locked out of your Azure AD
 ### Create Conditional Access policy
 
 1. Sign in to the [Azure portal](https://portal.azure.com) using a global administrator account.
-1. Browse to **Azure Active Directory**, **Conditional Access**.
+1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
 1. Select **New policy**.
    ![Create a Conditional Access policy to enable MFA for Azure portal users in pilot group](media/howto-mfa-getstarted/conditionalaccess-newpolicy.png)
 1. Provide a meaningful name for your policy.

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

@@ -93,8 +93,8 @@ If you aren't using the Event Confirmation feature, and your users aren't using
 Follow these steps to download the Azure Multi-Factor Authentication Server from the Azure portal:
 
 1. Sign in to the [Azure portal](https://portal.azure.com) as an administrator.
-2. Search for and select *Azure Active Directory*. Select **MFA Server**.
-3. Select **Server settings**.
+2. Search for and select *Azure Active Directory*. Select **Security** > **MFA**.
+3. Under **Manager MFA Server**, select **Server settings**.
 4. Select **Download** and follow the instructions on the download page to save the installer. 
 
    ![Download MFA Server from the Azure portal](./media/howto-mfaserver-deploy/downloadportal.png)

articles/active-directory/authentication/howto-mfaserver-deploy.md

@@ -23,7 +23,7 @@ Many organizations find their users create passwords using common local words su
 
 Configuring the custom banned password list requires an Azure Active Directory Premium P1 or P2 license. For more detailed information about Azure Active Directory licensing, see the [Azure Active Directory pricing page](https://azure.microsoft.com/pricing/details/active-directory/).
 
-1. Sign in to the [Azure portal](https://portal.azure.com) and browse to **Azure Active Directory**, **Authentication methods**, then **Password protection**.
+1. Sign in to the [Azure portal](https://portal.azure.com) and browse to **Azure Active Directory** > **Security** > **Authentication methods** > **Password protection**.
 1. Set the option **Enforce custom list**, to **Yes**.
 1. Add strings to the **Custom banned password list**, one string per line
    * The custom banned password list can contain up to 1000 terms.

articles/active-directory/authentication/howto-password-ban-bad-configure.md

@@ -25,7 +25,7 @@ Follow the guidance in the article [Configuring the custom banned password list]
 
 ## Enable Password Protection
 
-1. Sign in to the [Azure portal](https://portal.azure.com) and browse to **Azure Active Directory**, **Security**,**Authentication methods**, then **Password Protection**.
+1. Sign in to the [Azure portal](https://portal.azure.com) and browse to **Azure Active Directory** > **Security** > **Authentication methods** > **Password Protection**.
 1. Set **Enable Password Protection on Windows Server Active Directory** to **Yes**
 1. As mentioned in the [Deployment guide](howto-password-ban-bad-on-premises-deploy.md#deployment-strategy), it is recommended to initially set the **Mode** to **Audit**
    * After you are comfortable with the feature, you can switch the **Mode** to **Enforced**