Cuir in eagar

Comhroinn trí

Privileged roles and permissions in Microsoft Entra ID (preview)

  • Alt

Important

The label for privileged roles and permissions is currently in PREVIEW. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

Microsoft Entra ID has roles and permissions that are identified as privileged. These roles and permissions can be used to delegate management of directory resources to other users, modify credentials, authentication or authorization policies, or access restricted data. Privileged role assignments can lead to elevation of privilege if not used in a secure and intended manner. This article describes privileged roles and permissions and best practices for how to use.

Which roles and permissions are privileged?

For a list of privileged roles and permissions, see Microsoft Entra built-in roles. You can also use the Microsoft Entra admin center, Microsoft Graph PowerShell, or Microsoft Graph API to identify roles, permissions, and role assignments that are identified as privileged.

In the Microsoft Entra admin center, look for the PRIVILEGED label.

Privileged label icon.

On the Roles and administrators page, privileged roles are identified in the Privileged column. The Assignments column lists the number of role assignments. You can also filter privileged roles.

Screenshot of the Microsoft Entra roles and administrators page that shows the Privileged and Assignments columns.

When you view the permissions for a privileged role, you can see which permissions are privileged. If you view the permissions as a default user, you won't be able to see which permissions are privileged.

Screenshot of the Microsoft Entra roles and administrators page that shows the privileged permissions for a role.

When you create a custom role, you can see which permissions are privileged and the custom role will be labeled as privileged.

Screenshot of the New custom role page that shows a custom role with privileged permissions.

Best practices for using privileged roles

Here are some best practices for using privileged roles.

  • Apply principle of least privilege
  • Use Privileged Identity Management to grant just-in-time access
  • Turn on multi-factor authentication for all your administrator accounts
  • Configure recurring access reviews to revoke unneeded permissions over time
  • Limit the number of Global Administrators to less than 5
  • Limit the number of privileged role assignments to less than 10

For more information, see Best practices for Microsoft Entra roles.

Privileged permissions versus protected actions

Privileged permissions and protected actions are security-related capabilities that have different purposes. Permissions that have the PRIVILEGED label help you identify permissions that can lead to elevation of privilege if not used in a secure and intended manner. Protected actions are role permissions that have been assigned Conditional Access policies for added security, such as requiring multi-factor authentication. Conditional Access requirements are enforced when a user performs the protected action. Protected actions are currently in Preview. For more information, see What are protected actions in Microsoft Entra ID?.

Capability Privileged permission Protected action
Identify permissions that should be used in a secure manner ✅
Require additional security to perform an action ✅

Terminology

To understand privileged roles and permissions in Microsoft Entra ID, it helps to know some of the following terminology.

Term Definition
action An activity a security principal can perform on an object type. Sometimes referred to as an operation.
permission A definition that specifies the activity a security principal can perform on an object type. A permission includes one or more actions.
privileged permission In Microsoft Entra ID, permissions that can be used to delegate management of directory resources to other users, modify credentials, authentication or authorization policies, or access restricted data.
privileged role A built-in or custom role that has one or more privileged permissions.
privileged role assignment A role assignment that uses a privileged role.
elevation of privilege When a security principal obtains more permissions than their assigned role initially provided by impersonating another role.
protected action Permissions with Conditional Access applied for added security.

How to understand role permissions

The schema for permissions loosely follows the REST format of Microsoft Graph:

<namespace>/<entity>/<propertySet>/<action>

For example:

microsoft.directory/applications/credentials/update

Permission element Description
namespace Product or service that exposes the task and is prepended with microsoft. For example, all tasks in Microsoft Entra ID use the microsoft.directory namespace.
entity Logical feature or component exposed by the service in Microsoft Graph. For example, Microsoft Entra ID exposes User and Groups, OneNote exposes Notes, and Exchange exposes Mailboxes and Calendars. There is a special allEntities keyword for specifying all entities in a namespace. This is often used in roles that grant access to an entire product.
propertySet Specific properties or aspects of the entity for which access is being granted. For example, microsoft.directory/applications/authentication/read grants the ability to read the reply URL, logout URL, and implicit flow property on the application object in Microsoft Entra ID.
  • allProperties designates all properties of the entity, including privileged properties.
  • standard designates common properties, but excludes privileged ones related to read action. For example, microsoft.directory/user/standard/read includes the ability to read standard properties like public phone number and email address, but not the private secondary phone number or email address used for multifactor authentication.
  • basic designates common properties, but excludes privileged ones related to the update action. The set of properties that you can read may be different from what you can update. That’s why there are standard and basic keywords to reflect that.
action Operation being granted, most typically create, read, update, or delete (CRUD). There is a special allTasks keyword for specifying all of the above abilities (create, read, update, and delete).

Compare authentication 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 Yes for some users Yes for some users Yes No No Yes for some users Yes for some users
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 No Yes Yes Yes Yes No No
User Administrator No No No No No Yes for some users Yes for some users

Who can reset passwords

In the following table, the columns list the roles that can reset passwords and invalidate refresh tokens. The rows list the roles for which their password can be reset. For example, a Password Administrator can reset the password for Directory Readers, Guest Inviter, Password Administrator, and users with no administrator role. If a user is assigned any other role, the Password Administrator cannot reset their password.

The following table is for roles assigned at the scope of a tenant. For roles assigned at the scope of an administrative unit, further restrictions apply.

Role that password can be reset Password Admin Helpdesk Admin Auth Admin User Admin Privileged Auth Admin Global Admin
Auth Admin     ✅   ✅ ✅
Directory Readers ✅ ✅ ✅ ✅ ✅ ✅
Global Admin         ✅ ✅*
Groups Admin       ✅ ✅ ✅
Guest Inviter ✅ ✅ ✅ ✅ ✅ ✅
Helpdesk Admin   ✅   ✅ ✅ ✅
Message Center Reader   ✅ ✅ ✅ ✅ ✅
Password Admin ✅ ✅ ✅ ✅ ✅ ✅
Privileged Auth Admin         ✅ ✅
Privileged Role Admin         ✅ ✅
Reports Reader   ✅ ✅ ✅ ✅ ✅
User
(no admin role)		 ✅ ✅ ✅ ✅ ✅ ✅
User
(no admin role, but member or owner of a role-assignable group)		         ✅ ✅
User with a role scoped to a restricted management administrative unit         ✅ ✅
User Admin       ✅ ✅ ✅
User Experience Success Manager   ✅ ✅ ✅ ✅ ✅
Usage Summary Reports Reader   ✅ ✅ ✅ ✅ ✅
All other built-in and custom roles ✅ ✅

Important

The Partner Tier2 Support role can reset passwords and invalidate refresh tokens for all non-administrators and administrators (including Global Administrators). The Partner Tier1 Support role can reset passwords and invalidate refresh tokens for only non-administrators. These roles should not be used because they are deprecated.

The ability to reset a password includes the ability to update the following sensitive properties required for self-service password reset:

  • businessPhones
  • mobilePhone
  • otherMails

Who can perform sensitive actions

Some administrators can perform the following sensitive actions for some users. All users can read the sensitive properties.

Sensitive action Sensitive property name
Disable or enable users accountEnabled
Update business phone businessPhones
Update mobile phone mobilePhone
Update on-premises immutable ID onPremisesImmutableId
Update other emails otherMails
Update password profile passwordProfile
Update user principal name userPrincipalName
Delete or restore users Not applicable

In the following table, the columns list the roles that can perform sensitive actions. The rows list the roles for which the sensitive action can be performed upon.

The following table is for roles assigned at the scope of a tenant. For roles assigned at the scope of an administrative unit, further restrictions apply.

Role that sensitive action can be performed upon Auth Admin User Admin Privileged Auth Admin Global Admin
Auth Admin ✅   ✅ ✅
Directory Readers ✅ ✅ ✅ ✅
Global Admin     ✅ ✅
Groups Admin   ✅ ✅ ✅
Guest Inviter ✅ ✅ ✅ ✅
Helpdesk Admin   ✅ ✅ ✅
Message Center Reader ✅ ✅ ✅ ✅
Password Admin ✅ ✅ ✅ ✅
Privileged Auth Admin     ✅ ✅
Privileged Role Admin     ✅ ✅
Reports Reader ✅ ✅ ✅ ✅
User
(no admin role)		 ✅ ✅ ✅ ✅
User
(no admin role, but member or owner of a role-assignable group)		     ✅ ✅
User with a role scoped to a restricted management administrative unit     ✅ ✅
User Admin   ✅ ✅ ✅
User Experience Success Manager ✅ ✅ ✅ ✅
Usage Summary Reports Reader ✅ ✅ ✅ ✅
All other built-in and custom roles ✅ ✅

Next steps