Merge pull request #245983 from rolyon/rolyon-aadroles-privileged-roles-permissions-preview

[Azure AD roles] Privileged roles and permissions preview

Author: v-ccolin

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) |