Merge pull request #249983 from MicrosoftDocs/main

Merge main to live, 4 AM

Author: v-ccolin

articles/active-directory/develop/reference-error-codes.md

@@ -111,6 +111,7 @@ The `error` field has several possible values - review the protocol documentatio
 | AADSTS50015 | ViralUserLegalAgeConsentRequiredState - The user requires legal age group consent. |
 | AADSTS50017 | CertificateValidationFailed - Certification validation failed, reasons for the following reasons:<ul><li>Cannot find issuing certificate in trusted certificates list</li><li>Unable to find expected CrlSegment</li><li>Cannot find issuing certificate in trusted certificates list</li><li>Delta CRL distribution point is configured without a corresponding CRL distribution point</li><li>Unable to retrieve valid CRL segments because of a timeout issue</li><li>Unable to download CRL</li></ul>Contact the tenant admin. |
 | AADSTS50020 | UserUnauthorized - Users are unauthorized to call this endpoint. User account '{email}' from identity provider '{idp}' does not exist in tenant '{tenant}' and cannot access the application '{appid}'({appName}) in that tenant. This account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account. If this user should be a member of the tenant, they should be invited via the [B2B system](/azure/active-directory/b2b/add-users-administrator). For additional information, visit [AADSTS50020](/troubleshoot/azure/active-directory/error-code-aadsts50020-user-account-identity-provider-does-not-exist). |
+| AADSTS500208 | The domain is not a valid login domain for the account type - This situation occurs when the user's account does not match the expected account type for the given tenant.. For instance, if the tenant is configured to allow only work or school accounts, and the user tries to sign in with a personal Microsoft account, they will receive this error.
 | AADSTS500212 | NotAllowedByOutboundPolicyTenant - The user's administrator has set an outbound access policy that doesn't allow access to the resource tenant. |
 | AADSTS500213 | NotAllowedByInboundPolicyTenant - The resource tenant's cross-tenant access policy doesn't allow this user to access this tenant. |
 | AADSTS50027 | InvalidJwtToken - Invalid JWT token because of the following reasons:<ul><li>doesn't contain nonce claim, sub claim</li><li>subject identifier mismatch</li><li>duplicate claim in idToken claims</li><li>unexpected issuer</li><li>unexpected audience</li><li>not within its valid time range </li><li>token format isn't proper</li><li>External ID token from issuer failed signature verification.</li></ul> |

articles/active-directory/manage-apps/configure-user-consent.md

@@ -59,7 +59,7 @@ To choose which app consent policy governs user consent for applications, you ca
 
 ### Connect to Microsoft Graph PowerShell
 
-Connect to Microsoft Graph PowerShell using the least-privilege permission needed. For reading the current user consent settings, use *Policy.Read.All*. For reading and changing the user consent settings, use *Policy.ReadWrite.Authorization*.
+Connect to Microsoft Graph PowerShell using the least-privilege permission needed. For reading the current user consent settings, use *Policy.Read.All*. For reading and changing the user consent settings, use *Policy.ReadWrite.Authorization*. You need to sign in as a [Global Administrator](../roles/permissions-reference.md#global-administrator).
 
 ```powershell
 Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

articles/active-directory/manage-apps/grant-admin-consent.md

@@ -35,6 +35,7 @@ Granting tenant-wide admin consent requires you to sign in as a user that is aut
 To grant tenant-wide admin consent, you need:
 
 - An Azure AD user account with one of the following roles:
+
    - Global Administrator or Privileged Role Administrator, for granting consent for apps requesting any permission, for any API.
    - Cloud Application Administrator or Application Administrator, for granting consent for apps requesting any permission for any API, _except_ Azure AD Graph or Microsoft Graph app roles (application permissions).
    - A custom directory role that includes the [permission to grant permissions to applications](../roles/custom-consent-permissions.md), for the permissions required by the application.
@@ -100,7 +101,7 @@ In the example, the resource enterprise application is Microsoft Graph of object
 
 ## Grant admin consent for delegated permissions
 
-1. Connect to Microsoft Graph PowerShell:
+1. Connect to Microsoft Graph PowerShell and sign in as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).
 
    ```powershell
    Connect-MgGraph -Scopes "Application.ReadWrite.All", "DelegatedPermissionGrant.ReadWrite.All"
@@ -136,7 +137,7 @@ New-MgOauth2PermissionGrant -BodyParameter $params |
 
 In the following example, you grant the Microsoft Graph enterprise application (the principal of ID `b0d9b9e3-0ecf-4bfd-8dab-9273dd055a94`) an app role (application permission) of ID `df021288-bdef-4463-88db-98f22de89214` that's exposed by a resource enterprise application of ID `7ea9e944-71ce-443d-811c-71e8047b557a`.
 
-1. Connect to Microsoft Graph PowerShell:
+1. Connect to Microsoft Graph PowerShell and sign in as a [Global Administrator](../roles/permissions-reference.md#global-administrator).
 
    ```powershell
    Connect-MgGraph -Scopes "Application.ReadWrite.All", "AppRoleAssignment.ReadWrite.All"
@@ -169,7 +170,9 @@ Use [Graph Explorer](https://developer.microsoft.com/graph/graph-explorer) to gr
 
 ## Grant admin consent for delegated permissions
 
-In the following example, you'll grant delegated permissions defined by a resource enterprise application to a client enterprise application on behalf of all users.
+In the following example, you'll grant delegated permissions defined by a resource enterprise application to a client enterprise application on behalf of all users. 
+
+You need to sign in as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).
 
 In the example, the resource enterprise application is Microsoft Graph of object ID `7ea9e944-71ce-443d-811c-71e8047b557a`. The Microsoft Graph defines the delegated permissions, `User.Read.All` and `Group.Read.All`. The consentType is `AllPrincipals`, indicating that you're consenting on behalf of all users in the tenant. The object ID of the client enterprise application is `b0d9b9e3-0ecf-4bfd-8dab-9273dd055a941`.
 
@@ -202,7 +205,9 @@ In the example, the resource enterprise application is Microsoft Graph of object
    ```
 ## Grant admin consent for application permissions
 
-In the following example, you grant the Microsoft Graph enterprise application (the principal of ID `b0d9b9e3-0ecf-4bfd-8dab-9273dd055a94`) an app role (application permission) of ID `df021288-bdef-4463-88db-98f22de89214` that's exposed by a resource enterprise application of ID `7ea9e944-71ce-443d-811c-71e8047b557a`.
+In the following example, you grant the Microsoft Graph enterprise application (the principal of ID `b0d9b9e3-0ecf-4bfd-8dab-9273dd055a94`) an app role (application permission) of ID `df021288-bdef-4463-88db-98f22de89214` that's exposed by a resource enterprise application of ID `7ea9e944-71ce-443d-811c-71e8047b557a`. 
+
+You need to sign in as sign as a [Global Administrator](../roles/permissions-reference.md#global-administrator).
 
 1. Retrieve the app roles defined by Microsoft graph in your tenant. Identify the app role that you'll grant the client enterprise application. In this example, the app role ID is `df021288-bdef-4463-88db-98f22de89214`
 

articles/active-directory/roles/TOC.yml

@@ -30,6 +30,8 @@
     href: best-practices.md
   - name: Security
     items:
+    - name: Privileged roles and permissions
+      href: privileged-roles-permissions.md
     - name: Role security planning
       href: security-planning.md
     - name: Create emergency accounts

articles/active-directory/roles/best-practices.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.workload: identity
 ms.subservice: roles
 ms.topic: conceptual
-ms.date: 03/28/2021
+ms.date: 09/01/2023
 ms.author: rolyon
 ms.reviewer: vincesm
 ms.custom: it-pro
@@ -19,7 +19,7 @@ ms.collection: M365-identity-device-management
 
 This article describes some of the best practices for using Azure Active Directory role-based access control (Azure AD RBAC). These best practices are derived from our experience with Azure AD RBAC and the experiences of customers like yourself. We encourage you to also read our detailed security guidance at [Securing privileged access for hybrid and cloud deployments in Azure AD](security-planning.md).
 
-## 1. Manage to least privilege
+## 1. Apply principle of least privilege
 
 When planning your access control strategy, it's a best practice to manage to least privilege. Least privilege means you grant your administrators exactly the permission they need to do their job. There are three aspects to consider when you assign a role to your administrators: a specific set of permissions, over a specific scope, for a specific period of time. Avoid assigning broader roles at broader scopes even if it initially seems more convenient to do so. By limiting roles and scopes, you limit what resources are at risk if the security principal is ever compromised. Azure AD RBAC supports over 65 [built-in roles](permissions-reference.md). There are Azure AD roles to manage directory objects like users, groups, and applications, and also to manage Microsoft 365 services like Exchange, SharePoint, and Intune. To better understand Azure AD built-in roles, see [Understand roles in Azure Active Directory](concept-understand-roles.md). If there isn't a built-in role that meets your need, you can create your own [custom roles](custom-create.md).  
 
@@ -35,7 +35,7 @@ Follow these steps to help you find the right role.
 
     ![Roles and administrators page in Azure AD with Service filter open](./media/best-practices/roles-administrators.png)
 
-1. Refer to the [Azure AD built-in roles](permissions-reference.md) documentation. Permissions associated with each role are listed together for better readability. To understand the structure and meaning of role permissions, see [How to understand role permissions](permissions-reference.md#how-to-understand-role-permissions).
+1. Refer to the [Azure AD built-in roles](permissions-reference.md) documentation. Permissions associated with each role are listed together for better readability. To understand the structure and meaning of role permissions, see [How to understand role permissions](privileged-roles-permissions.md#how-to-understand-role-permissions).
 
 1. Refer to the [Least privileged role by task](delegate-by-task.md) documentation.
 
@@ -61,27 +61,31 @@ For information about access reviews for roles, see [Create an access review of
 
 ## 5. Limit the number of Global Administrators to less than 5
 
-As a best practice, Microsoft recommends that you assign the Global Administrator role to **fewer than five** people in your organization. Global Administrators hold keys to the kingdom, and it is in your best interest to keep the attack surface low. As stated previously, all of these accounts should be protected with multi-factor authentication.
+As a best practice, Microsoft recommends that you assign the Global Administrator role to **fewer than five** people in your organization. Global Administrators essentially have unrestricted access, and it is in your best interest to keep the attack surface low. As stated previously, all of these accounts should be protected with multi-factor authentication.
 
 By default, when a user signs up for a Microsoft cloud service, an Azure AD tenant is created and the user is made a member of the Global Administrators role. Users who are assigned the Global Administrator role can read and modify every administrative setting in your Azure AD organization. With a few exceptions, Global Administrators can also read and modify all configuration settings in your Microsoft 365 organization. Global Administrators also have the ability to elevate their access to read data.
 
 Microsoft recommends that you keep two break glass accounts that are permanently assigned to the Global Administrator role. Make sure that these accounts don't require the same multi-factor authentication mechanism as your normal administrative accounts to sign in, as described in [Manage emergency access accounts in Azure AD](../roles/security-emergency-access.md). 
 
-## 6. Use groups for Azure AD role assignments and delegate the role assignment
+## 6. Limit the number of privileged role assignments to less than 10
+
+Some roles include privileged permissions, such as the ability to update credentials. Since these roles can potentially lead to elevation of privilege, you should limit the use of these privileged role assignments to **fewer than 10** in your organization. You can identity roles, permissions, and role assignments that are privileged by looking for the **PRIVILEGED** label. For more information, see [Privileged roles and permissions in Azure AD](privileged-roles-permissions.md).
+
+## 7. Use groups for Azure AD role assignments and delegate the role assignment
 
 If you have an external governance system that takes advantage of groups, then you should consider assigning roles to Azure AD groups, instead of individual users. You can also manage role-assignable groups in PIM to ensure that there are no standing owners or members in these privileged groups. For more information, see [Privileged Identity Management (PIM) for Groups (preview)](../privileged-identity-management/concept-pim-for-groups.md).
 
 You can assign an owner to role-assignable groups. That owner decides who is added to or removed from the group, so indirectly, decides who gets the role assignment. In this way, a Global Administrator or Privileged Role Administrator can delegate role management on a per-role basis by using groups. For more information, see [Use Azure AD groups to manage role assignments](groups-concept.md).
 
-## 7. Activate multiple roles at once using PIM for Groups
+## 8. Activate multiple roles at once using PIM for Groups
 
 It may be the case that an individual has five or six eligible assignments to Azure AD roles through PIM. They will have to activate each role individually, which can reduce productivity. Worse still, they can also have tens or hundreds of Azure resources assigned to them, which aggravates the problem.
 
 In this case, you should use [Privileged Identity Management (PIM) for Groups (preview)](../privileged-identity-management/concept-pim-for-groups.md). Create a PIM for Groups and grant it permanent access to multiple roles (Azure AD and/or Azure). Make that user an eligible member or owner of this group. With just one activation, they will have access to all the linked resources.
 
 ![PIM for Groups diagram showing activating multiple roles at once](./media/best-practices/pim-for-groups.png)
 
-## 8. Use cloud native accounts for Azure AD roles
+## 9. Use cloud native accounts for Azure AD roles
 
 Avoid using on-premises synced accounts for Azure AD role assignments. If your on-premises account is compromised, it can compromise your Azure AD resources as well.
 

articles/active-directory/roles/includes/authentication-table-include.md

@@ -12,11 +12,11 @@ ms.author: rolyon
 ms.custom: include file
 ---
 
-The following table compares the capabilities of this role with related roles.
+The following table compares the capabilities of authentication-related roles.
 
 | Role | Manage user's auth methods | Manage per-user MFA | Manage MFA settings | Manage auth method policy | Manage password protection policy | Update sensitive properties | Delete and restore users |
 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | --- |
-| [Authentication Administrator](#authentication-administrator) | Yes for [some users](#who-can-perform-sensitive-actions) | Yes for [some users](#who-can-perform-sensitive-actions) | No | No | No | Yes for [some users](#who-can-perform-sensitive-actions) | Yes for [some users](#who-can-perform-sensitive-actions) |
-| [Privileged Authentication Administrator](#privileged-authentication-administrator) | Yes for all users | Yes for all users | No | No | No | Yes for all users | Yes for all users |
-| [Authentication Policy Administrator](#authentication-policy-administrator) | No | No | Yes | Yes | Yes | No | No |
-| [User Administrator](#user-administrator) | No | No | No | No | No | Yes for [some users](#who-can-perform-sensitive-actions) | Yes for [some users](#who-can-perform-sensitive-actions) |
+| [Authentication Administrator](../permissions-reference.md#authentication-administrator) | Yes for [some users](../privileged-roles-permissions.md#who-can-perform-sensitive-actions) | Yes for [some users](../privileged-roles-permissions.md#who-can-perform-sensitive-actions) | No | No | No | Yes for [some users](../privileged-roles-permissions.md#who-can-perform-sensitive-actions) | Yes for [some users](../privileged-roles-permissions.md#who-can-perform-sensitive-actions) |
+| [Privileged Authentication Administrator](../permissions-reference.md#privileged-authentication-administrator) | Yes for all users | Yes for all users | No | No | No | Yes for all users | Yes for all users |
+| [Authentication Policy Administrator](../permissions-reference.md#authentication-policy-administrator) | No | No | Yes | Yes | Yes | No | No |
+| [User Administrator](../permissions-reference.md#user-administrator) | No | No | No | No | No | Yes for [some users](../privileged-roles-permissions.md#who-can-perform-sensitive-actions) | Yes for [some users](../privileged-roles-permissions.md#who-can-perform-sensitive-actions) |