Privileged roles and permissions in Microsoft Entra ID (preview)

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 No 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 No 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      
Usage Summary Reports Reader  
All 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  
Usage Summary Reports Reader
All custom roles

Next steps