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

Author: jpconnock

.gitignore

@@ -22,5 +22,5 @@ articles/directories.txt
 AzureMigration.ps1
 
 !/.vscode/extensions.json
-articles/data-lake-analytics/.vscode/settings.json
 .gitignore
+**/.vscode/settings.json

.openpublishing.redirection.json

@@ -5705,6 +5705,11 @@
       "redirect_url": "/azure/connectors/connectors-create-api-sharepoint",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/connectors/connectors-native-query.md",
+      "redirect_url": "/azure/logic-apps/logic-apps-perform-data-operations#filter-array-action",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/logic-apps/logic-apps-enterprise-integration-as2-encode.md",
       "redirect_url": "/azure/logic-apps/logic-apps-enterprise-integration-as2",
@@ -43236,7 +43241,7 @@
     },
     {
       "source_path": "articles/iot-central/howto-connect-devkit.md",
-      "redirect_url": "/azure/iot-central/core/howto-connect-devki/t",
+      "redirect_url": "/azure/iot-central/core/howto-connect-devkit/",
       "redirect_document_id": true
     },
     {

articles/active-directory/develop/v2-oauth2-on-behalf-of-flow.md

@@ -14,7 +14,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: conceptual
-ms.date: 11/19/2019
+ms.date: 1/3/2020
 ms.author: ryanwi
 ms.reviewer: hirsin
 ms.custom: aaddev
@@ -31,22 +31,22 @@ This article describes how to program directly against the protocol in your appl
 
 > [!NOTE]
 >
-> - The Microsoft identity platform endpoint doesn't support all scenarios and features. To determine whether you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md). Specifically, known client applications aren't supported for apps with Microsoft account (MSA) and Azure AD audiences. Thus, a common consent pattern for OBO will not work for clients that sign in both personal and work or school accounts. To learn more about how to handle this step of the flow, see [Gaining consent for the middle-tier application](#gaining-consent-for-the-middle-tier-application).
+> - The Microsoft identity platform endpoint doesn't support all scenarios and features. To determine whether you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md). 
 > - As of May 2018, some implicit-flow derived `id_token` can't be used for OBO flow. Single-page apps (SPAs) should pass an **access** token to a middle-tier confidential client to perform OBO flows instead. For more info about which clients can perform OBO calls, see [limitations](#client-limitations).
 
 ## Protocol diagram
 
-Assume that the user has been authenticated on an application using the [OAuth 2.0 authorization code grant flow](v2-oauth2-auth-code-flow.md). At this point, the application has an access token *for API A* (token A) with the user’s claims and consent to access the middle-tier web API (API A). Now, API A needs to make an authenticated request to the downstream web API (API B).
+Assume that the user has been authenticated on an application using the [OAuth 2.0 authorization code grant flow](v2-oauth2-auth-code-flow.md) or another login flow. At this point, the application has an access token *for API A* (token A) with the user’s claims and consent to access the middle-tier web API (API A). Now, API A needs to make an authenticated request to the downstream web API (API B).
 
 The steps that follow constitute the OBO flow and are explained with the help of the following diagram.
 
 ![Shows the OAuth2.0 On-Behalf-Of flow](./media/v2-oauth2-on-behalf-of-flow/protocols-oauth-on-behalf-of-flow.png)
 
 1. The client application makes a request to API A with token A (with an `aud` claim of API A).
 1. API A authenticates to the Microsoft identity platform token issuance endpoint and requests a token to access API B.
-1. The Microsoft identity platform token issuance endpoint validates API A's credentials with token A and issues the access token for API B (token B).
-1. Token B is set in the authorization header of the request to API B.
-1. Data from the secured resource is returned by API B.
+1. The Microsoft identity platform token issuance endpoint validates API A's credentials along with token A and issues the access token for API B (token B) to API A.
+1. Token B is set by API A in the authorization header of the request to API B.
+1. Data from the secured resource is returned by API B to API A, and from there to the client.
 
 > [!NOTE]
 > In this scenario, the middle-tier service has no user interaction to obtain the user's consent to access the downstream API. Therefore, the option to grant access to the downstream API is presented upfront as a part of the consent step during authentication. To learn how to set this up for your app, see [Gaining consent for the middle-tier application](#gaining-consent-for-the-middle-tier-application).
@@ -70,7 +70,7 @@ When using a shared secret, a service-to-service access token request contains t
 | `grant_type` | Required | The type of  token request. For a request using a JWT, the value must be `urn:ietf:params:oauth:grant-type:jwt-bearer`. |
 | `client_id` | Required | The application (client) ID that [the Azure portal - App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) page has assigned to your app. |
 | `client_secret` | Required | The client secret that you generated for your app in the Azure portal - App registrations page. |
-| `assertion` | Required | The value of the token used in the request. |
+| `assertion` | Required | The value of the token used in the request.  This token must have an audience of the app making this OBO request (the app denoted by the `client-id` field). |
 | `scope` | Required | A space separated list of scopes for the token request. For more information, see [scopes](v2-permissions-and-consent.md). |
 | `requested_token_use` | Required | Specifies how the request should be processed. In the OBO flow, the value must be set to `on_behalf_of`. |
 
@@ -157,7 +157,7 @@ The following example shows a success response to a request for an access token
 ```
 
 > [!NOTE]
-> The above access token is a v1.0-formatted token. This is because the token is provided based on the resource being accessed. The Microsoft Graph requests v1.0 tokens, so Microsoft identity platform produces v1.0 access tokens when a client requests tokens for Microsoft Graph. Only applications should look at access tokens. Clients should not need to inspect them.
+> The above access token is a v1.0-formatted token. This is because the token is provided based on the **resource** being accessed. The Microsoft Graph is setup to accept v1.0 tokens, so Microsoft identity platform produces v1.0 access tokens when a client requests tokens for Microsoft Graph. Only applications should look at access tokens. Clients **must not** inspect them.
 
 ### Error response example
 
@@ -189,29 +189,24 @@ Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQTZOVG
 
 ## Gaining consent for the middle-tier application
 
-Depending on the audience for your application, you may consider different strategies for ensuring that the OBO flow is successful. In all cases, the ultimate goal is to ensure proper consent is given. How that occurs, however, depends on which users your application supports.
-
-### Consent for Azure AD-only applications
+Depending on the architecture or usage of your application, you may consider different strategies for ensuring that the OBO flow is successful. In all cases, the ultimate goal is to ensure proper consent is given so that the client app can call the middle-tier app, and the middle tier app has permission to call the back-end resource. 
 
-#### /.default and combined consent
+> [!NOTE]
+> Previously the Microsoft account system (personal accounts) did not support the "Known client application" field, nor could it show combined consent.  This has been added and all apps in the Microsoft identity platform can use the known client application approach for gettign consent for OBO calls. 
 
-For applications that only need to sign in work or school accounts, the traditional "Known Client Applications" approach is sufficient. The middle tier application adds the client to the known client applications list in its manifest, and then the client can trigger a combined consent flow for both itself and the middle tier application. On the Microsoft identity platform endpoint, this is done using the [`/.default` scope](v2-permissions-and-consent.md#the-default-scope). When triggering a consent screen using known client applications and `/.default`, the consent screen will show permissions for both the client to the middle tier API, and also request whatever permissions are required by the middle-tier API. The user provides consent for both applications, and then the OBO flow works.
+### /.default and combined consent
 
-At this time, the personal Microsoft account system does not support combined consent and so this approach does not work for apps that want to specifically sign in personal accounts. Personal Microsoft accounts being used as guest accounts in a tenant are handled using the Azure AD system, and can go through combined consent.
+The middle tier application adds the client to the known client applications list in its manifest, and then the client can trigger a combined consent flow for both itself and the middle tier application. On the Microsoft identity platform endpoint, this is done using the [`/.default` scope](v2-permissions-and-consent.md#the-default-scope). When triggering a consent screen using known client applications and `/.default`, the consent screen will show permissions for **both** the client to the middle tier API, and also request whatever permissions are required by the middle-tier API. The user provides consent for both applications, and then the OBO flow works.
 
-#### Pre-authorized applications
+### Pre-authorized applications
 
-A feature of the application portal is "pre-authorized applications". In this way, a resource can indicate that a given application always has permission to receive certain scopes. This is primarily useful to make connections between a front-end client and a back-end resource more seamless. A resource can declare multiple pre-authorized applications - any such application can request these permissions in an OBO flow and receive them without the user providing consent.
+Resources can indicate that a given application always has permission to receive certain scopes. This is primarily useful to make connections between a front-end client and a back-end resource more seamless. A resource can declare multiple pre-authorized applications - any such application can request these permissions in an OBO flow and receive them without the user providing consent.
 
-#### Admin consent
+### Admin consent
 
 A tenant admin can guarantee that applications have permission to call their required APIs by providing admin consent for the middle tier application. To do this, the admin can find the middle tier application in their tenant, open the required permissions page, and choose to give permission for the app. To learn more about admin consent, see the [consent and permissions documentation](v2-permissions-and-consent.md).
 
-### Consent for Azure AD + Microsoft account applications
-
-Because of restrictions in the permissions model for personal accounts and the lack of a governing tenant, the consent requirements for personal accounts are a bit different from Azure AD. There is no tenant to provide tenant-wide consent for, nor is there the ability to do combined consent. Thus, other strategies present themselves - note that these work for applications that only need to support Azure AD accounts as well.
-
-#### Use of a single application
+### Use of a single application
 
 In some scenarios, you may only have a single pairing of middle-tier and front-end client. In this scenario, you may find it easier to make this a single application, negating the need for a middle-tier application altogether. To authenticate between the front-end and the web API, you can use cookies, an id_token, or an access token requested for the application itself. Then, request consent from this single application to the back-end resource.
 

articles/active-directory/devices/troubleshoot-hybrid-join-windows-current.md

@@ -101,7 +101,7 @@ This field indicates whether the device is registered with Azure AD as a persona
 
 #### AzureAdJoined : YES  
 
-This field indicates whether the device is joined with Azure AD. 
+This field indicates whether the device is joined. The value will be **YES** if the device is either an Azure AD joined device or a hybrid Azure AD joined device.
 If the value is **NO**, the join to Azure AD has not completed yet. 
 
 Proceed to next steps for further troubleshooting.

articles/active-directory/manage-apps/application-provisioning-when-will-provisioning-finish-specific-user.md

@@ -32,7 +32,7 @@ When you first configure automatic provisioning, the **Current Status** section
 - The type of provisioning cycle (initial or incremental) that is currently running or was last completed.
 - A **progress bar** showing the percentage of the provisioning cycle that has completed. The percentage reflects the count of pages provisioned. Note that each page could contain multiple users or groups, so the percentage doesn't directly correlate to the number of users, groups, or roles provisioned.
 - A **Refresh** button you can use to keep the view updated.
-- The number of **Users** and **Groups** provisioned, and the number of roles created. During the initial cycle, the **Users** number counts up by 1 when a user is created or updated, and it counts down by 1 when a user is deleted. During an incremental cycle, user updates don’t affect the **Users** count; the number changes only when users are created or deleted.
+- The number of **Users** and **Groups** in the connector data store. The count increases anytime an object is added to the scope of provisioning. The count will not go down if a user is soft-deleted or hard-deleted as this does not remove the object from the connector data store. The count will be re-caculated the first sync after the CDS is [reset](https://docs.microsoft.com/graph/api/synchronization-synchronizationjob-restart?view=graph-rest-beta&tabs=http) 
 - A **View Audit Logs** link, which opens the Azure AD provisioning logs for details about all operations run by the user provisioning service, including provisioning status for individual users (see the [Use provisioning logs](#use-provisioning-logs-to-check-a-users-provisioning-status) section below).
 
 After a provisioning cycle is complete, the **Statistics to date** section shows the cumulative numbers of users and groups that have been provisioned to date, along with the completion date and duration of the last cycle. The **Activity ID** uniquely identifies the most recent provisioning cycle. The **Job ID** is a unique identifier for the provisioning job, and is specific to the app in your tenant.

articles/active-directory/saas-apps/amazon-web-service-tutorial.md

@@ -71,10 +71,10 @@ In this tutorial, you configure and test Azure AD SSO in a test environment.
 
 To configure the integration of Amazon Web Services (AWS) into Azure AD, you need to add Amazon Web Services (AWS) from the gallery to your list of managed SaaS apps.
 
-1. Sign in to the [Azure portal](https://portal.azure.com) using either a work or school account, or a personal Microsoft account.
-1. On the left navigation pane, select the **Azure Active Directory** service.
-1. Navigate to **Enterprise Applications** and then select **All Applications**.
-1. To add new application, select **New application**.
+1. Sign in to the [Azure portal](https://portal.azure.com) using a work account, school account, or personal Microsoft account.
+1. In the Azure portal, search for and select **Azure Active Directory**.
+1. Within the Azure Active Directory overview menu, choose **Enterprise Applications** > **All applications**.
+1. Select **New application** to add an application.
 1. In the **Add from the gallery** section, type **Amazon Web Services (AWS)** in the search box.
 1. Select **Amazon Web Services (AWS)** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.
 
@@ -120,7 +120,8 @@ Follow these steps to enable Azure AD SSO in the Azure portal.
 
 In this section, you'll create a test user in the Azure portal called B.Simon.
 
-1. From the left pane in the Azure portal, select **Azure Active Directory**, select **Users**, and then select **All users**.
+1. In the Azure portal, search for and select **Azure Active Directory**.
+1. Within the Azure Active Directory overview menu, choose **Users** > **All users**.
 1. Select **New user** at the top of the screen.
 1. In the **User** properties, follow these steps:
    1. In the **Name** field, enter `B.Simon`.  
@@ -132,8 +133,9 @@ In this section, you'll create a test user in the Azure portal called B.Simon.
 
 In this section, you'll enable B.Simon to use Azure single sign-on by granting access to Amazon Web Services (AWS).
 
-1. In the Azure portal, select **Enterprise Applications**, and then select **All applications**.
-1. In the applications list, select **Amazon Web Services (AWS)**.
+1. In the Azure portal, search for and select **Azure Active Directory**.
+1. Within the Azure Active Directory overview menu, choose **Enterprise Applications** > **All applications**.
+1. In the application list, select **Amazon Web Services (AWS)**.
 1. In the app's overview page, find the **Manage** section and select **Users and groups**.
 
    ![The "Users and groups" link](common/users-groups-blade.png)