get role assignment azure

Manage Azure Role Assignments Like a Pro with PowerShell

Today’s blog post is a little bit different. I have a couple of examples of how you can use PowerShell snippets and simple commandlets to get or set role assignmnets in your Azure Subscriptions.

PowerShell examples for managing Azure Role assignments

List all role assignments in a subscription, get all role assignments for a specific resource group, get all role assignments for a specific user, add a role assignment to a user, remove a role assignment for a user, remove all role assignments for a specific user, list all built-in roles, list all custom roles, create a custom role, update a custom role, delete a custom role, list all users or groups assigned to a specific role, list all permissions granted by a specific role, list all resource groups that a user has access to, create a role assignment for a service principal, powershell script to manage azure role assignments.

And now there is a script that combines some of these examples into one usable function:

I hope this was useful. Let me know if you liked the format of this blog and if you want me to include more of these examples.

Vukasin Terzic

Recent Update

• Writing your first Azure Terraform Configuration
• Transition from ARM Templates to Terraform with AI
• Getting started with Terraform for Azure
• Terraform Configuration Essentials: File Types, State Management, and Provider Selection
• Dynamically Managing Azure NSG Rules with PowerShell

Trending Tags

Retrieve azure resource group cost with powershell api.

The Future Of Azure Governance: Trends and Predictions

Further Reading

In my previous blog posts, I wrote about how simple PowerShell scripts can help speed up daily tasks for Azure administrators, and how you can convert them to your own API. One of these tasks is...

Azure Cost Optimization: 30 Ways to Save Money and Increase Efficiency

As organizations continue to migrate their applications and workloads to the cloud, managing and controlling cloud costs has become an increasingly critical issue. While Azure provides a robust s...

Custom PowerShell API for Azure Naming Policy

To continue our PowerShell API series, we have another example of a highly useful API that you can integrate into your environment. Choosing names for Azure resources can be a challenging task. ...

Wim Matthyssen

Azure infra, security & governance, azure development and ai/ml, azure identity and security, stéphane eyskens, cloud-native azure architecture, geert baeke, azure kubernetes service & containerization, maik van der gaag, azure infrastructure as code & devops, bart verboven, sammy deprez, azure ai, ml & cognitive services, sander van de velde.

All about Microsoft 365

Generate a report of Azure AD role assignments via the Graph API or PowerShell

A while back, I published a short article and script to illustrate the process of obtaining a list of all Azure AD role assignments. The examples therein use the old MSOnline and Azure AD PowerShell modules, which are now on a deprecation path. Thus, it’s time to update the code to leverage the “latest and greatest”. Quotes are there for a reason…

The updated script comes in two flavors. The first one is based on direct web requests against the Graph API endpoints and uses application permissions, thus is suitable for automation scenarios. Do make sure to replace the authentication variables, which you can find on lines 11-13. Better yet, replace the whole authentication block (lines 7-36) with your preferred “connect to Graph” function. Also make sure that sufficient permissions are granted to the service principal under which you will be running the script. Those include the Directory.Read.All scope for fetching regular role assignments and performing directory-wide queries, and the RoleManagement.Read.Directory for PIM roles.

The second flavor is based on the cmdlets included as part of the Microsoft Graph SDK for PowerShell. As authentication is handled via the Connect-MGGraph cmdlet, the script is half the size of the first one. And it would’ve been even smaller were it not for few annoying bugs Microsoft is yet to address.

In all fairness, switching to the Graph does offer some improvements, such as being able to use a single call to list all role assignments. This is made possible thanks to the  /roleManagement/directory/roleAssignments endpoint (or calling the Get-MgRoleManagementDirectoryRoleAssignment cmdlet). Previously, we had to iterate over each admin role and list its members, which is not exactly optimal, and given the fact that the list of built-in roles has now grown to over 90, it does add up. On the negative side, we have a bunch of GUIDs in the output, most of which we will want to translate to human-readable values, as they designate the user, group or service principal to which a given role has been assigned, as well as the actual role. One way to go about this is to use the $expand operator (or the – ExpandProperty parameter if using the SDK) to request the full object.

While this is the quickest method, the lack of support for the $select operator inside an $expand query means we will be fetching a lot more data than what we need for the report. In addition, there seems to be an issue with the definition of the expandable properties for this specific endpoint, as trying to use the handy $expand=* value will result in an error ( “Could not find a property named ‘appScope’ on type ‘Microsoft.DirectoryServices.RoleAssignment'” ). In effect, to fetch both the expanded principal object and the expanded roleDefinition object, we need to run two separate queries and merge the results. Hopefully Microsoft will address this issue in the future (the /roleManagement/directory/roleEligibilitySchedules we will use to fetch PIM eligible role assignments does support $expand=* query).

Another option is to collect all the principalIDs and issue a POST request against the /directoryObjects/getByIds endpoint (or the corresponding Get-MgDirectoryObjectById cmdlet), which does have a proper support for $select . A single query can be used to “translate” up to 1000 principal values, which should be sufficient for most scenarios. With the information gathered from the query, we can construct a hash-table and use it to lookup the property values we want to expose in our report. Lastly, you can also query each principalID individually, but that’s the messiest option available.

Apart from role assignments obtained via the /roleManagement/directory/roleAssignments call, the script can also include any PIM eligible role assignments. To fetch those, invoke the script with the – IncludePIMEligibleAssignments switch. It will then call the /v1.0/roleManagement/directory/roleEligibilitySchedules endpoint, or similarly, use the Get-MgRoleManagementDirectoryRoleEligibilitySchedule cmdlet. Some minor adjustments are needed to ensure the output between the two is uniform, which includes the aforementioned issue with expanding the navigation properties. But hey, it wouldn’t be a Microsoft product if everything worked out of the box 🙂

Here are some examples on how to run the scripts. The first example uses the Graph API version and no parameters. For the second one, we invoke the – IncludePIMEligibleAssignments parameter in order to include PIM eligible role assignments as well. The last example does the same thing, but for the Graph SDK version of the script.

And with that, we’re ready to build the output. Thanks to the $expand operator and the workarounds used above, we should be able to present sufficient information about each role assignment, while minimizing the number of calls made. The output is automatically exported to a CSV in the script folder, and includes the following fields:

• Principal – an identifier for the user, group or service principal to which the role has been assigned. Depending on the object type, an UPN, appID or GUID value will be presented.
• PrincipalDisplayName – the display name for the principal.
• PrincipalType – the object type of the principal.
• AssignedRole – the display name of the role assigned.
• AssignedRoleScope – the assignment scope, either the whole directory (“/”) or a specific administrative unit.
• AssignmentType – the type of assignment (“Permanent” or “Eligible”).
• IsBuiltIn – indicates whether the role is a default one, or custom-created one.
• RoleTemplate – the GUID for the role template.

Now, it’s very important to understand that this script only covers Azure AD admin roles, either default or custom ones, and optionally eligible PIM-assignable roles (do note that the PIM cmdlets/endpoints do not cover all custom role scenarios). Apart from these, there are numerous workload-specific roles that can be granted across Office 365, such as the Exchange Online Roles and assignments, Roles in the Security and Compliance Center, site collection permissions in SharePoint Online, and so on. Just because a given user doesn’t appear in the admin role report, it doesn’t mean that he cannot have other permissions granted!

In addition, one should make sure to cover any applications (service principals) that have been granted permissions to execute operations against your tenant. Such permissions can range from being able to read directory data to full access to user’s messages and files, so it’s very important to keep track on them. We published an article  that can get you started with a sample script a while back.

9 thoughts on “ Generate a report of Azure AD role assignments via the Graph API or PowerShell ”

• Pingback: Reporting on Entra ID directory role assignments (including PIM) - Blog

This script is very nicely written, however the output of the Powershell Graph SDK version is incorrect (I didn’t check the other).

If I am eligible to activate a role I’ll be in the eligible list. However once I activate the role, my activated role assignment will show up in the list of role assignments from “Get-MgRoleManagementDirectoryRoleAssignment”. The output of that command doesn’t include a ‘status’ property. Your script assumes that if there’s no ‘status’ then the assignment is permanent, however that’s not accurate. So every eligible user who has activated a role shows up twice in the output of your script – once as as eligible for the role and once as a permanent assignment.

I came across your script because I’m trying to accomplish a similar task. My goal is to enumerate all the users who have eligible or permanent role assignments. I think the answer may be that if a user is in the eligible list, and also in the role assignment list, for the same role, then you can assume that the role assignment came from activation, but that doesn’t really seem very satisfactory.

Thanks Matt. The script is a bit outdated by now, I don’t even know if it runs with the “V2” Graph SDK. I’ll update it at some point 🙂

To further address your comment – neither the Get-MgRoleManagementDirectoryRoleAssignment nor the Get-MgRoleManagementDirectoryRoleEligibilitySchedule cmdlet returns sufficient information in order to determine whether a given (eligible) role assignment is currently activated. You can get this information via Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance, should be easy enough to add to the next iteration of the script.

Hi, thks for your great work. do you know why i dont see the eligible assignements ?

Seems they made some changes and you can no longer use $expand=* on the /v1.0 endpoint. Try using /beta, should work there. I’ll update the script when I get some time.

I’ve updated the script, let me know if you are still having issues.

Awesome, thank you very much.

Merci merci merci !!! Thanks thanks thanks !!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Get-AzRoleAssignment

In this Azure PowerShell article, we will discuss the syntax and usage of the Get-AzRoleAssignment PowerShell cmdlet with a few examples.

Table of Contents

Syntax of Get-AzRoleAssignment

Wrapping up.

Get-AzRoleAssignment is an excellent Azure PowerShell cmdlet that can get you the lists of all the role assignments under your subscription or a specific scope.

Below is the syntax of the Get-AzRoleAssignment Azure PowerShell cmdlet.

Let’s discuss some examples of implementation of the Get-AzRoleAssignment PowerShell command.

You can execute the Azure PowerShell cmdlet below to help you get the list of all the role assignments under my current subscription.

After executing the above PowerShell command, I got the below output.

You can see the output below

You can also use the below Azure PowerShell command to get the list of role assignments under the specified service principal “http://tsinfotechnologies.com”.

Execute the below PowerShell command that can help you to get the list of role assignments under a specified tsinfo website scope.

You may also like following the articles below

• New-AzRoleAssignment
• Get-AzRoleDefinition
• Get-AzResource

In this Azure article, we have discussed the syntax and usage of the Get-AzRoleAssignment Azure PowerShell cmdlet. Thanks for reading this article !!!

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more .

Export role assignments for all Azure subscriptions

Microsoft has done it straightforward to get an overview of Azure role assignments for a subscription. They have added the  Download role assignments  button in the Azure portal under Subscriptions. When I’m working with customers that have many subscriptions, I’ll like to get an overview of all the subscriptions at once. Therefore I use PowerShell the export role assignments for all Azure subscriptions at once.

Script parameters

There are 2 parameters in the script, $OutputPath and $SelectCurrentSubscription . None of them are mandatory.

$OutputPath: If defined, a CSV file will be exported to the chosen location. Example:  .\Export-RoleAssignments.ps1 -OutputPath C:\temp

$SelectCurrentSubscription: Will only export role assignments from the subscription that are selected. Example:  .\Export-RoleAssignments.ps1 -SelectCurrentSubscription

Run  Get-Azcontext  to view which subscription is selected.

Script Output

Besides getting an overview of the overall role assignments in an Azure subscription, I also like to know if a role is a Custom or Built-in role. The script will check each assignment if CustomRole is True or False.

Output Example in Powershell Console

Output Example to CSV File

The PowerShell Script

The Powershell script will be available on my account Github . Go there for the latest updates (article script will not be synced with the GitHub version).

3 thoughts on “ Export role assignments for all Azure subscriptions ”

Can you edit the script that when roles assigned to groups the group members are also exported in that csv?

getting the following error on azuread part:

PS C:\scripts> .\azure.ps1 -OutPutPath C:\temp VERBOSE: Running for all subscriptions in tenant VERBOSE: Changing to Subscription Access to Azure Active Directory VERBOSE: Getting information about Role Assignments… WARNING: We have migrated the API calls for this cmdlet from Azure Active Directory Graph to Microsoft Graph. Visit https://go.microsoft.com/fwlink/?linkid=2181475 for any permission issues. Get-AzRoleAssignment : Operation returned an invalid status code ‘BadRequest’ At C:\scripts\azure.ps1:39 char:14 + $roles = Get-AzRoleAssignment | Select-Object RoleDefinitionName, … + ~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : CloseError: (:) [Get-AzRoleAssignment], ErrorResponseException + FullyQualifiedErrorId : Microsoft.Azure.Commands.Resources.GetAzureRoleAssignmentCommand

You have to edit the script for it to work again. You will have to change the API call to Microsoft Graph. Maybe I will do it at some point.

Leave a Reply Cancel reply

Your email address will not be published.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

role-assignments.md

Latest commit, file metadata and controls, understand azure role assignments.

Role assignments enable you to grant a principal (such as a user, a group, a managed identity, or a service principal) access to a specific Azure resource. This article describes the details of role assignments.

Role assignment

Access to Azure resources is granted by creating a role assignment, and access is revoked by removing a role assignment.

A role assignment has several components, including:

• The principal , or who is assigned the role.
• The role that they're assigned.
• The scope at which the role is assigned.
• The name of the role assignment, and a description that helps you to explain why the role has been assigned.

For example, you can use Azure RBAC to assign roles like:

• User Sally has owner access to the storage account contoso123 in the resource group ContosoStorage .
• Everybody in the Cloud Administrators group in Microsoft Entra ID has reader access to all resources in the resource group ContosoStorage .
• The managed identity associated with an application is allowed to restart virtual machines within Contoso's subscription.

The following shows an example of the properties in a role assignment when displayed using Azure PowerShell :

The following shows an example of the properties in a role assignment when displayed using the Azure CLI , or the REST API :

The following table describes what the role assignment properties mean.

When you create a role assignment, you need to specify the scope at which it's applied. The scope represents the resource, or set of resources, that the principal is allowed to access. You can scope a role assignment to a single resource, a resource group, a subscription, or a management group.

Use the smallest scope that you need to meet your requirements.

For example, if you need to grant a managed identity access to a single storage account, it's good security practice to create the role assignment at the scope of the storage account, not at the resource group or subscription scope.

For more information about scope, see Understand scope .

Role to assign

A role assignment is associated with a role definition. The role definition specifies the permissions that the principal should have within the role assignment's scope.

You can assign a built-in role definition or a custom role definition. When you create a role assignment, some tooling requires that you use the role definition ID while other tooling allows you to provide the name of the role.

For more information about role definitions, see Understand role definitions .

Principals include users, security groups, managed identities, workload identities, and service principals. Principals are created and managed in your Microsoft Entra tenant. You can assign a role to any principal. Use the Microsoft Entra ID object ID to identify the principal that you want to assign the role to.

When you create a role assignment by using Azure PowerShell, the Azure CLI, Bicep, or another infrastructure as code (IaC) technology, you specify the principal type . Principal types include User , Group , and ServicePrincipal . It's important to specify the correct principal type. Otherwise, you might get intermittent deployment errors, especially when you work with service principals and managed identities.

A role assignment's resource name must be a globally unique identifier (GUID).

Role assignment resource names must be unique within the Microsoft Entra tenant, even if the scope of the role assignment is narrower.

When you create a role assignment by using the Azure portal, Azure PowerShell, or the Azure CLI, the creation process gives the role assignment a unique name for you automatically.

If you create a role assignment by using Bicep or another infrastructure as code (IaC) technology, you need to carefully plan how you name your role assignments. For more information, see Create Azure RBAC resources by using Bicep .

Resource deletion behavior

When you delete a user, group, service principal, or managed identity from Microsoft Entra ID, it's a good practice to delete any role assignments. They aren't deleted automatically. Any role assignments that refer to a deleted principal ID become invalid.

If you try to reuse a role assignment's name for another role assignment, the deployment will fail. This issue is more likely to occur when you use Bicep or an Azure Resource Manager template (ARM template) to deploy your role assignments, because you have to explicitly set the role assignment name when you use these tools. To work around this behavior, you should either remove the old role assignment before you recreate it, or ensure that you use a unique name when you deploy a new role assignment.

Description

You can add a text description to a role assignment. While descriptions are optional, it's a good practice to add them to your role assignments. Provide a short justification for why the principal needs the assigned role. When somebody audits the role assignments, descriptions can help to understand why they've been created and whether they're still applicable.

Some roles support role assignment conditions based on attributes in the context of specific actions. A role assignment condition is an additional check that you can optionally add to your role assignment to provide more fine-grained access control.

For example, you can add a condition that requires an object to have a specific tag for the user to read the object.

You typically build conditions using a visual condition editor, but here's what an example condition looks like in code:

The preceding condition allows users to read blobs with a blob index tag key of Project and a value of Cascade .

For more information about conditions, see What is Azure attribute-based access control (Azure ABAC)?

• Delegate Azure access management to others
• Steps to assign an Azure role

Get PIM Role Assignment Status For Azure AD Using Powershell

If you’re like me and you love to run reports to get valuable information for your tenant and settings, the get PIM role assignment status is the script for you. Recently I was running a report to audit user permissions in Azure AD and realized that my data was off by a bit. I knew some users were added to Privilege Identity Management (PIM) roles but they weren’t showing up in my report.  

The reason they weren’t showing up is because I was using the Get-AzureADDirectoryRoleMember cmdlet and that only shows users with current or activated access. If a user was not elevated in PIM, they basically didn’t have access so it skewing my results.

To give you a better idea of what I’m talking about, the above is a sample of the Helpdesk Administrators role. In the Azure AD GUI, the user is added as an eligible role, meaning he can elevate his just in time access. However in Powershell, since the role is not activated, it is not going to display.

Therefore we are going to use the Get-AzureADMSPrivilegedRoleDefinition Azure AD cmdlet to display the list of roles available and the Get-AzureADMSPrivilegedRoleAssignment to filter for the user we’re specifying.

Requirements for this script to work

In order to make this work you’ll need the following:

• AzureADPreview Powershell module .

I want to emphasize the “preview” in the name of the module. Using just the regular AzureAD module is not not going to work so that’s something to keep in mind.

Script Parameters

Userprincipalname.

Specify the UserPrincipalName for the user you want to check roles for.

Specify the RoleName you want to filter for. This will display all PIM roles that are granted directly or through a group.

By default it will use the TenantId from your current session. If you’re connected to a multi-tenant, you can specify the tenant here.

By using this script you’ll be able to see all the people who have standing access as well as PIM eligible roles.

We can now see that the Helpdesk Administrator is now showing up in our output and in the Assignment column it is labeled as Eligible. We’ll also take note that we can see if the member type is added through a group or if it was added directly. This script will support that option.

Get PIM role assignment status for Azure AD using Powershell will now be in your arsenal of cool tips and tricks for your Syadmin role. If you’re interested in more scripts like this, be sure to check out our Powershell Gallery or Azure Content . Finally, be sure to check out our Youtube Channel for any video content.

Paul Contreras

Hi, my name is Paul and I am a Sysadmin who enjoys working on various technologies from Microsoft, VMWare, Cisco and many others. Join me as I document my trials and tribulations of the daily grind of System Administration.

Is there a possibility we could get an updated version of this using Microsoft Graph or Graph API? I cannot find any suitable alternatives now that the azure cmdlets are depreciated.

Yes. I have the script already created, just need to create an article

Could you upload this script, please? This is wonderfull.

See my updated post for the Graph API version. https://thesysadminchannel.com/get-entra-id-pim-role-assignment-using-graph-api/

See my updated post for the Graph API script. https://thesysadminchannel.com/get-entra-id-pim-role-assignment-using-graph-api/

it was a great job but riles are changed and groups extract cannot work

What about a similar Script for Azure resource roles?

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

• Contact Sales
• Try Azure for free

Feature Update: Azure Action Groups

Published date: may 30, 2024.

Action groups has recently updated the Email notification when using Resource Manager.

In the  previous  behavior, emails would send only to users who were assigned an RBAC role as a user assignment with an email address configured in their user object profile. Emails in this previous behavior would not have been sent to users who inherit the relevant RBAC role through a group level assignment.

In the  new  behavior, the users who inherit a role assignment from being a group member will start receiving emails. The emails will be sent to users regardless of role inheritance or direct user assignment, including to users inheriting role assignment through group-level assignment on Azure Lighthouse. This new behavior was rolled out mid May 2024.

• Azure Monitor
• Action Groups

Related Products

Assign Azure Built-In Roles for Access to Resources

You can assign Azure built-in roles to the Azure app registration that you use for Commvault.

• Prerequisites

If you will use Azure CLI or Azure PowerShell for the steps on this page, use most recent version of the application.

Your Azure account must have the Role Based Access Control Administrator role

• Azure Portal

In the Azure portal, on the Access Control (IAM) tab, click Add , and then select Add role assignment .

The Add role assignment pane appears.

From the Role list, select the roles that are required for the workload:

From the Assign access to list, select User, group, or service principal .

For Members , do the following:

Click Select members .

The Select members blade appears.

In the Select box, start typing to select the application that you created in the preceding step.

Click Save .

To obtain the tenant ID (which is also the directory ID) from the public Azure cloud, go to Azure Active Directory > Properties > Directory .

To protect Azure resources with your own storage account, repeat the preceding steps to add the Storage Blob Data Contributor role.

Use the following command to assign roles:

az ad sp create-for-rbac -n Azure_app --scopes /subscriptions/${Azure_subscription_ID} --role “role” --output json --only-show-errors Where:

- Azure_app is the name of your Azure app.

- Azure_subscription_ID is the ID of your Azure subscription.

- role is the role to assign.

Required roles for Azure workloads are as follows:

• Azure PowerShell

Where role is the role to assign.

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Assign Azure roles using the Azure portal

• 4 contributors

Azure role-based access control (Azure RBAC) is the authorization system you use to manage access to Azure resources. To grant access, you assign roles to users, groups, service principals, or managed identities at a particular scope. This article describes how to assign roles using the Azure portal.

If you need to assign administrator roles in Microsoft Entra ID, see Assign Microsoft Entra roles to users .

Prerequisites

To assign Azure roles, you must have:

• Microsoft.Authorization/roleAssignments/write permissions, such as Role Based Access Control Administrator or User Access Administrator

Step 1: Identify the needed scope

When you assign roles, you must specify a scope. Scope is the set of resources the access applies to. In Azure, you can specify a scope at four levels from broad to narrow: management group , subscription, resource group , and resource. For more information, see Understand scope .

Sign in to the Azure portal .

In the Search box at the top, search for the scope you want to grant access to. For example, search for Management groups , Subscriptions , Resource groups , or a specific resource.

Click the specific resource for that scope.

The following shows an example resource group.

Step 2: Open the Add role assignment page

Access control (IAM) is the page that you typically use to assign roles to grant access to Azure resources. It's also known as identity and access management (IAM) and appears in several locations in the Azure portal.

Click Access control (IAM) .

The following shows an example of the Access control (IAM) page for a resource group.

Click the Role assignments tab to view the role assignments at this scope.

Click Add > Add role assignment .

If you don't have permissions to assign roles, the Add role assignment option will be disabled.

The Add role assignment page opens.

Step 3: Select the appropriate role

Follow these steps:

On the Role tab, select a role that you want to use.

You can search for a role by name or by description. You can also filter roles by type and category.

If you want to assign a privileged administrator role, select the Privileged administrator roles tab to select the role.

For best practices when using privileged administrator role assignments, see Best practices for Azure RBAC .

In the Details column, click View to get more details about a role.

Click Next .

Step 4: Select who needs access

On the Members tab, select User, group, or service principal to assign the selected role to one or more Microsoft Entra users, groups, or service principals (applications).

Click Select members .

Find and select the users, groups, or service principals.

You can type in the Select box to search the directory for display name or email address.

Click Select to add the users, groups, or service principals to the Members list.

To assign the selected role to one or more managed identities, select Managed identity .

In the Select managed identities pane, select whether the type is user-assigned managed identity or system-assigned managed identity .

Find and select the managed identities.

For system-assigned managed identities, you can select managed identities by Azure service instance.

Click Select to add the managed identities to the Members list.

In the Description box enter an optional description for this role assignment.

Later you can show this description in the role assignments list.

Step 5: (Optional) Add condition

If you selected a role that supports conditions, a Conditions tab will appear and you have the option to add a condition to your role assignment. A condition is an additional check that you can optionally add to your role assignment to provide more fine-grained access control.

The Conditions tab will look different depending on the role you selected.

Delegate condition

Delegating Azure role assignment management with conditions 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.

If you selected one of the following privileged roles, follow the steps in this section.

• Role Based Access Control Administrator
• User Access Administrator

On the Conditions tab under What user can do , select the Allow user to only assign selected roles to selected principals (fewer privileges) option.

Click Select roles and principals to add a condition that constrains the roles and principals this user can assign roles to.

Follow the steps in Delegate Azure role assignment management to others with conditions .

Storage condition

If you selected one of the following storage roles, follow the steps in this section.

• Storage Blob Data Contributor
• Storage Blob Data Owner
• Storage Blob Data Reader
• Storage Queue Data Contributor
• Storage Queue Data Message Processor
• Storage Queue Data Message Sender
• Storage Queue Data Reader

Click Add condition if you want to further refine the role assignments based on storage attributes.

Follow the steps in Add or edit Azure role assignment conditions .

Step 6: Assign role

On the Review + assign tab, review the role assignment settings.

Click Review + assign to assign the role.

After a few moments, the security principal is assigned the role at the selected scope.

If you don't see the description for the role assignment, click Edit columns to add the Description column.

Related content

• Assign a user as an administrator of an Azure subscription
• Remove Azure role assignments
• Troubleshoot Azure RBAC

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources