An Azure service used to deploy Grafana dashboards for analytics and monitoring solutions.
Hello Anuha,
Thank you for reaching out regarding this issue.
Azure role assignment creation during ARM/Bicep deployments can fail even when the deploying identity has Owner permissions. This is expected behavior because role assignment operations require Microsoft Entra ID (directory-level) permissions, not just Azure subscription-level RBAC.
This failure typically occurs due to one of the following conditions:
1. Missing Directory (Entra ID) Permissions
Creating role assignments requires the ability to write to principals in Microsoft Entra ID.
Common causes include:
- The deploying user is a Guest in the tenant
- The identity does not have User Access Administrator or higher
- Conditional Access or Entra restrictions block role creation
- A service principal used for deployment lacks directory write permissions
Resolution: Ensure the deploying identity is:
- A Member of the tenant (not Guest)
- Assigned User Access Administrator or higher at the subscription or higher scope
2. Identity Not Yet Available During Deployment
Role assignment creation can fail when targeting identities created in the same deployment, such as:
- System-assigned managed identities
- Newly created user-assigned managed identities
The service principal may not have fully propagated in Entra ID at deployment time.
Resolutions:
- Split the deployment into two steps:
- Create the identity
- Assign the role
- Or add an explicit ARM/Bicep
dependsOnto enforce ordering
- Create the identity
3. Scope Misalignment (Cross-scope Role Assignments)
If the role assignment scope differs from the deployment scope (for example, assigning at subscription scope while deploying at resource group scope), Azure performs additional authorization validation.
Resolution: Ensure the scope property of the role assignment matches a scope where the deploying identity has permissions.
4. Role Assignment Already Exists (GUID Collision)
Microsoft.Authorization/roleAssignments requires a deterministic and globally unique GUID. If the role assignment already exists but a new GUID is generated, the deployment fails.
Resolution: Use a deterministic GUID, for example:
guid(subscription().id, principalId, roleDefinitionId, scope)
5. Privileged Identity Management (PIM) Not Activated
If the Owner or User Access Administrator role is assigned via PIM but not activated, Azure treats the request as unauthorized.
Resolution: Activate the required role in PIM and retry the deployment.
Summary
This issue is not caused by missing subscription-level Owner permissions. Role assignment creation requires directory-level privileges, and Azure performs additional authorization checks beyond RBAC.
To consistently resolve this:
- Use a Member account (not Guest)
- Assign User Access Administrator or higher
- Activate PIM roles before deployment
- Separate identity creation and role assignment when necessary
- Use deterministic GUIDs for role assignment resources
Following these steps allows ARM/Bicep deployments involving role assignments to succeed without modifying the underlying template.