Merge branch 'main' into freshness-work

Author: vmagelo

.openpublishing.publish.config.json

@@ -386,6 +386,12 @@
       "branch": "main",
       "branch_mapping": {}
     },
+    {
+      "path_to_root": "azureml-examples-mavaisma-r-azureml",
+      "url": "https://github.com/azure/azureml-examples",
+      "branch": "mavaisma-r-azureml",
+      "branch_mapping": {}
+    },
     {
       "path_to_root": "azureml-examples-v2samplesreorg",
       "url": "https://github.com/azure/azureml-examples",

articles/active-directory-b2c/TOC.yml

@@ -66,7 +66,7 @@
     - name: Authentication library
       href: ../active-directory/develop/msal-overview.md?bc=%2fazure%2factive-directory-b2c%2fbread%2ftoc.json&toc=%2fazure%2factive-directory-b2c%2fTOC.json
       displayName: MSAL, client library, Microsoft Authentication Library
-  - name: Azure AD B2C global identitiy framework
+  - name: Azure AD B2C global identity framework
     items:
       - name: Global identity solutions
         href: azure-ad-b2c-global-identity-solutions.md

articles/active-directory/develop/TOC.yml

@@ -812,6 +812,8 @@
           href: reply-url.md
         - name: Validation differences by supported account types
           href: supported-accounts-validation.md
+        - name: Configured permissions limits troubleshooting
+          href: troubleshoot-required-resource-access-limits.md
     - name: Microsoft auth libraries by app type
       displayName: MSAL, auth client library, SDK, token validation
       href: reference-v2-libraries.md

articles/active-directory/develop/troubleshoot-required-resource-access-limits.md

@@ -0,0 +1,150 @@
+---
+title: Troubleshooting the configured permissions limits
+description: Learn why some apps may exceed the limits on configured permissions and how to address this issue.
+author: Jackson-Woods
+ms.author: jawoods
+manager: CelesteDG
+ms.date: 12/08/2022
+ms.topic: reference
+ms.subservice: develop
+ms.custom: aaddev
+ms.service: active-directory
+ms.reviewer: phsignor
+---
+
+# Troubleshooting the configured permissions limits
+
+The `RequiredResourceAccess` collection (RRA) on an application object contains all the configured API permissions that an app requires for its default consent request. This collection has various limits depending on which types of identities the app supports, For more information on the limits for supported account types, see [Validation differences by supported account types](supported-accounts-validation.md).
+
+The limits on maximum permissions were updated in May 2022, so some apps may have more permissions in their RRA than are now allowed. In addition, apps that change their supported account types after configuring permissions may exceed the limits of the new setting. When apps exceed the configured permissions limit, no new permissions may be added until the number of permissions in the `RequiredResourceAccess` collection is brought back under the limits.
+
+This document offers additional information and troubleshooting steps to resolve this issue.
+
+## Identifying when an app has exceeded the `RequiredResourceAccess` limits
+
+In general, all applications with more than 400 permissions have exceeded the configuration limits. Apps may also be subject to lower limits if they support sign-in for personal Microsoft accounts (MSA). An app that has exceeded the permission limits will receive the following error when trying to add more permissions in the Azure portal: 
+
+> `Failed to save permissions for <AppName>. This configuration exceeds the global application object limit. Remove some items and retry your request.`
+
+## Resolution steps
+
+If the application isn't needed anymore, the first option you should consider is to delete the app registration entirely. (You can restore recently deleted applications, in case you discover soon afterwards that it was still needed.)
+
+If you still need the application or are unsure, the following steps will help you resolve this issue:
+
+1. **Remove duplicate permissions.** In some cases, the same permission is listed multiple times. Review the required permissions and remove permissions that are listed two or more times. See the related PowerShell script on the [additional resources](#additional-resources) section of this article.
+2. **Remove unused permissions.** Review the permissions required by the application and compare them to what the application or service does. Remove permissions that are configured in the app registration, but which the application or service doesn’t require. For more information on how to review permissions, see [Review application permissions](../manage-apps/manage-application-permissions.md)
+3. **Remove redundant permissions.** In many APIs, including Microsoft Graph, some permissions aren't necessary when other more privileged permissions are included. For example, the Microsoft Graph permission User.Read.All (read all users) isn't needed when an application also has User.ReadWrite.All (read, create and update all users). To learn more about Microsoft Graph permissions, see [Microsoft Graph permissions reference](/graph/permissions-reference). 
+4. **Use multiple app registrations.** If a single app or service requires more than 400 permissions in the required permissions list, the app will need to be configured to use two (or more) different app registrations, each one with 400 or fewer permissions configured on the app registration. 
+
+## Frequently asked questions (FAQ)
+
+### *Why has Microsoft revised the limit on total permissions?*
+
+This limit is important for two reasons:
+
+- To help prevent an app from being configured to require more permissions than can be granted during consent.
+- To keep the total size of the app registration within the limits required for stability and performance of the underlying storage platform.
+
+### *What will happen if I don’t do anything?*
+
+If your app exceeds the total permissions limit, you'll no longer be able to increase the total number of required permissions for your application.
+
+### *Does the limit change how many permissions my application can be granted?*
+
+No. This limit affects only the list of requested API permissions configured on the app registration. This is different from the list of permissions that have been granted to your application.
+
+Even if it isn't listed in the required API permissions list, a delegated permission can still be requested dynamically by an application. Both delegated permissions and app roles (application permissions) can also be granted directly, using Microsoft Graph API or Microsoft Graph PowerShell.  
+
+### *Can the limit be raised for my application?*
+
+No, the limit can't be raised for individual applications or organizations. 
+
+### *Are there other limits on the list of required API permissions?*
+
+Yes. The limits can vary depending on the supported account types for the app. Apps that support personal Microsoft Accounts for sign-in (for example, Outlook.com, Hotmail.com, Xbox Live) generally have lower limits. See [Validation differences by supported account types](supported-accounts-validation.md) to learn more.
+
+## Additional resources
+
+Use the following PowerShell script to remove any duplicate permissions from your app registrations.
+
+```PowerShell
+<#
+.SYNOPSIS
+    Remove duplicate required API permissions from an app registration's required API permission list.
+.DESCRIPTION
+    This script ensures all API permissions listed in a Microsoft identity platform's app registration are only listed once,
+    removing any duplicates it finds. This script requires the Microsoft.Graph.Applications PowerShell module.
+.EXAMPLE
+     Get-MgApplication -Filter "appId eq '46c22aca-bcdd-467d-a837-bd544c09b8b4'" | .\Deduplicate_RequiredResourceAccess.ps1"
+.EXAMPLE
+     $apps = Get-MgApplication -Filter "startswith(displayName,'Test_app')"
+     $apps | .\Deduplicate_RequiredResourceAccess.ps1
+#>
+
+#Requires -Modules Microsoft.Graph.Applications
+
+[CmdletBinding()]
+param(
+    [Parameter(ValueFromPipeline = $true)]
+    $App
+)
+
+begin {
+    $context = Get-MgContext
+    if (-not $context) {
+        throw ("You must connect to Microsoft Graph PowerShell first, with sufficient permissions " +
+               "to manage Application objects. For example: Connect-MgGraph -Scopes ""Application.ReadWrite.All""")
+    }
+}
+
+process {
+    
+    # Build the unique list of required API permissions for each required API
+    $originalCount = 0
+    $tempRras = @{}
+    foreach ($rra in $App.RequiredResourceAccess) {
+        if (-not $tempRras.ContainsKey($rra.ResourceAppId)) {
+            $tempRras[$rra.ResourceAppId] = @{"Scope" = @{}; "Role" = @{}};
+        }
+        foreach ($ra in $rra.ResourceAccess) {
+            if ($tempRras[$rra.ResourceAppId][$ra.Type].ContainsKey($ra.Id)) {
+                # Skip duplicate required API permission
+            } else {
+                $tempRras[$rra.ResourceAppId][$ra.Type][$ra.Id] = $true
+            }
+            $originalCount++
+        }
+    }
+    
+    # Now that we have the unique set of required API permissions, iterate over all the keys to build the final requiredResourceAccess structure
+    $deduplicatedCount = 0
+    $finalRras = @($tempRras.Keys) | ForEach-Object {
+        $resourceAppId = $_
+        @{
+            "resourceAppId" = $resourceAppId
+            "resourceAccess" = @(@("Scope", "Role") | ForEach-Object { 
+                $type = $_
+                $tempRras[$resourceAppId][$type].Keys | ForEach-Object { 
+                    $deduplicatedCount++;
+                    @{"type" = $type; "id" = $_}
+                }
+            })
+        }
+    }
+    
+    $countDifference = $originalCount - $deduplicatedCount
+    if ($countDifference) {
+        Write-Host "Removing $($countDifference) duplicate entries in RequiredResourceAccess for '$($App.DisplayName)' (AppId: $($App.AppId))"
+        Update-MgApplication -ApplicationId $App.Id -RequiredResourceAccess $finalRras
+    } else {
+        Write-Host "No updates necessary for '$($App.DisplayName)' (AppId: $($App.AppId))"
+    }
+}
+```
+
+## Learn more
+
+- Learn about API permissions and the Microsoft identity platform: [Overview of permissions and consent in the Microsoft identity platform](permissions-consent-overview.md)
+- Understand the permissions available for Microsoft Graph: [Microsoft Graph permissions reference](/graph/permissions-reference)
+- Review the limitations to application configurations: [Validation differences by supported account types](supported-accounts-validation.md)

articles/active-directory/governance/TOC.yml

@@ -36,6 +36,8 @@
         href: entitlement-management-group-licenses.md
       - name: Onboard external users to Azure AD through an approval process
         href: entitlement-management-onboard-external-user.md
+      - name: Migrate an organizational role model
+        href: identity-governance-organizational-roles.md
     - name: Access Reviews
       items:
       - name: Review access to Microsoft 365 groups - Microsoft Graph

articles/active-directory/governance/entitlement-management-access-package-auto-assignment-policy.md

@@ -72,11 +72,11 @@ To create a policy for an access package, you need to start from the access pack
 
 There are two ways to create an access package assignment policy for automatic assignment programmatically, through Microsoft Graph and through the PowerShell cmdlets for Microsoft Graph.
 
-### Creating an access package assignment policy through Graph
+### Create an access package assignment policy through Graph
 
 You can create a policy using Microsoft Graph. A user in an appropriate role with an application that has the delegated `EntitlementManagement.ReadWrite.All` permission, or an application in a catalog role or with the `EntitlementManagement.ReadWrite.All` permission, can call the [create an accessPackageAssignmentPolicy](/graph/api/entitlementmanagement-post-assignmentpolicies?tabs=http&view=graph-rest-1.0&preserve-view=true) API. In your [request payload](/graph/api/resources/accesspackageassignmentpolicy?view=graph-rest-1.0&preserve-view=true), include the `displayName`, `description`, `specificAllowedTargets`, [`automaticRequestSettings`](/graph/api/resources/accesspackageautomaticrequestsettings?view=graph-rest-1.0&preserve-view=true) and `accessPackage` properties of the policy.
 
-### Creating an access package assignment policy through PowerShell
+### Create an access package assignment policy through PowerShell
 
 You can also create a policy in PowerShell with the cmdlets from the [Microsoft Graph PowerShell cmdlets for Identity Governance](https://www.powershellgallery.com/packages/Microsoft.Graph.Identity.Governance/) module version 1.16.0 or later.
 

articles/active-directory/governance/entitlement-management-access-package-create.md

@@ -132,11 +132,11 @@ On the **Review + create** tab, you can review your settings and check for any v
 
     The new access package appears in the list of access packages.
 
-## Creating an access package programmatically
+## Create an access package programmatically
 
 There are two ways to create an access package programmatically, through Microsoft Graph and through the PowerShell cmdlets for Microsoft Graph.
 
-### Creating an access package with Microsoft Graph
+### Create an access package with Microsoft Graph
 
 You can create an access package using Microsoft Graph. A user in an appropriate role with an application that has the delegated `EntitlementManagement.ReadWrite.All` permission can call the API to
 
@@ -147,7 +147,7 @@ You can create an access package using Microsoft Graph. A user in an appropriate
 1. [Create an accessPackageAssignmentPolicy](/graph/api/entitlementmanagement-post-accesspackageassignmentpolicies?tabs=http&view=graph-rest-beta&preserve-view=true) for each policy needed in the access package.
 
 
-### Creating an access package with Microsoft PowerShell
+### Create an access package with Microsoft PowerShell
 
 You can also create an access package in PowerShell with the cmdlets from the [Microsoft Graph PowerShell cmdlets for Identity Governance](https://www.powershellgallery.com/packages/Microsoft.Graph.Identity.Governance/) module version 1.16.0 or later.  This script illustrates using the Graph `beta` profile.
 
@@ -197,7 +197,7 @@ $rparams = @{
 New-MgEntitlementManagementAccessPackageResourceRoleScope -AccessPackageId $ap.Id -BodyParameter $rparams
 ```
 
-Finally, create the policies.  In this policy, only the administrator can assign access, and there are no access reviews.  See [create an assignment policy through PowerShell](entitlement-management-access-package-request-policy.md#creating-an-access-package-assignment-policy-through-powershell) and [create an accessPackageAssignmentPolicy](/graph/api/entitlementmanagement-post-assignmentpolicies?tabs=http&view=graph-rest-beta&preserve-view=true) for more examples.
+Finally, create the policies.  In this policy, only the administrator can assign access, and there are no access reviews.  See [create an assignment policy through PowerShell](entitlement-management-access-package-request-policy.md#create-an-access-package-assignment-policy-through-powershell) and [create an accessPackageAssignmentPolicy](/graph/api/entitlementmanagement-post-assignmentpolicies?tabs=http&view=graph-rest-beta&preserve-view=true) for more examples.
 
 ```powershell
 

articles/active-directory/governance/entitlement-management-access-package-request-policy.md

@@ -209,19 +209,19 @@ To change the request and approval settings for an access package, you need to o
 
 1. If you are editing a policy click **Update**. If you are adding a new policy, click **Create**.
 
-## Creating an access package assignment policy programmatically
+## Create an access package assignment policy programmatically
 
 There are two ways to create an access package assignment policy programmatically, through Microsoft Graph and through the PowerShell cmdlets for Microsoft Graph.
 
-### Creating an access package assignment policy through Graph
+### Create an access package assignment policy through Graph
 
 You can create a policy using Microsoft Graph. A user in an appropriate role with an application that has the delegated `EntitlementManagement.ReadWrite.All` permission, or an application in a catalog role or with the `EntitlementManagement.ReadWrite.All` permission, can call the [create an accessPackageAssignmentPolicy](/graph/api/entitlementmanagement-post-assignmentpolicies?tabs=http&view=graph-rest-1.0&preserve-view=true) API.
 
-### Creating an access package assignment policy through PowerShell
+### Create an access package assignment policy through PowerShell
 
 You can also create an access package in PowerShell with the cmdlets from the [Microsoft Graph PowerShell cmdlets for Identity Governance](https://www.powershellgallery.com/packages/Microsoft.Graph.Identity.Governance/) module version 1.16.0 or later.  
 
-This script below illustrates using the `beta` profile, to create a policy for direct assignment to an access package. In this policy, only the administrator can assign access, and there are no access reviews. See [Create an automatic assignment policy](entitlement-management-access-package-auto-assignment-policy.md#creating-an-access-package-assignment-policy-through-powershell) for an example of how to create an automatic assignment policy, and [create an accessPackageAssignmentPolicy](/graph/api/entitlementmanagement-post-assignmentpolicies?tabs=http&view=graph-rest-beta&preserve-view=true) for more examples.
+This script below illustrates using the `beta` profile, to create a policy for direct assignment to an access package. In this policy, only the administrator can assign access, and there are no access reviews. See [Create an automatic assignment policy](entitlement-management-access-package-auto-assignment-policy.md#create-an-access-package-assignment-policy-through-powershell) for an example of how to create an automatic assignment policy, and [create an accessPackageAssignmentPolicy](/graph/api/entitlementmanagement-post-assignmentpolicies?tabs=http&view=graph-rest-beta&preserve-view=true) for more examples.
 
 ```powershell
 Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"

articles/active-directory/governance/entitlement-management-delegate.md

@@ -25,11 +25,11 @@ ms.collection: M365-identity-device-management
 
 In Azure AD, you can use role models to manage access at scale through identity governance.
 
- * You can use access packages to represent organizational roles in your organization, such as "sales representative". An access package representing that enterprise role would include all the access rights that a sales representative might typically need, across multiple resources.
+ * You can use access packages to represent [organizational roles](identity-governance-organizational-roles.md) in your organization, such as "sales representative". An access package representing that organizational role would include all the access rights that a sales representative might typically need, across multiple resources.
  * Applications [can define their own roles](../develop/howto-add-app-roles-in-azure-ad-apps.md). For example, if you had a sales application, and that application included the app role "salesperson", you could then [include that role in an access package](entitlement-management-access-package-resources.md).
  * You can use roles for delegating administrative access.  If you have a catalog for all the access packages needed by sales, you could assign someone to be responsible for that catalog, by assigning them a catalog-specific role.
 
-This article discusses how to use roles to manage aspects within entitlement management.
+This article discusses how to use roles to manage aspects within Microsoft Entra entitlement management, for controlling access to the entitlement management resources.
 
 By default, Global administrators and Identity governance administrators can create and manage all aspects of entitlement management. However, the users in these roles may not know all the situations where access packages are required. Typically it's users within the respective departments, teams, or projects who know who they're collaborating with, using what resources, and for how long. Instead of granting unrestricted permissions to non-administrators, you can grant users the least permissions they need to do their job and avoid creating conflicting or inappropriate access rights.