Merge pull request #70788 from MicrosoftDocs/master

3/25 PM Publish

articles/active-directory-b2c/active-directory-b2c-reference-customize-ui-custom.md

@@ -147,7 +147,7 @@ The following table describes the purpose of the preceding HTML5 pages.
 
 You can add a link to your HTML5/CSS templates to your user journey by editing a custom policy directly.
 
-The custom HTML5/CSS templates to use in your user journey have to be specified in a list of content definitions that can be used in those user journeys. For that purpose, an optional *<ContentDefinitions>* XML element must be declared under the *<BuildingBlocks>* section of your custom policy XML file.
+The custom HTML5/CSS templates to use in your user journey have to be specified in a list of content definitions that can be used in those user journeys. For that purpose, an optional *\<ContentDefinitions>* XML element must be declared under the *\<BuildingBlocks>* section of your custom policy XML file.
 
 The following table describes the set of content definition IDs recognized by the Azure AD B2C identity experience engine and the type of pages that relates to them.
 

articles/active-directory-b2c/active-directory-b2c-reference-spa.md

@@ -23,7 +23,7 @@ Many modern apps have a single-page app front end that primarily is written in J
 
 To support these applications, Azure Active Directory B2C (Azure AD B2C) uses the OAuth 2.0 implicit flow. The OAuth 2.0 authorization implicit grant flow is described in [section 4.2 of the OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749). In implicit flow, the app receives tokens directly from the Azure Active Directory (Azure AD) authorize endpoint, without any server-to-server exchange. All authentication logic and session handling takes place entirely in the JavaScript client, without additional page redirects.
 
-Azure AD B2C extends the standard OAuth 2.0 implicit flow to more than simple authentication and authorization. Azure AD B2C introduces the [policy parameter](active-directory-b2c-reference-policies.md). With the policy parameter, you can use OAuth 2.0 to add policies to your app, such as sign-up, sign-in, and profile management user flows. In this article, we show you how to use the implicit flow and Azure AD to implement each of these experiences in your single-page applications. To help you get started, take a look at our [Node.js](https://github.com/Azure-Samples/active-directory-b2c-javascript-singlepageapp-nodejs-webapi) and [Microsoft .NET](https://github.com/Azure-Samples/active-directory-b2c-javascript-singlepageapp-dotnet-webapi) samples.
+Azure AD B2C extends the standard OAuth 2.0 implicit flow to more than simple authentication and authorization. Azure AD B2C introduces the [policy parameter](active-directory-b2c-reference-policies.md). With the policy parameter, you can use OAuth 2.0 to add policies to your app, such as sign-up, sign-in, and profile management user flows. In this article, we show you how to use the implicit flow and Azure AD to implement each of these experiences in your single-page applications.
 
 In the example HTTP requests in this article, we use our sample Azure AD B2C directory, **fabrikamb2c.onmicrosoft.com**. We also use our own sample application and user flows. You can try the requests yourself by using these values, or you can replace them with your own values.
 Learn how to [get your own Azure AD B2C directory, application, and user flows](#use-your-own-azure-ad-b2c-tenant).
@@ -272,8 +272,3 @@ To try these requests yourself, complete the following three steps. Replace the
 2. [Create an application](active-directory-b2c-app-registration.md) to obtain an application ID and a `redirect_uri` value. Include a web app or web API in your app. Optionally, you can create an application secret.
 3. [Create your user flows](active-directory-b2c-reference-policies.md) to obtain your user flow names.
 
-## Samples
-
-* [Create a single-page app by using Node.js](https://github.com/Azure-Samples/active-directory-b2c-javascript-singlepageapp-nodejs-webapi)
-* [Create a single-page app by using .NET](https://github.com/Azure-Samples/active-directory-b2c-javascript-singlepageapp-dotnet-webapi)
-

articles/active-directory-b2c/active-directory-b2c-setup-goog-app.md

@@ -8,7 +8,7 @@ manager: daveba
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 09/11/2018
+ms.date: 03/25/2019
 ms.author: davidmu
 ms.subservice: B2C
 ---
@@ -20,15 +20,13 @@ ms.subservice: B2C
 To use a Google account as an [identity provider](active-directory-b2c-reference-oauth-code.md) in Azure Active Directory (Azure AD) B2C, you need to create an application in your tenant that represents it. If you don’t already have a Google account you can get it at [https://accounts.google.com/SignUp](https://accounts.google.com/SignUp).
 
 1. Sign in to the [Google Developers Console](https://console.developers.google.com/) with your Google account credentials.
-2. Select **Create project**, and then click **Create**. If you have created projects before, select the project list, and then select **New Project**.
+2. In the upper-left corner of the page, select the project list, and then select **New Project**.
 3. Enter a **Project Name**, click **Create**, and then make sure you are using the new project.
-3. Select **Credentials** in the left menu, and then select **Create credentials** > **Oauth client ID**.
-4. Select **Configure consent screen**.
-5. Select or specify a valid **Email address**, provide a **Product name shown to users**, add `b2clogin.com` to **Authorized domains**, and click **Save**.
-6. Under **Application type**, select **Web application**.
-7. Enter a **Name** for your application, enter `https://your-tenant-name.b2clogin.com` in **Authorized JavaScript origins**, and `https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp` in **Authorized redirect URIs**. Replace `your-tenant-name` with the name of your tenant. You need to use all lowercase letters when entering your tenant name even if the tenant is defined with uppercase letters in Azure AD B2C.
-8. Click **Create**.
-9. Copy the values of **Client ID** and **Client secret**. You will need both of them to configure Google as an identity provider in your tenant. **Client secret** is an important security credential.
+4. Select **Credentials** in the left menu, and then select **Create credentials** > **Oauth client ID**.
+5. Under **Application type**, select **Web application**.
+6. Enter a **Name** for your application, enter `https://your-tenant-name.b2clogin.com` in **Authorized JavaScript origins**, and `https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp` in **Authorized redirect URIs**. Replace `your-tenant-name` with the name of your tenant. You need to use all lowercase letters when entering your tenant name even if the tenant is defined with uppercase letters in Azure AD B2C.
+7. Click **Create**.
+8. Copy the values of **Client ID** and **Client secret**. You will need both of them to configure Google as an identity provider in your tenant. **Client secret** is an important security credential.
 
 ## Configure a Google account as an identity provider
 

articles/active-directory-b2c/jwt-issuer-technical-profile.md

@@ -50,7 +50,7 @@ The **InputClaims**, **OutputClaims**, and **PersistClaims** elements are empty
 | rolling_refresh_token_lifetime_secs | No | Refresh token sliding window lifetime. After this time period elapses the user is forced to reauthenticate, irrespective of the validity period of the most recent refresh token acquired by the application. If you don't want to enforce a sliding window lifetime, set the value of allow_infinite_rolling_refresh_token to `true`. The default is 7,776,000 seconds (90 days). The minimum (inclusive) is 86,400 seconds (24 hours). The maximum (inclusive) is 31,536,000 seconds (365 days). | 
 | allow_infinite_rolling_refresh_token | No | If set to `true`, the refresh token sliding window lifetime never expires. |
 | IssuanceClaimPattern | Yes | Controls the Issuer (iss) claim. One of the values:<ul><li>AuthorityAndTenantGuid - The iss claim includes your domain name, such as `login.microsoftonline` or `tenant-name.b2clogin.com`, and your tenant identifier https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0/</li><li>AuthorityWithTfp - The iss claim includes your domain name, such as `login.microsoftonline` or `tenant-name.b2clogin.com`, your tenant identifier and your relying party policy name. https://login.microsoftonline.com/tfp/00000000-0000-0000-0000-000000000000/b2c_1a_tp_sign-up-or-sign-in/v2.0/</li></ul> | 
-| AuthenticationContextReferenceClaimPattern | No | Controls the `acr` claim value.<ul><li>None - Azure AD B2C doesn't issue the acr claim</li><li>PolicyId - the `acr` claim contains the policy name</li></ul>The options for setting this value are TFP (trust framework policy) and ACR (authentication context reference). It is recommended setting this value to TFP, to set the value, ensure the `<Item>` with the `Key="AuthenticationContextReferenceClaimPattern"` exists and the value is `None`. In your relying party policy, add <OutputClaims> item, add this element `<OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" />`. Also make sure your policy contains the claim type `<ClaimType Id="trustFrameworkPolicy">	<DisplayName>trustFrameworkPolicy</DisplayName>		<DataType>string</DataType>	</ClaimType>` | 
+| AuthenticationContextReferenceClaimPattern | No | Controls the `acr` claim value.<ul><li>None - Azure AD B2C doesn't issue the acr claim</li><li>PolicyId - the `acr` claim contains the policy name</li></ul>The options for setting this value are TFP (trust framework policy) and ACR (authentication context reference). It is recommended setting this value to TFP, to set the value, ensure the `<Item>` with the `Key="AuthenticationContextReferenceClaimPattern"` exists and the value is `None`. In your relying party policy, add `<OutputClaims>` item, add this element `<OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" />`. Also make sure your policy contains the claim type `<ClaimType Id="trustFrameworkPolicy">	<DisplayName>trustFrameworkPolicy</DisplayName>		<DataType>string</DataType>	</ClaimType>` | 
 
 ## Cryptographic keys
 

articles/active-directory/authentication/howto-mfa-reporting-datacollection.md

@@ -135,7 +135,7 @@ For MFA Server version 8.0 or higher the following process allows administrators
 - Log in to your MFA Server, navigate to the **Users** tab, select the user in question, and click the **Edit** button. Take screenshots (Alt-PrtScn) of each tab to provide the user their current MFA settings.
 - From the command line of the MFA Server, run the following command changing the path according to your installation `C:\Program Files\Multi-Factor Authentication Server\MultiFactorAuthGdpr.exe export <username>` to produce a JSON formatted file.
 - Administrators can also use the Web Service SDK GetUserGdpr operation as an option to export all MFA cloud service information collected for a given user or  incorporate into a larger reporting solution.
-- Search `C:\Program Files\Multi-Factor Authentication Server\Logs\MultiFactorAuthSvc.log` and any backups for “<username>” (include the quotes in the search) to find all instances of the user record being added or changed.
+- Search `C:\Program Files\Multi-Factor Authentication Server\Logs\MultiFactorAuthSvc.log` and any backups for “\<username>” (include the quotes in the search) to find all instances of the user record being added or changed.
    - These records can be limited (but not eliminated) by unchecking **“Log user changes”** in the MFA Server UX, Logging section, Log Files tab.
    - If syslog is configured, and **“Log user changes”** is checked in the MFA Server UX, Logging section, Syslog tab, then the log entries can be gathered from syslog instead.
 - Other occurrences of the username in MultiFactorAuthSvc.log and other MFA Server log files pertaining to authentication attempts are considered operational and duplicative to the information provided using MultiFactorAuthGdpr.exe export or Web Service SDK GetUserGdpr.

articles/active-directory/authentication/howto-password-ban-bad-on-premises-monitor.md

@@ -18,6 +18,8 @@ ms.collection: M365-identity-device-management
 
 After the deployment of Azure AD Password Protection, monitoring and reporting are essential tasks. This article goes into detail to help you understand various monitoring techniques, including where each service logs information and how to report on the use of Azure AD Password Protection.
 
+Monitoring and reporting are done either by event log messages or by running PowerShell cmdlets. The DC agent and proxy services both log event log messages. All PowerShell cmdlets described below are only available on the proxy server (see the AzureADPasswordProtection PowerShell module). The DC agent software does not install a PowerShell module.
+
 ## DC agent event logging
 
 On each domain controller, the DC agent service software writes the results of each individual password validation operation (and other status) to a local event log:

articles/active-directory/conditional-access/block-legacy-authentication.md

@@ -15,7 +15,7 @@ ms.devlang: na
 ms.topic: article
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 03/22/2019
+ms.date: 03/25/2019
 ms.author: markvi
 ms.reviewer: calebb
 
@@ -136,4 +136,6 @@ If you block legacy authentication using the other clients condition, you can al
 
 ## Next steps
 
-If you are not familiar with configuring conditional access policies yet, see [require MFA for specific apps with Azure Active Directory conditional access](app-based-mfa.md) for an example.
+- If you are not familiar with configuring conditional access policies yet, see [require MFA for specific apps with Azure Active Directory conditional access](app-based-mfa.md) for an example.
+
+- For more information about modern authentication support, see [How modern authentication works for Office 2013 and Office 2016 client apps](https://docs.microsoft.com/en-us/office365/enterprise/modern-auth-for-office-2013-and-2016) 

articles/active-directory/develop/active-directory-saml-protocol-reference.md

@@ -33,7 +33,7 @@ Azure AD uses the cloud service's **Metadata URI** to retrieve the signing key a
 
 Azure Active Directory exposes tenant-specific and common (tenant-independent) single sign-on and single sign-out endpoints. These URLs represent addressable locations -- they are not just identifiers -- so you can go to the endpoint to read the metadata.
 
-* The tenant-specific endpoint is located at `https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml`. The *<TenantDomainName>* placeholder represents a registered domain name or TenantID GUID of an Azure AD tenant. For example, the federation metadata of the contoso.com tenant is at: https://login.microsoftonline.com/contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
+* The tenant-specific endpoint is located at `https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml`. The *\<TenantDomainName>* placeholder represents a registered domain name or TenantID GUID of an Azure AD tenant. For example, the federation metadata of the contoso.com tenant is at: https://login.microsoftonline.com/contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
 
 * The tenant-independent endpoint is located at
   `https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml`. In this endpoint address, **common** appears instead of a tenant domain name or ID.

articles/active-directory/develop/active-directory-signing-key-rollover.md

@@ -274,15 +274,15 @@ Once you have followed these steps, your application’s Web.config will be upda
 
 Follow the steps below to verify that the key rollover logic is working.
 
-1. After you have verified that your application is using the code above, open the **Web.config** file and navigate to the **<issuerNameRegistry>** block, specifically looking for the following few lines:
+1. After you have verified that your application is using the code above, open the **Web.config** file and navigate to the **\<issuerNameRegistry>** block, specifically looking for the following few lines:
    ```
    <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
         <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
           <keys>
             <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
           </keys>
    ```
-2. In the **<add thumbprint="">** setting, change the thumbprint value by replacing any character with a different one. Save the **Web.config** file.
+2. In the **\<add thumbprint="">** setting, change the thumbprint value by replacing any character with a different one. Save the **Web.config** file.
 3. Build the application, and then run it. If you can complete the sign-in process, your application is successfully updating the key by downloading the required information from your directory’s federation metadata document. If you are having issues signing in, ensure the changes in your application are correct by reading the [Adding Sign-On to Your Web Application Using Azure AD](https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect) article, or downloading and inspecting the following code sample: [Multi-Tenant Cloud Application for Azure Active Directory](https://code.msdn.microsoft.com/multi-tenant-cloud-8015b84b).
 
 ### <a name="vs2010"></a>Web applications protecting resources and created with Visual Studio 2008 or 2010 and Windows Identity Foundation (WIF) v1.0 for .NET 3.5

articles/active-directory/develop/quickstart-v2-ios.md

@@ -41,7 +41,7 @@ This quickstart contains a code sample that demonstrates how a native iOS applic
 
 > [!div renderon="portal" class="sxs-lookup"]
 > #### Step 1: Configure your application
-> For the code sample for this quickstart to work, you need to add a reply URL as `msal<AppId>://auth` (where msal<AppId> is this application Id).
+> For the code sample for this quickstart to work, you need to add a reply URL as `msal<AppId>://auth` (where msal\<AppId> is this application Id).
 > > [!div renderon="portal" id="makechanges" class="nextstepaction"]
 > > [Make this change for me]()
 >
@@ -165,7 +165,7 @@ applicationContext.acquireToken(forScopes: self.kScopes) { (result, error) in /*
 
 > |Where:||
 > |---------|---------|
-> | `forScopes` | Contains the scopes being requested (that is, [ "user.read" ]` for Microsoft Graph or `[ "<Application ID URL>/scope" ]` for custom Web APIs (i.e. `api://<Application ID>/access_as_user`)) |
+> | `forScopes` | Contains the scopes being requested (that is, `[ "user.read" ]` for Microsoft Graph or `[ "<Application ID URL>/scope" ]` for custom Web APIs (i.e. `api://<Application ID>/access_as_user`)) |
 
 #### Getting an access token silently
 

articles/active-directory/develop/single-sign-on-saml-protocol.md

@@ -154,7 +154,7 @@ The `Response` element includes the result of the authorization request. Azure A
 
 ### Issuer
 
-Azure AD sets the `Issuer` element to `https://login.microsoftonline.com/<TenantIDGUID>/` where <TenantIDGUID> is the tenant ID of the Azure AD tenant.
+Azure AD sets the `Issuer` element to `https://login.microsoftonline.com/<TenantIDGUID>/` where \<TenantIDGUID> is the tenant ID of the Azure AD tenant.
 
 For example, a response with Issuer element could look like the following sample:
 
@@ -189,7 +189,7 @@ In addition to the `ID`, `IssueInstant` and `Version`, Azure AD sets the followi
 
 #### Issuer
 
-This is set to `https://sts.windows.net/<TenantIDGUID>/`where <TenantIDGUID> is the Tenant ID of the Azure AD tenant.
+This is set to `https://sts.windows.net/<TenantIDGUID>/`where \<TenantIDGUID> is the Tenant ID of the Azure AD tenant.
 
 ```
 <Issuer>https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer>

articles/active-directory/develop/single-sign-out-saml-protocol.md

@@ -68,7 +68,7 @@ Azure AD sends a `LogoutResponse` in response to a `LogoutRequest` element. The
 Azure AD sets the `ID`, `Version` and `IssueInstant` values in the `LogoutResponse` element. It also sets the `InResponseTo` element to the value of the `ID` attribute of the `LogoutRequest` that elicited the response.
 
 ### Issuer
-Azure AD sets this value to `https://login.microsoftonline.com/<TenantIdGUID>/` where <TenantIdGUID> is the tenant ID of the Azure AD tenant.
+Azure AD sets this value to `https://login.microsoftonline.com/<TenantIdGUID>/` where \<TenantIdGUID> is the tenant ID of the Azure AD tenant.
 
 To evaluate the value of the `Issuer` element, use the value of the **App ID URI** provided during application registration.