arm template create role assignment

This browser is no longer supported.

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

Microsoft.Authorization roleAssignments

• 1 contributor
• 2020-10-01-preview

Bicep resource definition

The roleAssignments resource type is an extension resource , which means you can apply it to another resource.

Use the scope property on this resource to set the scope for this resource. See Set scope on extension resources in Bicep .

The roleAssignments resource type can be deployed with operations that target:

• Resource groups - See resource group deployment commands
• Subscriptions - See subscription deployment commands
• Management groups - See management group deployment commands
• Tenants - See tenant deployment commands

For a list of changed properties in each API version, see change log .

For guidance on creating role assignments and definitions, see Create Azure RBAC resources by using Bicep .

Resource format

To create a Microsoft.Authorization/roleAssignments resource, add the following Bicep to your template.

Property values

Roleassignments, roleassignmentproperties, quickstart templates.

The following quickstart templates deploy this resource type.

ARM template resource definition

Use the scope property on this resource to set the scope for this resource. See Set scope on extension resources in ARM templates .

To create a Microsoft.Authorization/roleAssignments resource, add the following JSON to your template.

Terraform (AzAPI provider) resource definition

Use the parent_id property on this resource to set the scope for this resource.

• Resource groups
• Subscriptions
• Management groups

To create a Microsoft.Authorization/roleAssignments resource, add the following Terraform to your template.

Was this page helpful?

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

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

• Top of Page

Defining RBAC Role Assignments in ARM Templates

It’s no secret I’m a big fan of Azure Resource Manager (ARM) templates. Getting started with ARM templates is hard, but well worth the effort, and make it significantly easier to have reproduceable, consistent deployments of your Azure resources.

One thing that I had been feeling left out, however, was being able to assign permissions to Azure resources during creation. Azure’s Role-based Access Control (RBAC) mechanism is a powerful way to control who can manage and access your resources, and having to do this through scripting was possible, but cumbersome at times.

A few days ago, I realized that you can actually create RBAC role assignments through ARM templates just like any other resource. This capability is not new by any means, I just had missed it before!

Creating an assignment

To create an assignment, you need the following information:

• The ID of the role you want to assign. This is a long string that contains the subscription id and the role identifier (both GUIDs).
• The object ID of the user/group/service principal you want to grant access to.
• The scope at which you want to assign the role, which is going to be either a subscription, resource group, or resource id.

Here’s an example of creating such an assignment:

Here we grant the members of an Azure Active Directory group the Monitoring Contributor built-in role to the resource group the template is deployed to.

Also interesting here is that you don’t need to specify a location property in the resource.

Some gotchas

There are a couple of things to watch out for when doing this.

The first one is that to assign a role, you need the objectId of the AAD user/group/principal, rather than the name. This is cumbersome because there’s no way to resolve these within the ARM template itself, so you’ll always need to pass these as input parameters.

A more significant issue, however, is the name of the roleAssignment resource, which needs to be a unique GUID.

This is a problem if, for example, you’re assigning role permissions at the resource group or individual resource level, rather than globally at the subscription.

For example, in my case I was creating a template that would be used to deploy multiple copies of the same resources into different resource groups within the same subscription.

If the GUID that defines the role assignment name is hardcoded in the template, then each time I ran the template, the scope of the role assignment would get overwritten with the id of the last resource group it was deployed to. Clearly, this is undesirable.

What we need then, is a way to ensure that each deployment to a different resource group uses a different GUID for the role assignment, but at the same time, ensure that the same one is used when deploying to the same resource group.

Clearly, providing the assignment GUID as a parameter is an easy workaround, but very cumbersome.

A better workaround comes from the guid function! It takes one or more strings that are used to calculate a hash, very much like the uniquestring function; only this one generates a string in GUID format instead.

By using the guid function with the resource group id and some other consistent stuff as input, we can solve our problem in an elegant way:

• Azure (41) ,
• Security (2)

Tomas Restrepo

Software developer located in Colombia.

• ← Previous
• Next →

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.

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

quickstart-role-assignments-template.md

Latest commit, file metadata and controls, quickstart: assign an azure role using an arm template.

Azure role-based access control (Azure RBAC) is the way that you manage access to Azure resources. In this quickstart, you create a resource group and grant a user access to create and manage virtual machines in the resource group. This quickstart uses an Azure Resource Manager template (ARM template) to grant the access.

[!INCLUDE About Azure Resource Manager ]

If your environment meets the prerequisites and you're familiar with using ARM templates, select the Deploy to Azure button. The template will open in the Azure portal.

:::image type="content" source="~/reusable-content/ce-skilling/azure/media/template-deployments/deploy-to-azure-button.svg" alt-text="Button to deploy the Resource Manager template to Azure." border="false" link=" https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fquickstarts%2Fmicrosoft.authorization%2Frbac-builtinrole-resourcegroup%2Fazuredeploy.json ":::

Prerequisites

To assign Azure roles and remove role assignments, you must have:

• If you don't have an Azure subscription, create a free account before you begin.
• Microsoft.Authorization/roleAssignments/write and Microsoft.Authorization/roleAssignments/delete permissions, such as Role Based Access Control Administrator
• To assign a role, you must specify three elements: security principal, role definition, and scope. For this quickstart, the security principal is you or another user in your directory, the role definition is Virtual Machine Contributor , and the scope is a resource group that you specify.

Review the template

The template used in this quickstart is from Azure Quickstart Templates . The template has two parameters and a resources section. In the resources section, notice that it has the three elements of a role assignment: security principal, role definition, and scope.

:::code language="json" source="~/quickstart-templates/quickstarts/microsoft.authorization/rbac-builtinrole-resourcegroup/azuredeploy.json":::

The resource defined in the template is:

• Microsoft.Authorization/roleAssignments

Deploy the template

Sign in to the Azure portal .

Determine your email address that is associated with your Azure subscription. Or determine the email address of another user in your directory.

Open Azure Cloud Shell for PowerShell.

Copy and paste the following script into Cloud Shell.

Enter a resource group name such as ExampleGrouprg.

Enter an email address for yourself or another user in your directory.

Enter a location for the resource group such as centralus.

If necessary, press Enter to run the New-AzResourceGroupDeployment command.

The New-AzResourceGroup command creates a new resource group and the New-AzResourceGroupDeployment command deploys the template to add the role assignment.

You should see output similar to the following:

Review deployed resources

In the Azure portal, open the resource group you created.

In the left menu, click Access control (IAM) .

Click the Role assignments tab.

Verify that the Virtual Machine Contributor role is assigned to the user you specified.

Clean up resources

To remove the role assignment and resource group you created, follow these steps.

Enter the email address of the user with the role assignment to remove.

Enter the resource group name to remove such as ExampleGrouprg.

If necessary, press Enter to run the Remove-AzResourceGroup command.

Enter Y to confirm that you want to remove the resource group.

[!div class="nextstepaction"] Tutorial: Grant a user access to Azure resources using Azure PowerShell

Good Workaround!

Assigning PIM Azure RBAC permissions using Terraform and ARM template

Currently, Terraform does not support eligible assignments of permissions in Azure RBAC, and only active assignments using the azurerm_role_assignment resource. Continue reading if you want to be able to assign your eligible assignments using ARM or Terraform (Terraform willl use the ARM template).

With the 3rd version of the PIM APIs, we have something called Role Eligibility Schedule Request, available through documented through the API documentation and the ARM documentation . However, the documentation can be a bit difficult to understand, especially because the roleDefinitionId in the ARM template must be provided differently than the when using the API.

Let’s first define an ARM template, as below, that can be used to assign eligible permissions:

Parameter – principalId

This should be the objectid of the principal you are granting the access to. If you are assigning permissions to user [email protected], use the following value:

Parameter – roleDefinitionId

I spent way too much time to figure out the format of the value for this parameter, but it should be like this:

The first guid (1272951b-df54-45eb-9c08-a8c93ea18302) should be changed to the subscription i d of your subscription, while the second guid (b24988ac-6180-42a0-ab88-20f7382dd24) is the Azure RBAC role id, found here . The example provided is “Contributor”.

Parameter – id

All eligible schedule requests have a unique ID, defined client side, so this should basically just be a unique guid. The ARM template generates ut automatically.

Parameter – requestType

I have defaulted this to AdminUpdate, as that will also work with new assignments. However, due to how PIM works, in order to actually remove an assignment, you must deploy the ARM template with the value “AdminRemove”. This is super anoying, from a Terraform perspective. Also, when deploying with AdminRemove for a second time, it fails with RoleAssignmentDoesNotExist.

Deploying using ARM template

Here is how to deploy eligible contributor permission to a user with objectid e9176fb9-63d3-480a-a51f-e5399059b588 on subscription level:

And this is how to do the same thing on resource group level:

Now that we have things going with ARM template, let’s do it with Terraform aswell.

Deploying using Terraform

Some say it’s cheating, but we need to use the ARM template here aswell. This is because currently no Terraform resource exist for eligible role assignments.

Also, Terraform does not support comments in JSON documents, so remove them before saving the file.

Go to https://github.com/goodworkaround/terraform-az-rbac-pim-assignment and clone my Terraform example. The example uses the Azure AD provider to create groups, which is not necessary. You can get away with only the AzureRM provider, but then you need to specify the objectids of the principals you are granting access to.

There are two modules available:

PIM Assignment – Subscription

The following code will create an Azure AD group called “subscription_owner_group_1” and assign it eligible “Owner”

As an admin in PIM, you will find the following assignment:

Members of the group should see this in PIM:

It is worth noting that simply unloading the module will not remove the assignment. Instead, the module must be used with request_type = “AdminRemove”, as it will remove the permission. Then you can remove the module.

PIM Assignment – Resource Group

The following code will create an Azure AD group called “rg_contributor_group_1”, a resource group “rg1” and delegate the group eligible Contributor on the resource group:

Share this:

Published by Marius Solbakken

View all posts by Marius Solbakken

16 thoughts on “ Assigning PIM Azure RBAC permissions using Terraform and ARM template ”

Nice article, could you please tell me the Role that is assigned to the service principle doing this task?

Hi, if you mean the role of the principal that deploys the ARM template, it is either Owner or User Access Administrator. 🙂

thank you! I will try with that.

Have you tried using AdminRemove test for the same principle ID which was added by AdminAdd step? It fails every time.

I have, with success – what is your error message?

Error: removing items provisioned by this Template Deployment: `properties.OutputResources` was nil – insufficient data to clean up this Template Deployment

Ah yes, can you try to disable the delete_nested_items_during_deletion setting of the azurerm provider to see if that resolves things?

yup that worked, I don’t really use ARM deployment with TF, but your article has been quite helpful.

one more thing I noticed, after assigning az resource PIM role to principleID, If I run the same release again, it fails with error that { “code”: “Conflict”, “message”: “A role assignment request with Id: a2d47b66-96d6-16d4-5b35-29b3139cae94 already exists” } . I thought it would just pass through

Yes I know. The API expects a unique is each time. Terrible design on the Microsoft side

Will this work for ADRoles like “User Administrator” or “Application Administrator” . I am trying to work make PIM for Azure AD roles

No, this is for RBAC only. Azure AD PIM roles is a completely different api 🙂

That is right, also make sure yours SPN has the right api permissions and Rbac to do this via code for Az Resource Roles or AD roles 🙂 For Resource Roles I was able to get it working with User Access Admin on the subscription as well as Contributor Access with User.Read, PrivilegedAccess.Read.AzureResources and PrivilegedAccess.Write.AzureResources access with Grant persimmons as least .

Great solution! A couple of questions if you don’t mind!

1/ we were thinking to use ‘az rest’ to achieve the same but all of our testing using: https://docs.microsoft.com/en-us/rest/api/authorization/role-eligibility-schedule-requests/create#requesttype

with basically an identical payload it didn’t create the assignment, it left it in a strange ‘pending’ state

any thoughts on why this might be?

2/ any ideas on setting the role policy via ARM or REST? eg MFA required, 4 hours, etc… it uses PATCH method: https://docs.microsoft.com/en-us/rest/api/authorization/privileged-role-policy-rest-sample#update-a-role-management-policy

This is great solution but I am facing an issue when running AdminRemove on resource group template, it fails by saying below error:

Error: removing items provisioned by this Template Deployment: deleting Nested Resource “/subscriptions/***/resourceGroups/***/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/***”: resources.Client#DeleteByID: Failure sending request: StatusCode=405 — Original Error: Code=”Failed” Message=”The async operation failed.” AdditionalInfo=[{“message”:”The requested resource does not support http method ‘DELETE’.”}]

Hi, for this you will need to disable the delete_nested_items_during_deletion feature tag. This was defaulted to true some point in the past.

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/resource_group_template_deployment

Leave a comment Cancel reply

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

DEV Community

Posted on Aug 3, 2020 • Updated on Aug 21, 2020

Deploying across subscriptions; Using Scope with ARM Templates for your deployments in Azure

Most of the time, when you think about ARM templates, it's about deploying objects in a Resource Group. It’s the most used deployment level. But ARM templates allow you to deploy more than resource group objects. There are four levels or scopes in ARM template, Tenant, Management Group, Subscription, and resource group. These levels are called scopes. The logic behind resource deployment in the first three scopes is the same as in the Resource group scope. At all scope, ARM templates use the JSON notation, with the five sections (Parameters, Variables, Resources, Functions, and Outputs). But schemas are different and of course, you are only allowed to deploy resources related to the scope. Impossible to deploy a VNET in the management scope (at least directly).

What can you deploy at these scopes?

For the Tenant Scope, you need some extra permission even for a Global Azure AD Administrator. You need an elevate access to management subscription and management group .

More you may need to have extra privilege on the root of the tenant.

Or with Object ID instead of username

If you want to create two management groups, one parent and one child using ARM templates, you will need to use the tenant scope. How can you represent in ARM the hierarchy of the two groups? The management group resource in ARM template look like this

Under the properties, you can add the parent detail like this

Creating the management group will be like this

To deploy it, you can use the New-AzTenantDeployment cmdlet

What is very interesting, all scopes also support deployment objects, Microsoft.Resources/deployments. You can use it to deploy multiple objects, but you can also use it for nested deployment across scopes. With the deployment resource, you can deploy management group objects from the tenant scope, subscription object from the tenant scope, or management group scope and you can deploy resource group objects from the subscription scope.

Imagine the situation where you need to deploy a network infrastructure across two subscriptions. You need to deploy the hub network in one subscription and a spoke network in another subscription. Using only the resource group scope you will need to have at least two deployments. Using the proper scope you can do it with only one template. The tenant and the Management group scope let you deploy subscription scope objects which include resource group deployment. In our example, two VNET in different subscriptions and the peering between these two VNET can be done with one template.

You will need to use the tenant or the management group's scope. The management group require fewer permissions so let use it

Here’s what you can see parameters

The first task is to ensure the resource group in the subscription is created before deploying the VNET by using a first deployment resource at the subscription level and use the resource group resource.

Then create a deployment resource inside the first deployment resource this time at the resource group level to deploy the network.

Then you can create the two peering objects, but you will need to ensure the two VNET are deployed. Remember to create a peering resource, as it is a child resource of the virtual network object, you need to include the VNET name in the peering name.

The complete template is here.

There are some limitations to use multi scope deployment. You cannot use resource group scope deployment functions similar to resourceID or resourcegroup(). If you need to use these functions you will need to use a linked template instead of inline deployment presented in this example. This is the best practice.

Top comments (0)

Templates let you quickly answer FAQs or store snippets for re-use.

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

How I Conquered the AWS Certified DevOps Engineer Professional Exam in 60 Days

Damien Burks - Apr 11

Azure Monitoring Tools for GPU Usage and Cost Optimization

sajjad hussain - Apr 14

Setup NGINX

Akbar Nafisa - Apr 15

Docker networking, how to connect different containers

Diona Rodrigues - Apr 11

We're a place where coders share, stay up-to-date and grow their careers.

DevOps & Azure Architect | Consultant | Speaker | Microsoft MVP

Creating a rbac role assignment, using an arm template.

In an earlier post on provisioning a Let’s encrypt SSL certificate to a Web App , I touched upon the subject of creating an RBAC Role Assignment using an ARM template. In that post I said that I wasn’t able to provision an Role Assignment to a just single resource (opposed to a whole Resourcegroup.) This week I found out that this was due to an error on my side. The template for provisioning an Authorizaton Rule for just a single resource, differs from that for provisioning a Rule for a whole Resourcegroup.

Here the correct JSON for provisioning an Role Assignment to a single resource:

As Ohad correctly points out in the comments the appServiceContributerRoleGuid , should be a unique Guid generated by you. It does not refer back to a Guid of any predefined role.

In contrast, below find the JSON for provisioning an Authorizaton Rule for a Resourcegroup as a whole. To provision a roleAssignment for a single resource, we do not need to set a more specific scope, but completely leave it out. Instead the roleAssignment has to be nested within the resource it applies to. This is visible when comparing the type, name and scope properties of both definitions.

• Pingback: Add a SSL certificate to your Azure Web App using an ARM template – Henry Been

Great stuff!

1. Would be great if you could link to the appropriate docs docs for this. Specifically the ones that explain Microsoft.Web/sites/providers/roleAssignments, or really the more general case of Microsoft.Foo/Bar/providers/roleAssignments.

2. I would clarify the constraints on the name, i.e. that it has to be {resourceName}/Microsoft.Authorization/{uniqueRoleAssignmentGuid}. Specifically, when you write appServiceContributerRoleGuid it’s confusing, because one might mistakenly think they should use the known role GUIDS (e.g. b24988ac-6180-42a0-ab88-20f7382dd24c).

Thanks, Ohad

Thank you. You are right that the Guid might be confusing, so I added a sentence there. As for documentation, the documentation in this area is kind of lacking. The above is the result of a lot of Googling, trying, looking at API calls and finding out the specific differences. There is not a single thing I can point to as my source unfortunately.

Thanks for your post, the name format and the scope are the keys to solve my problem. Thanks for your inspiration.

Geef een reactie Reactie annuleren

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *