assignment type azure

This browser is no longer supported.

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

Assign Azure resource roles in Privileged Identity Management

• 20 contributors

With Microsoft Entra Privileged Identity Management (PIM), you can manage the built-in Azure resource roles, and custom roles, including (but not limited to):

• User Access Administrator
• Contributor
• Security Admin
• Security Manager

Users or members of a group assigned to the Owner or User Access Administrator subscription roles, and Microsoft Entra Global administrators that enable subscription management in Microsoft Entra ID have Resource administrator permissions by default. These administrators can assign roles, configure role settings, and review access using Privileged Identity Management for Azure resources. A user can't manage Privileged Identity Management for Resources without Resource administrator permissions. View the list of Azure built-in roles .

Privileged Identity Management support both built-in and custom Azure roles. For more information on Azure custom roles, see Azure custom roles .

Role assignment conditions

You can use the Azure attribute-based access control (Azure ABAC) to add conditions on eligible role assignments using Microsoft Entra PIM for Azure resources. With Microsoft Entra PIM, your end users must activate an eligible role assignment to get permission to perform certain actions. Using conditions in Microsoft Entra PIM enables you not only to limit a user's role permissions to a resource using fine-grained conditions, but also to use Microsoft Entra PIM to secure the role assignment with a time-bound setting, approval workflow, audit trail, and so on.

When a role is assigned, the assignment:

• Can't be assigned for a duration of less than five minutes
• Can't be removed within five minutes of it being assigned

Currently, the following built-in roles can have conditions added:

• Storage Blob Data Contributor
• Storage Blob Data Owner
• Storage Blob Data Reader

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

Assign a role

Follow these steps to make a user eligible for an Azure resource role.

Sign in to the Microsoft Entra admin center as at least a User Access Administrator .

Browse to Identity governance > Privileged Identity Management > Azure resources .

Select the resource type you want to manage. Start at either the Management group dropdown or the Subscriptions dropdown, and then further select Resource groups or Resources as needed. Click the Select button for the resource you want to manage to open its overview page.

Under Manage , select Roles to see the list of roles for Azure resources.

Select Add assignments to open the Add assignments pane.

Select a Role you want to assign.

Select No member selected link to open the Select a member or group pane.

Select a member or group you want to assign to the role and then choose Select .

On the Settings tab, in the Assignment type list, select Eligible or Active .

Microsoft Entra PIM for Azure resources provides two distinct assignment types:

Eligible assignments require the member to activate the role before using it. Administrator may require role member to perform certain actions before role activation, which might include performing a multi-factor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers.

Active assignments don't require the member to activate the role before usage. Members assigned as active have the privileges assigned ready to use. This type of assignment is also available to customers that don't use Microsoft Entra PIM.

To specify a specific assignment duration, change the start and end dates and times.

If the role has been defined with actions that permit assignments to that role with conditions, then you can select Add condition to add a condition based on the principal user and resource attributes that are part of the assignment.

Conditions can be entered in the expression builder.

When finished, select Assign .

After the new role assignment is created, a status notification is displayed.

Assign a role using ARM API

Privileged Identity Management supports Azure Resource Manager (ARM) API commands to manage Azure resource roles, as documented in the PIM ARM API reference . For the permissions required to use the PIM API, see Understand the Privileged Identity Management APIs .

The following example is a sample HTTP request to create an eligible assignment for an Azure role.

Request body

Status code: 201

Update or remove an existing role assignment

Follow these steps to update or remove an existing role assignment.

Open Microsoft Entra Privileged Identity Management .

Select Azure resources .

Under Manage , select Roles to list the roles for Azure resources. The following screenshot lists the roles of an Azure Storage account. Select the role that you want to update or remove.

Find the role assignment on the Eligible roles or Active roles tabs.

To add or update a condition to refine Azure resource access, select Add or View/Edit in the Condition column for the role assignment. Currently, the Storage Blob Data Owner, Storage Blob Data Reader, and Storage Blob Data Contributor roles in Microsoft Entra PIM are the only roles that can have conditions added.

Select Add expression or Delete to update the expression. You can also select Add condition to add a new condition to your role.

For information about extending a role assignment, see Extend or renew Azure resource roles in Privileged Identity Management .

• Configure Azure resource role settings in Privileged Identity Management
• Assign Microsoft Entra roles in Privileged Identity Management

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

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

configure-host-pool-personal-desktop-assignment-type-2019.md

Latest commit, file metadata and controls, configure the personal desktop host pool assignment type for azure virtual desktop (classic).

This content applies to Azure Virtual Desktop (classic), which doesn't support Azure Resource Manager Azure Virtual Desktop objects. If you're trying to manage Azure Resource Manager Azure Virtual Desktop objects, see this article .

You can configure the assignment type of your personal desktop host pool to adjust your Azure Virtual Desktop environment to better suit your needs. In this topic, we'll show you how to configure automatic or direct assignment for your users.

The instructions in this article only apply to personal desktop host pools, not pooled host pools, since users in pooled host pools aren't assigned to specific session hosts.

Configure automatic assignment

Automatic assignment is the default assignment type for new personal desktop host pools created in your Azure Virtual Desktop environment. Automatically assigning users doesn't require a specific session host.

To automatically assign users, first assign them to the personal desktop host pool so that they can see the desktop in their feed. When an assigned user launches the desktop in their feed, they will claim an available session host if they have not already connected to the host pool, which completes the assignment process.

Before you start, download and import the Azure Virtual Desktop PowerShell module if you haven't already.

Make sure you've installed Azure Virtual Desktop PowerShell module version 1.0.1534.2001 or later before following these instructions.

After that, run the following cmdlet to sign in to your account:

To configure a host pool to automatically assign users to VMs, run the following PowerShell cmdlet:

To assign a user to the personal desktop host pool, run the following PowerShell cmdlet:

Configure direct assignment

Unlike automatic assignment, when you use direct assignment, you must assign the user to both the personal desktop host pool and a specific session host before they can connect to their personal desktop. If the user is only assigned to a host pool without a session host assignment, they won't be able to access resources.

To configure a host pool to require direct assignment of users to session hosts, run the following PowerShell cmdlet:

To assign a user to a specific session host, run the following PowerShell cmdlet:

Remove a user assignment

You may want to remove a user assignment because the user no longer needs the personal desktop, the user has left the company, or you want to reuse the desktop for someone else.

Currently, the only way you can remove the user assignment for a personal desktop is to fully remove the session host. To remove the session host, run this cmdlet:

If you need to add the session host back into the personal desktop host pool, uninstall Azure Virtual Desktop on that machine, then follow the steps in Create a host pool with PowerShell to re-register the session host.

Now that you've configured the personal desktop assignment type, you can sign in to an Azure Virtual Desktop client to test it as part of a user session. These next two How-tos will tell you how to connect to a session using the client of your choice:

• Connect with the Windows Desktop client
• Connect with the web client

Azure RBAC: role assignments and ARM templates

This post is about Azure's role assignments and ARM templates. Role assignments can be thought of as "permissions for Azure".

If you're deploying to Azure, there's a good chance you're using ARM templates to do so. Once you've got past "Hello World", you'll probably find yourself in a situation when you're deploying multiple types of resource to make your solution. For instance, you may be deploying an App Service alongside Key Vault and Storage .

One of the hardest things when it comes to deploying software and having it work, is permissions. Without adequate permissions configured, the most beautiful code can do nothing . Incidentally, this is a good thing. We're deploying to the web; many people are there, not all good. As a different kind of web-head once said:

Azure has great power and suggests you use it wisely .

Access management for cloud resources is critical for any organization that uses the cloud. Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. Designating groups or individual roles responsible for specific functions in Azure helps avoid confusion that can lead to human and automation errors that create security risks. Restricting access based on the need to know and least privilege security principles is imperative for organizations that want to enforce security policies for data access.

This is good advice. With that in mind, how can we ensure that the different resources we're deploying to Azure can talk to one another?

Role (up for your) assignments ​

The answer is roles. There's a number of roles that exist in Azure that can be assigned to users, groups, service principals and managed identities. In our own case we're using managed identity for our resources. What we can do is use "role assignments" to give our managed identity access to given resources. Arturo Lucatero gives a great short explanation of this:

Whilst this explanation is delightfully simple, the actual implementation when it comes to ARM templates is a little more involved. Because now it's time to talk "magic" GUIDs. Consider the following truncated ARM template, which gives our managed identity (and hence our App Service which uses this identity) access to Key Vault and Storage:

Let's take a look at these three variables:

The three variables above contain the subscription resource ids for the roles Storage Blob Data Contributor , Key Vault Secrets Officer and Key Vault Crypto Officer . The first question on your mind is likely: "what is ba92f5b4-2d11-453d-a403-e96b0029c9fe and where does it come from?" Great question! Well, each of these GUIDs represents a built-in role in Azure RBAC. The ba92f5b4-2d11-453d-a403-e96b0029c9fe represents the Storage Blob Data Contributor role.

How can I look these up? Well, there's two ways; there's an article which documents them here or you could crack open the Cloud Shell and look up a role by GUID like so:

Or by name like so:

As you can see, the Actions section of the output above (and in even more detail on the linked article ) provides information about what the different roles can do. So if you're looking to enable one Azure resource to talk to another, you should be able to refer to these to identify a role that you might want to use.

Creating a role assignment ​

So now we understand how you identify the roles in question, let's take the final leap and look at assigning those roles to our managed identity. For each role assignment, you'll need a roleAssignments resource defined that looks like this:

Let's go through the above, significant property by significant property (it's also worth checking the official reference here ):

• type - the type of role assignment we want to create, for a key vault it's "Microsoft.KeyVault/vaults/providers/roleAssignments" , for storage it's "Microsoft.Storage/storageAccounts/providers/roleAssignments" . The pattern is that it's the resource type, followed by "/providers/roleAssignments" .
• dependsOn - before we can create a role assignment, we need the service principal we desire to permission (in our case a managed identity) to exist
• properties.roleDefinitionId - the role that we're assigning, provided as an id. So for this example it's the keyVaultCryptoOfficer variable, which was earlier defined as [subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'ba92f5b4-2d11-453d-a403-e96b0029c9fe')] . (Note the use of the GUID)
• properties.principalId - the id of the principal we're adding permissions for. In our case this is a managed identity (a type of service principal).
• properties.scope - we're modifying another resource; our key vault isn't defined in this ARM template and we want to specify the resource we're granting permissions to.
• properties.principalType - the type of principal that we're creating an assignment for; in our this is "ServicePrincipal" - our managed identity.

There is an alternate approach that you can use where the type is "Microsoft.Authorization/roleAssignments" . Whilst this also works, it displayed errors in the Azure tooling for VS Code . As such, we've opted not to use that approach in our ARM templates.

Many thanks to the awesome John McCormick who wrangled permissions with me until we bent Azure RBAC to our will.

• Role (up for your) assignments
• Creating a role assignment

Lab 11 - Assign Azure resource roles in Privileged Identity Management

Note - This lab requires an Azure Pass. Please see lab 00 for directions.

Lab scenario

Microsoft Entra Privileged Identity Management (PIM) can manage the built-in Azure resource roles, as well as custom roles, including (but not limited to):

• User Access Administrator
• Contributor
• Security Admin
• Security Manager

You need to make a user eligible for an Azure resource role.

Estimated time: 10 minutes

Exercise 1 - pim with azure resources, task 1 - assign azure resource roles.

Sign in to https://entra.microsoft.com using a Global Administrator account.

Search for and then select Privileged Identity Management.

In the Privileged Identity Management page, in the left navigation, select Azure resources.

On the top menu, select Discover resources .

In the Azure resources – Discovery page, select your subscription.

In the Overview page, review the information.

In the left navigation menu, under Manage , select Roles to see the list of roles for Azure resources.

On the top menu, select + Add assignments .

In the Add assignments page, select the Select role menu and then select API Management Service Contributor.

Under Select member(s), select No member selected .

In the Select Miriam Graham from your organization that will be assigned the role. Then chose Select .

Select Next .

On the Settings tab, under Assignment type , select Eligible .

Eligible assignments require the member of the role to perform an action to use the role. Actions might include performing a multi-factor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers.

Active assignments do not require the member to perform any action to use the role. Members assigned as active have the privileges always assigned to the role.

Specify an assignment duration by changing the start and end dates and times.

When finished, select Assign .

After the new role assignment is created, a status notification is displayed.

Task 2 - Update or remove an existing resource role assignment

Follow these steps to update or remove an existing role assignment.

Open Microsoft Entra Privileged Identity Management .

Select Azure resources .

Select the subscription you want to manage to open its overview page.

Under Manage , select Assignments .

On the Eligible assignments tab, in the Action column, review the available options.

Select Remove .

In the Remove dialog box, review the information and then select Yes .

Assignment Types

At a time when security breaches seem to be an everyday occurrence, it’s become more and more important to protect resources with more than just a username and password. It’s even more important to protect resources from INTERNAL threats. By implementing Azure AD Privileged Identity Management, organizations can protect their resources with improved security features, and even keep an eye on what legitimate administrators are doing.

In this lesson, you’ll learn how to implement Azure AD Privileged Identity Management. We’ll start the lesson by touching on an overview of what Azure AD Privileged Identity Management is and what it offers. We will then work through the deployment of PIM and how it works with multi-factor authentication. As we work through some demos, you will learn how to enable PIM and how to navigate tasks in PIM.

We’ll then cover the activation of roles and the assignment of those roles, including permanent roles and just-in-time roles. We’ll also cover the concepts of updating and removing role assignments, reinforcing these concepts through demonstrations.

We’ll round out the lesson with supported management scenarios, configuring PIM management access, and how to process requests. 

Learning Objectives

• Activate a PIM role
• Configure just-in-time resource access
• Configure permanent access to resources
• Configure PIM management access
• Configure time-bound resource access
• Create a Delegated Approver account
• Process pending approval requests

Intended Audience

• People who want to become Azure cloud architects
• People who are preparing to take Microsoft’s AZ-101 exam

Prerequisites

• Moderate knowledge of Azure Active Directory

 To see the full range of Microsoft Azure Content, visit the  Azure Training Library .

Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions. In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs. In his spare time, Tom enjoys camping, fishing, and playing poker.

Emilyvanputten.com

Azure AD role-assignable groups

by Emily | Aug 7, 2020 | Azure AD , Privileged Identity Management

Group creation

Assigning Azure AD Roles

Group Perspective

Assigning groups to Azure AD roles and Privileged access groups, a first look!

On August 13th 2020, Alex Simons (Microsoft Identity PM) announced that assigning groups to Azure AD roles in now in public preview . This feature is one of the most requested features to be found in the Azure AD feedback forum .

I have been following this feature request for a while now, and up until recently Microsoft stated that implementing Azure AD role assignment for Azure AD groups wasn’t the issue, the issue was more related to who is able to manage those groups. For example, if enabled how can we circumvent that someone with the “User Administrator” role (capable of adding users to groups) is capable of adding someone to the group used to assign Global Administrator rights. When implemented incorrectly, this new “feature” could then introduce a new security risk in your environment.

Assigning groups to Azure AD roles requires an Azure AD Premium P1 license at minimum, for the Privileged Identity Functionality an Azure AD Premium P2 license is needed.

Disclaimer:  This post reflects the status of assigning groups to Azure AD roles as of August 20, 2020. Functionality may change, even right after this post has been published.

So, let’s walk through on what was announced and see..

So, up until now when you wanted to assign a user an Azure AD role, you had to include the user account directly in the role. Verifying which account has what privileges is therefore hard, especially if you don’t have Azure AD Privileged Identity Management (PIM) licensed.

For a more in depth overview of what Azure AD Privileged Identity Management (PIM) is, please see another blogpost I wrote on this subject here: Lessons learned while implementing Azure AD Privileged Identity Management (PIM)

Changed behaviour while adding members to Azure AD Roles

On the topic of PIM, I also noticed some changed functionality when adding users when you have PIM enabled in your environment. If you don’t have PIM enabled you can assign a user to a role, but if you have PIM enabled there is another experience where when you want to assign an Azure AD role you are actually redirected to the Privileged Identity Management blade, where you can directly create an Eligible (must be activated) or Active (always active) assignment.

Adding users to Azure AD roles via Group membership

In order to add users to Azure AD roles via Group membership you first have to create a new group, so it’s not possible to repurpose an existing group for this.

New groups have the option to set the “Azure AD roles can be assigned to the group (Preview)” option which can be set to either “No” or “Yes”. When you switch this setting to ‘Yes’ the group’s eligibility for role assignment is permanent. Besides that you can only have a membership type of Assigned, so using Dynamic Groups is not supported, and within the wizard you can only add users as member and not groups (group nesting). Interestingly, you can assign multiple Azure AD roles to the group.

If you want to create the Group with the “Azure AD roles can be assigned to the group (Preview)” option enabled you will get an extra confirmation screen:

The option “Azure AD roles can be assigned to the group (Preview)” is only visible if you are member of either the Global Administrator or Privileged Role Administrator role.

Privileged access groups

Once a group with the option to enable Azure AD role assignments is created and you have PIM enabled, a new option becomes available called “Privileged access (Preview)”.

Enabling this option gives us the following options:

Define Eligible or Active assignments to the group

On the group you can assign members or owners using the capabilities provided by PIM. So for example, while adding our user as a member of the group permanently earlier in this article, I now have the option to make the membership Eligible. Also notice that this assignment type is time bound, with a maximum of 1 year.

It’s also interesting to notice that if you want to update an Active Assignment you will not be allowed to Permanently assign an Active role by default. And that assigning an Active role has a maximum allowed assignment duration of 6 months. Once the group is enabled for Privileged Access and you want to add a member, then you don’t have the option “Permanently assigned” available. Also notice that providing a justification is mandatory.

The default options described above are configurable though, trough the settings, so you are able to configure these depending on your requirements.

Activating your Azure AD role while using Privileged access groups

It’s interesting to see that once a user is set to Eligible for the privileged access group, that the Azure AD role doesn’t show up under Eligible Assignments when the user browses to My Roles in PIM. In order to active the Azure AD role in this scenario, the user must go to Privileged access groups (Preview) and active the role from there.

Once the role is activated via the group, it will show up under Active assignments, and what’s interesting to see is that at this time it’s still displayed as being permanent. But I expect that to be fixed while the functionality is still in preview.

Within the PIM settings of the group you can also specify that any Activation request for the group must be approved. This works similar to approval in PIM as we already know it. You define that approval is mandatory and specify who can approve. This can either be a user or a group.

If the user now requests to activate the privileged access group, he will receive the message that the request is pending for approval

The approver doesn’t see the request under Privileged Identity Management | Approve requests but has to go to Privileged Identity Management | Privileged access groups (Preview) and select the group, from there the Approve Requests functionality is providing the ability to approve the request.

I hope this walkthrough gave you an idea on the new possibilities as announced in the public preview. And there is much more to cover actually when it comes to PIM, like more in depth information about auditing and access reviews.

Microsoft has addressed its own concerns by only allowing Global Administrators and Privileged Role Administrators to create the groups enabled for Azure AD role assignment. And having this functionality combined with Privileged Identity Management (PIM) makes the solution even better. Another reason to buy an Azure AD Premium P2 license for your administrative accounts at least.

A winning feature is that by using Privileged access with Azure AD Groups is that you can enable multiple Azure AD roles at once, this could save you creation of a custom role in some cases when using PIM.

While there are still some little fixes which must be applied, for now this looks like a welcome addition for any Azure AD tenant using Premium functionality.

Assigning groups to Azure AD roles is now in public preview!

Use cloud groups to manage role assignments in Azure Active Directory (preview)

Management capabilities for privileged access Azure AD groups (preview)

2 thoughts on “ Assigning groups to Azure AD roles and Privileged access groups, a first look! ”

• Pingback: Active Directory Identity Governance – Privileged Identity Management - JanBakker.tech

make the Security Admin Role a member Privilege Role Admin in Privilege Identity Management in Azure AD is this possible??

Leave a Reply Cancel reply

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

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

Privacy Overview

Removing Unknown Azure RBAC Role Assignments with PowerShell

5 minute read

Ever wondered how to programmatically find and remove Azure RBAC role assignments of ‘Unknown’ ObjectType, at scale, in your Azure subscription?

In this blog I’ll describe the problem using an example scenario and then show you a scripted solution using PowerShell.

Unknown Role Assignments with Identity Not Found

Looking at Access Control (IAM) role assignments within the Azure portal, you might’ve noticed that a security principal is listed as “Identity not found” with an “Unknown” type.

There’s 2 possible reasons this can occur:

• You recently invited a user when creating a role assignment
• You deleted a security principal that had a role assignment

Note - a security principal can be a:

• Service Principal
• Managed Identity

Example Scenario of How This Can Occur

Let’s examine an example scenario for the 2nd possible reason listed above: You deleted a security principal that had a role assignment.

Imagine you’re testing Azure policy definitions using ‘deployIfNotExists’ or ‘modify’ effects - a managed identity needs to be created because that’s how Azure policy has the required permissions to action those effects specified in your policy definitions.

In the screenshot below you can see a managed identity will be created automatically as part of the task to assign a policy initiative. So far, so good!

Now this new managed identity will also have a corresponding RBAC role assignment created on the scope defined by the policy assignment.

So if you are assigning your policy to the subscription scope a role assignment will be applied at the subscription level.

If, later on, you delete that policy assignment the managed identity will also automatically get deleted, which makes sense, because you might not need that managed identity ever again - but wait, for some reason the RBAC role assignment still exists for the deleted managed identity.

This leaves you with a security principal on the Access Control (IAM) role assignments page that displays as “Identity not found” with an “Unknown” type. Not harmful, I think, but also not a clean/tidy experience to encounter.

My hope is that Microsoft identify this as a problem and resolve it - so I’ve reached out to the Azure Policy Program Managers via Twitter…

TIL - via testing #AzurePolicy Assignments using DeployIfNotExists/Modify effects - a Managed Identity is created. If I delete the #AzurePolicy Assignment the Managed Identity is also deleted - BUT the RBAC Role Assignment still exists for the Managed Identity. Oops :) — Jesse Loudon (@coder_au) May 18, 2020

Finding Role Assignments of ‘Unknown’ ObjectType with PowerShell

There’s no current method I know of to easily find and remove these ‘Unknown’ type role assignments via the Azure Portal without doing a bunch of clicking.

So to programmatically discover Azure RBAC role assignments of the ‘Unknown’ type we can use the Get-AzRoleAssignment cmdlet:

Above you can see we are searching on the ObjectType field matching the value ‘Unknown’.

An example output of the above cmdlet is shown below.

You may have noticed above that the values for DisplayName and SignInName are null (empty) and that ObjectType equals ‘Unknown’. This is clear indication that you’ve found a role assignment where the corresponding security principal has either been deleted, or a security principal has been invited (while the role assignment was created) and has not yet replicated across regions.

Removing Role Assignments of ‘Unknown’ ObjectType with PowerShell

To programmatically remove Azure RBAC role assignments of the ‘Unknown’ type we can use the Remove-AzRoleAssignment cmdlet.

Please note:

• When removing a role assignment you’ll need to specify the ObjectID, RoleDefinitionName and Scope
• You’ll also need Microsoft.Authorization/roleAssignments/delete permissions, such as User Access Administrator or Owner
• Always test your scripts in a development environment first before using in production.

The PowerShell script above does the following:

• Finds all Azure role assignments in the subscription where ObjectType equals ‘Unknown’
• Exports the results to CSV where you can review/send off for ITSM approvals, etc
• Imports the results from CSV and sets variables for the required fields needed to remove a role assignment (ObjectID, RoleDefinitionName and Scope)
• Uses a for each loop to remove each role assignment specified from the imported CSV

For the simplest removal script without any authentication or CSV export/import for documentation purposes, you can use the following PowerShell script:

Closing Remarks

Finding and removing Azure RBAC role assignments might not be a common occurence for your team but I think it’s important to share with the community how to complete a task like this programmatically.

I came across this problem during my testing of Azure policy assignments, which use a managed identity for certain effects, and would’ve never thought to look for these role assignments otherwise.

If you don’t look, you’ll never find :)

Leave a comment

You may also enjoy.

Flexing your Security Governance with Azure Policy as Code

3 minute read

I recently had the pleasure of presenting a livestream session via Microsoft Reactor Sydney on a subject close to my heart.

Talking Azure Policy as Code on CtrlAltAzure podcast

4 minute read

Appearing as a guest on the Ctrl+Alt+Azure podcast to talk Azure Policy as Code with hosts Tobias Zimmergren and Jussi Roine

How to Win vs Azure Policy Non-Compliance

Fixing a design flaw with the existenceCondition for builtin policies

HashiTalks ANZ: DRY Coding with Terraform, CSVs, ForEach

How combining Terraform with CSVs and ForEach we can deploy at scale from large datasets

Daniel's Tech Blog

Cloud Computing, Cloud Native & Kubernetes

Assigning RBAC permissions with Azure Resource Manager templates

Recently, I updated my AKS ARM template supporting the latest AKS feature set and important RBAC role assignments for the AKS cluster.

After having a hard time, I managed to get the RBAC role assignment working.

When you now think what should be so complicated? Check out my tweet on Twitter getting the background information.

-> https://twitter.com/neumanndaniel/status/1294272253211947008

It is not as easy as it sounds. Just using the Microsoft.Authorization resource provider as in the ARM template reference only works on resource group level and above like subscriptions.

-> https://docs.microsoft.com/en-us/azure/templates/microsoft.authorization/roleassignments

Here starts our journey of todays blog post. I walk you through my findings and provide you with the necessary guidance doing the RBAC role assignment with ARM templates in the correct way. So, at least I can spare you some time when this topic arises.

Let us start from the beginning why you can use the Microsoft.Authorization resource provider only on resource group level and above like subscriptions.

When using the RP Microsoft.Authorization we specifically using the resource type roleAssignments.

As you can deploy ARM templates only on MG (management group), subscription and RG (resource group) level, tenant level is also possible, the RP targets the resource at the deployment level. This excludes resources and their sub resources for instance a Virtual Network and its subnets.

Let us take a look at two ARM templates with an RBAC role assignment on subscription and RG level.

As seen above the template assigns a user object Network Contributor permission on the subscription level.

The Azure CLI command explicitly targets the subscription for the deployment.

Similar looks the template targeting the resource group.

Using the following ARM template assigning the Network Contributor permissions on a VNET subnet will not work.

We get an error message that the assignment scope does not match the scope of the deployment.

So, how you going to do an RBAC role assignment on a resource or sub resource?

Via a sub resource deployment. Each RP has a providers resource type roleAssignments which we can leverage in a sub resource deployment assigning the RBAC role to resources like a VNET or sub resources like a VNET subnet.

The template assumes that the target resource lives in the same RG that the deployment targets. If this is not the case, you must use a nested / linked template where you can specify the resource group.

One important part in the RBAC role assignment via sub resource deployments plays the dependency between the name and the type.

The segment length must be the same.

Not the name defines the segment length it is the type and the /providers/ does not count towards the length.

From the given example someone might think the segment length is five, but as I mentioned that /providers/ does not count the actual segment length is four.

Looking at the name this is true for our name.

I hope you got some useful insights into RBAC role assignments via Azure Resource Manager templates that can spare you some time in the foreseeable future.

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