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

Author: KumudD

articles/active-directory-b2c/claimsproviders.md

@@ -48,7 +48,7 @@ The **ClaimsProvider** element contains the following child elements:
 | Element | Occurrences | Description |
 | ------- | ---------- | ----------- |
 | Domain | 0:1 | A string that contains the domain name for the claim provider. For example, if your claims provider includes the Facebook technical profile, the domain name is Facebook.com. This domain name is used for all technical profiles defined in the claims provider unless overridden by the technical profile. The domain name can also be referenced in a **domain_hint**. For more information, see the **Redirect sign-in to a social provider** section of [Set up direct sign-in using Azure Active Directory B2C](direct-signin.md). |
-| DisplayName | 0:1 | A string that contains the name of the claims provider that can be displayed to users. |
+| DisplayName | 1:1 | A string that contains the name of the claims provider that can be displayed to users. |
 | [TechnicalProfiles](technicalprofiles.md) | 0:1 | A set of technical profiles supported by the claim provider |
 
 **ClaimsProvider** organizes how your technical profiles relate to the claims provider. The following example shows the Azure Active Directory claims provider with the Azure Active Directory technical profiles:

articles/active-directory-domain-services/deploy-kcd.md

@@ -16,7 +16,7 @@ ms.author: iainfou
 ---
 # Configure Kerberos constrained delegation (KCD) in Azure Active Directory Domain Services
 
-As you run applications, there may be a need for those applications to access resources in the context of a different user. Active Directory Domain Services (AD DS) supports a mechanism called *Kerberos delegation* that enables this use-case. Kerberos *constrained* delegation (KCD) then builds on this mechanism to define specific resources that can be accessed in the context of the user. Azure Active Directory Domain Services (Azure AD DS) managed domains are more securely locked down that traditional on-premises AD DS environments, so use a more secure *resource-based* KCD.
+As you run applications, there may be a need for those applications to access resources in the context of a different user. Active Directory Domain Services (AD DS) supports a mechanism called *Kerberos delegation* that enables this use-case. Kerberos *constrained* delegation (KCD) then builds on this mechanism to define specific resources that can be accessed in the context of the user. Azure Active Directory Domain Services (Azure AD DS) managed domains are more securely locked down than traditional on-premises AD DS environments, so use a more secure *resource-based* KCD.
 
 This article shows you how to configure resource-based Kerberos constrained delegation in an Azure AD DS managed domain.
 

articles/active-directory/develop/TOC.yml

@@ -404,6 +404,8 @@
         href: active-directory-optional-claims.md
       - name: Configure token lifetimes
         href: active-directory-configurable-token-lifetimes.md
+      - name: Handle SameSite cookie changes in Chrome browser
+        href: howto-handle-samesite-cookie-changes-chrome-browser.md
     - name: Application configuration
       items:
       - name: New Azure portal app registration training guide

articles/active-directory/develop/howto-handle-samesite-cookie-changes-chrome-browser.md

@@ -0,0 +1,87 @@
+---
+title: How to handle SameSite cookie changes in Chrome browser | Azure
+titleSuffix: Microsoft identity platform
+description: Learn how to handle SameSite cookie changes in Chrome browser.
+services: active-directory
+documentationcenter: ''
+author: jmprieur
+manager: CelesteDG
+
+ms.service: active-directory
+ms.subservice: develop
+ms.workload: identity
+ms.topic: conceptual
+ms.date: 01/27/2020
+ms.author: jmprieur
+ms.reviewer: kkrishna
+ms.custom: aaddev
+---
+# Handle SameSite cookie changes in Chrome browser
+
+## What is SameSite?
+
+`SameSite` is a property that can be set in HTTP cookies to prevent Cross Site Request Forgery(CSRF) attacks in web applications:
+
+- When `SameSite` is set to **Lax**, the cookie is sent in requests within the same site and in GET requests from other sites. It isn't sent in GET requests that are cross-domain.
+- A value of **Strict** ensures that the cookie is sent in requests only within the same site.
+
+By default, the `SameSite` value is NOT set in browsers and that's why there are no restrictions on cookies being sent in requests. An application would need to opt-in to the CSRF protection by setting **Lax** or **Strict** per their requirements.
+
+## SameSite changes and impact on authentication
+
+Recent [updates to the standards on SameSite](https://tools.ietf.org/html/draft-west-cookie-incrementalism-00) propose protecting apps by making the default behavior of `SameSite` when no value is set to Lax. This mitigation means cookies will be restricted on HTTP requests except GET made from other sites. Additionally, a value of **None** is introduced to remove restrictions on cookies being sent. These updates will soon be released in an upcoming version of the Chrome browser.
+
+When web apps authenticate with the Microsoft Identity platform using the response mode "form_post", the login server responds to the application using an HTTP POST to send the tokens or auth code. Because this request is a cross-domain request (from `login.microsoftonline.com` to your domain - for instance https://contoso.com/auth), cookies that were set by your app now fall under the new rules in Chrome. The cookies that need to be used in cross-site scenarios are cookies that hold the *state* and *nonce* values, that are also sent in the login request. There are other cookies dropped by Azure AD to hold the session.
+
+If you don't update your web apps, this new behavior will result in authentication failures.
+
+## Mitigation and samples
+
+To overcome the authentication failures, web apps authenticating with the Microsoft identity platform can set the `SameSite` property to `None` for cookies that are used in cross-domain scenarios when running on the Chrome browser.
+Other browsers (see [here](https://www.chromium.org/updates/same-site/incompatible-clients) for a complete list) follow the previous behavior of `SameSite` and won't include the cookies if `SameSite=None` is set.
+That's why, to support authentication on multiple browsers web apps will have to set the `SameSite` value to `None` only on Chrome and leave the value empty on other browsers.
+
+This approach is demonstrated in our code samples below.
+
+# [.NET](#tab/dotnet)
+
+The table below presents the pull requests that worked around the SameSite changes in our ASP.NET and ASP.NET Core samples.
+
+| Sample | Pull request |
+| ------ | ------------ |
+|  [ASP.NET Core Web App incremental tutorial](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2)  |  [Same site cookie fix #261](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/pull/261)  |
+|  [ASP.NET MVC Web App sample](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect)  |  [Same site cookie fix #35](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect/pull/35)  |
+|  [active-directory-dotnet-admin-restricted-scopes-v2](https://github.com/azure-samples/active-directory-dotnet-admin-restricted-scopes-v2)  |  [Same site cookie fix #28](https://github.com/Azure-Samples/active-directory-dotnet-admin-restricted-scopes-v2/pull/28)  |
+
+for details on how to handle SameSite cookies in ASP.NET and ASP.NET Core, see also:
+
+- [Work with SameSite cookies in ASP.NET Core](https://docs.microsoft.com/aspnet/core/security/samesite) .
+- [ASP.NET Blog on SameSite issue](https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/)
+
+# [Python](#tab/python)
+
+| Sample |
+| ------ |
+|  [ms-identity-python-webapp](https://github.com/Azure-Samples/ms-identity-python-webapp)  |
+
+# [Java](#tab/java)
+
+| Sample | Pull request |
+| ------ | ------------ |
+|  [ms-identity-java-webapp](https://github.com/Azure-Samples/ms-identity-java-webapp)  | [Same site cookie fix #24](https://github.com/Azure-Samples/ms-identity-java-webapp/pull/24)
+|  [ms-identity-java-webapi](https://github.com/Azure-Samples/ms-identity-java-webapi)  | [Same site cookie fix #4](https://github.com/Azure-Samples/ms-identity-java-webapi/pull/4)
+
+---
+
+## Next steps
+
+Learn more about SameSite and the Web app scenario:
+
+> [!div class="nextstepaction"]
+> [Google Chrome's FAQ on SameSite](https://www.chromium.org/updates/same-site/faq)
+
+> [!div class="nextstepaction"]
+> [Chromium SameSite page](https://www.chromium.org/updates/same-site)
+
+> [!div class="nextstepaction"]
+> [Scenario: Web app that signs in users](scenario-web-app-sign-user-overview.md)

articles/active-directory/develop/scenario-web-app-sign-user-production.md

@@ -26,14 +26,21 @@ Now that you know how to get a token to call web APIs, learn how to move it to p
 
 ## Next steps
 
+### Same site
+
+Make sure you understand possible issues with new versions of the Chrome browser
+
+> [!div class="nextstepaction"]
+> [How to handle SameSite cookie changes in Chrome browser](howto-handle-samesite-cookie-changes-chrome-browser.md)
+
 ### Scenario for calling web APIs
 
 After your web app signs in users, it can call web APIs on behalf of the signed-in users. Calling web APIs from the web app is the object of the following scenario:
 
 > [!div class="nextstepaction"]
 > [Web app that calls web APIs](scenario-web-app-call-api-overview.md)
 
-### Deep dive: ASP.NET Core web app tutorial
+## Deep dive: ASP.NET Core web app tutorial
 
 Learn about other ways to sign in users with this ASP.NET Core tutorial: 
 
@@ -48,7 +55,7 @@ This progressive tutorial has production-ready code for a web app, including how
 - [Azure AD B2C](https://aka.ms/aadb2c)
 - National clouds
 
-### Sample code: Java web app
+## Sample code: Java web app
 
 Learn more about the Java web app from this sample on GitHub: 
 

articles/active-directory/develop/v2-protocols-oidc.md

@@ -71,7 +71,7 @@ The metadata is a simple JavaScript Object Notation (JSON) document. See the fol
 }
 ```
 
-If your app has custom signing keys as a result of using the [claims-mapping](active-directory-claims-mapping.md) feature, you must append an `appid` query parameter containing the app ID in order to get a `jwks_uri` pointing to your app's signing key information. For example: `https://login.microsoftonline.com/{tenant}/.well-known/v2.0/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e` contains a `jwks_uri` of `https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e`.
+If your app has custom signing keys as a result of using the [claims-mapping](active-directory-claims-mapping.md) feature, you must append an `appid` query parameter containing the app ID in order to get a `jwks_uri` pointing to your app's signing key information. For example: `https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e` contains a `jwks_uri` of `https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e`.
 
 Typically, you would use this metadata document to configure an OpenID Connect library or SDK; the library would use the metadata to do its work. However, if you're not using a pre-built OpenID Connect library, you can follow the steps in the remainder of this article to do sign-in in a web app by using the Microsoft identity platform endpoint.
 

articles/active-directory/hybrid/how-to-connect-sync-configure-filtering.md

@@ -293,7 +293,7 @@ Do the following steps:
 
 After the synchronization, all changes are staged to be exported. Before you actually make the changes in Azure AD, you want to verify that all these changes are correct.
 
-1. Start a command prompt, and go to `%Program Files%\Microsoft Azure AD Sync\bin`.
+1. Start a command prompt, and go to `%ProgramFiles%\Microsoft Azure AD Sync\bin`.
 2. Run `csexport "Name of Connector" %temp%\export.xml /f:x`.  
    The name of the Connector is in Synchronization Service. It has a name similar to "contoso.com – AAD" for Azure AD.
 3. Run `CSExportAnalyzer %temp%\export.xml > %temp%\export.csv`.

articles/active-directory/managed-identities-azure-resources/services-support-managed-identities.md

@@ -102,7 +102,7 @@ Managed identity type | All Generally Available<br>Global Azure Regions | Azure
 
 Refer to the following list to configure managed identity for Azure Logic Apps (in regions where available):
 
-- [Azure portal](/azure/logic-apps/create-managed-service-identity#azure-portal-system-logic-app)
+- [Azure portal](/azure/logic-apps/create-managed-service-identity#azure-portal)
 - [Azure Resource Manager template](/azure/app-service/overview-managed-identity)
 
 ### Azure Data Factory V2
@@ -154,6 +154,17 @@ Refer to the following list to configure managed identity for Azure Container Re
 
 - [Azure CLI](~/articles/container-registry/container-registry-tasks-authentication-managed-identity.md)
 
+### Azure Service Fabric
+[Managed Identity for Service Fabric Applications](https://docs.microsoft.com/azure/service-fabric/concepts-managed-identity) is in Preview and available in all regions.
+
+Managed identity type | All Generally Available<br>Global Azure Regions | Azure Government | Azure Germany | Azure China 21Vianet |
+| --- | --- | --- | --- | --- |
+| System assigned | Available | Not Available | Not Available | not Available |
+| User assigned | Available | Not Available | Not Available |Not Available |
+
+Refer to the following list to configure managed identity for Azure Service Fabric applications in all regions:
+- [Azure Resource Manager template](https://github.com/Azure-Samples/service-fabric-managed-identity/tree/anmenard-docs)
+
 ## Azure services that support Azure AD authentication
 
 The following services support Azure AD authentication, and have been tested with client services that use managed identities for Azure resources.

articles/active-directory/users-groups-roles/directory-assign-admin-roles.md

@@ -1716,7 +1716,7 @@ External Identity Provider Administrator | External Identity Provider Administra
 Global Reader | Global reader | f2ef992c-3afb-46b9-b7cf-a126ee74c451
 Group Administrator | Group administrator | fdd7a751-b60b-444a-984c-02652fe8fa1c 
 Guest Inviter | Guest inviter | 95e79109-95c0-4d8e-aee3-d01accf2d47b
-Helpdesk Administrator | Password administrator | 729827e3-9c14-49f7-bb1b-9608f156bbb8
+Helpdesk Administrator | Helpdesk administrator | 729827e3-9c14-49f7-bb1b-9608f156bbb8
 Intune Service Administrator | Intune administrator | 3a2c62db-5318-420d-8d74-23affee5d9d5
 Kaizala Administrator | Kaizala administrator | 74ef975b-6605-40af-a5d2-b9539d836353
 License Administrator | License administrator | 4d6ac14f-3453-41d0-bef9-a3e0c569773a

articles/app-service/configure-authentication-provider-aad.md

@@ -15,9 +15,6 @@ ms.custom: fasttrack-edit
 
 This article shows you how to configure Azure App Service to use Azure Active Directory (Azure AD) as an authentication provider.
 
-> [!NOTE]
-> At this time, Azure App Service and Azure Functions are only supported by Azure AD v1.0. They're not supported by the [Microsoft identity platform v2.0](https://docs.microsoft.com/azure/active-directory/develop/v2-overview), which includes Microsoft Authentication Libraries (MSAL).
-
 Follow these best practices when setting up your app and authentication:
 
 - Give each App Service app its own permissions and consent.