Merge pull request #111911 from MicrosoftDocs/master

Merge master to live, 4 AM

Author: ttorble

.openpublishing.redirection.json

@@ -33548,8 +33548,13 @@
     },
     {
       "source_path": "articles/active-directory/pim-azure-resource.md",
-      "redirect_url": "/azure/role-based-access-control/pim-azure-resource",
-      "redirect_document_id": true
+      "redirect_url": "/azure/role-based-access-control/best-practices",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "articles/role-based-access-control/pim-azure-resource.md",
+      "redirect_url": "/azure/role-based-access-control/best-practices",
+      "redirect_document_id": false
     },
     {
       "source_path": "articles/active-directory/role-based-access-control-resource-provider-operations.md",

articles/active-directory/app-provisioning/application-provisioning-config-problem-no-users-provisioned.md

@@ -1,5 +1,5 @@
 ---
-title: No users are being provisioned to an Azure AD Gallery application
+title: Users are not being provisioned in my application
 description: How to troubleshoot common issues faced when you don't see users appearing in an Azure AD Gallery Application you have configured for user provisioning with Azure AD
 services: active-directory
 documentationcenter: ''
@@ -12,19 +12,23 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: conceptual
-ms.date: 09/03/2019
+ms.date: 04/20/2020
 ms.author: mimart
 ms.reviewer: arvinh
 ms.collection: M365-identity-device-management
 ---
 
-# No users are being provisioned to an Azure AD Gallery application
+# No users are being provisioned 
+>[!NOTE]
+>Starting 04/16/2020 we have changed the behavior for users assigned the default access role. Please see the section below for details. 
+>
 After automatic provisioning has been configured for an application (including verifying that the app credentials provided to Azure AD to connect to the app are valid), then users and/or groups are provisioned to the app. Provisioning is determined by the following things:
 
 -   Which users and groups have been **assigned** to the application. Note that provisioning nested groups or Office 365 groups is not supported. For more information on assignment, see [Assign a user or group to an enterprise app in Azure Active Directory](../manage-apps/assign-user-or-group-access-portal.md).
 -   Whether or not **attribute mappings** are enabled, and configured to sync valid attributes from Azure AD to the app. For more information on attribute mappings, see [Customizing User Provisioning Attribute Mappings for SaaS Applications in Azure Active Directory](customize-application-attributes.md).
 -   Whether or not there is a **scoping filter** present that is filtering users based on specific attribute values. For more information on scoping filters, see [Attribute-based application provisioning with scoping filters](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).
 
+  
 If you observe that users are not being provisioned, consult the [Provisioning logs (preview)](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context) in Azure AD. Search for log entries for a specific user.
 
 You can access the provisioning logs in the Azure portal by selecting **Azure Active Directory** > **Enterprise Apps** > **Provisioning logs (preview)** in the **Activity** section. You can search the provisioning data based on the name of the user or the identifier in either the source system or the target system. For details, see [Provisioning logs (preview)](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context). 
@@ -53,7 +57,16 @@ When a user shows up as “skipped” in the provisioning logs, it is important
 - **The user is “not effectively entitled”.** If you see this specific error message, it is because there is a problem with the user assignment record stored in Azure AD. To fix this issue, unassign the user (or group) from the app, and reassign it again. For more information on assignment, see [Assign user or group access](../manage-apps/assign-user-or-group-access-portal.md).
 - **A required attribute is missing or not populated for a user.** An important thing to consider when setting up provisioning is to review and configure the attribute mappings and workflows that define which user (or group) properties flow from Azure AD to the application. This configuration includes setting the “matching property” that is used to uniquely identify and match users/groups between the two systems. For more information on this important process, see [Customizing User Provisioning Attribute Mappings for SaaS Applications in Azure Active Directory](customize-application-attributes.md).
 - **Attribute mappings for groups:** Provisioning of the group name and group details, in addition to the members, if supported for some applications. You can enable or disable this functionality by enabling or disabling the **Mapping** for group objects shown in the **Provisioning** tab. If provisioning groups is enabled, be sure to review the attribute mappings to ensure an appropriate field is being used for the “matching ID”. The matching ID can be the display name or email alias. The group and its members are not provisioned if the matching property is empty or not populated for a group in Azure AD.
+## Provisioning users assigned to the default access role
+The default role on an application from the gallery is called the "default access" role. Historically, users assigned to this role are not provisioned and are marked as skipped in the [provisioning logs](https://docs.microsoft.com/azure/active-directory/reports-monitoring/concept-provisioning-logs) due to being "not effectively entitled." 
+
+**Behavior for provisioning configurations created after 04/16/2020:**
+Users assigned to the default access role will be evaluated the same as all other roles. A user that is assigned the default access will not be skipped as "not effectively entitled." 
+
+**Behavior for provisioning configurations created before 04/16/2020:**
+For the next 3 months, the behavior will continue as it is today. Users with the default access role will be skipped as not effectively entitled. After July 2020, the behavior will be uniform for all applications. We will not skip provisioning users with the default access role due to being "not effectively entitled." This change will be made by Microsoft, with no customer action required. If you would like to ensure that these users continue to be skipped, even after this change, please apply the appropriate scoping filters or unassign the user from the application to ensure they are out of scope.  
 
+For questions about these changes, please reach out to [email protected]
 ## Next steps
 
 [Azure AD Connect sync: Understanding Declarative Provisioning](../hybrid/concept-azure-ad-connect-sync-declarative-provisioning.md)

articles/active-directory/develop/active-directory-configurable-token-lifetimes.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 02/19/2020
+ms.date: 04/17/2020
 ms.author: ryanwi
 ms.custom: aaddev, identityplatformtop40
 ms.reviewer: hirsin, jlu, annaba
@@ -240,19 +240,25 @@ In this example, you create a policy that lets your users' sign in less frequent
         }')
         ```
 
-    2. To create the policy, run the following command:
+    1. To create the policy, run the following command:
 
         ```powershell
         $policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1, "MaxAgeSingleFactor":"until-revoked"}}') -DisplayName "OrganizationDefaultPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
         ```
 
-    3. To see your new policy, and to get the policy's **ObjectId**, run the following command:
+    1. To remove any whitespace, run the following command:
+
+        ```powershell
+        Get-AzureADPolicy -id | set-azureadpolicy -Definition @($((Get-AzureADPolicy -id ).Replace(" ","")))
+        ```
+
+    1. To see your new policy, and to get the policy's **ObjectId**, run the following command:
 
         ```powershell
         Get-AzureADPolicy -Id $policy.Id
         ```
 
-2. Update the policy.
+1. Update the policy.
 
     You might decide that the first policy you set in this example is not as strict as your service requires. To set your Single-Factor Refresh Token to expire in two days, run the following command:
 
@@ -274,21 +280,21 @@ In this example, you create a policy that requires users to authenticate more fr
         $policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00","MaxAgeSessionSingleFactor":"02:00:00"}}') -DisplayName "WebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
         ```
 
-    2. To see your new policy, and to get the policy **ObjectId**, run the following command:
+    1. To see your new policy, and to get the policy **ObjectId**, run the following command:
 
         ```powershell
         Get-AzureADPolicy -Id $policy.Id
         ```
 
-2. Assign the policy to your service principal. You also need to get the **ObjectId** of your service principal.
+1. Assign the policy to your service principal. You also need to get the **ObjectId** of your service principal.
 
     1. Use the [Get-AzureADServicePrincipal](/powershell/module/azuread/get-azureadserviceprincipal) cmdlet to see all your organization's service principals or a single service principal.
         ```powershell
         # Get ID of the service principal
         $sp = Get-AzureADServicePrincipal -Filter "DisplayName eq '<service principal display name>'"
         ```
 
-    2. When you have the service principal, run the following command:
+    1. When you have the service principal, run the following command:
         ```powershell
         # Assign policy to a service principal
         Add-AzureADServicePrincipalPolicy -Id $sp.ObjectId -RefObjectId $policy.Id
@@ -305,13 +311,13 @@ In this example, you create a policy that requires users to authenticate less fr
         $policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxInactiveTime":"30.00:00:00","MaxAgeMultiFactor":"until-revoked","MaxAgeSingleFactor":"180.00:00:00"}}') -DisplayName "WebApiDefaultPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
         ```
 
-    2. To see your new policy, run the following command:
+    1. To see your new policy, run the following command:
 
         ```powershell
         Get-AzureADPolicy -Id $policy.Id
         ```
 
-2. Assign the policy to your web API. You also need to get the **ObjectId** of your application. Use the [Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) cmdlet to find your app's **ObjectId**, or use the [Azure portal](https://portal.azure.com/).
+1. Assign the policy to your web API. You also need to get the **ObjectId** of your application. Use the [Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) cmdlet to find your app's **ObjectId**, or use the [Azure portal](https://portal.azure.com/).
 
     Get the **ObjectId** of your app and assign the policy:
 
@@ -334,19 +340,19 @@ In this example, you create a few policies to learn how the priority system work
         $policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSingleFactor":"30.00:00:00"}}') -DisplayName "ComplexPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
         ```
 
-    2. To see your new policy, run the following command:
+    1. To see your new policy, run the following command:
 
         ```powershell
         Get-AzureADPolicy -Id $policy.Id
         ```
 
-2. Assign the policy to a service principal.
+1. Assign the policy to a service principal.
 
     Now, you have a policy that applies to the entire organization. You might want to preserve this 30-day policy for a specific service principal, but change the organization default policy to the upper limit of "until-revoked."
 
     1. To see all your organization's service principals, you use the [Get-AzureADServicePrincipal](/powershell/module/azuread/get-azureadserviceprincipal) cmdlet.
 
-    2. When you have the service principal, run the following command:
+    1. When you have the service principal, run the following command:
 
         ```powershell
         # Get ID of the service principal
@@ -356,13 +362,13 @@ In this example, you create a few policies to learn how the priority system work
         Add-AzureADServicePrincipalPolicy -Id $sp.ObjectId -RefObjectId $policy.Id
         ```
 
-3. Set the `IsOrganizationDefault` flag to false:
+1. Set the `IsOrganizationDefault` flag to false:
 
     ```powershell
     Set-AzureADPolicy -Id $policy.Id -DisplayName "ComplexPolicyScenario" -IsOrganizationDefault $false
     ```
 
-4. Create a new organization default policy:
+1. Create a new organization default policy:
 
     ```powershell
     New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSingleFactor":"until-revoked"}}') -DisplayName "ComplexPolicyScenarioTwo" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"

articles/active-directory/managed-identities-azure-resources/TOC.yml

@@ -136,13 +136,13 @@
   - name: Java
     href: https://github.com/Azure/azure-libraries-for-java#ready-to-run-code-samples-for-virtual-machines
   - name: Python
-    href: /python/api/azure.mgmt.msi
+    href: https://docs.microsoft.com/windows/python/
   - name: Ruby
     href: https://rubygems.org/gems/azure_mgmt_msi
   - name: Node.js
-    href: /javascript/api/ms-rest-azure
+    href: https://nodejs.org/en/docs/
   - name: Go
-    href: https://godoc.org/github.com/Azure/azure-sdk-for-go/services/msi/mgmt/2015-08-31-preview/msi
+    href: https://golang.org/doc/
 
 - name: Resources
   items:

articles/active-directory/managed-identities-azure-resources/overview.md

@@ -12,7 +12,7 @@ ms.subservice: msi
 ms.devlang:
 ms.topic: overview
 ms.custom: mvc
-ms.date: 03/25/2020
+ms.date: 04/18/2020
 ms.author: markvi
 
 #As a developer, I'd like to securely manage the credentials that my application uses for authenticating to cloud services without having the credentials in my code or checked into source control.