Azure DevOps - Managed Identity Linked Subscription not able to do role assignments

Question

Azure DevOps - Managed Identity Linked Subscription not able to do role assignments

Sumit Gaur 455

Hi.

We have created a User Assigned Managed Identity (UAMI) in our Azure subscription and assigned it the following roles at the subscription scope:

Contributor
Role Based Access Control Administrator

The Role Based Access Control Administrator assignment has a condition configured to restrict which roles can be assigned and to which principal types. The UAMI is linked to an Azure DevOps service connection and is used by our Terraform deployment pipeline.

During deployment, Terraform attempts to create Azure RBAC role assignments. However, the pipeline fails with the following error:

Error: unexpected status 403 (403 Forbidden) with error: AuthorizationFailed:
The client '<redacted>' with object id '<redacted>' does not have authorization
to perform action 'Microsoft.Authorization/roleAssignments/write' over scope
'/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<key-vault-name>/providers/Microsoft.Authorization/roleAssignments/<role-assignment-id>'
or the scope is invalid.

If access was recently granted, please refresh your credentials.

Terraform resource:

resource "azurerm_role_assignment" "role_assignment_integration_account_key_vault" {
  for_each             = toset(local.integration_account_key_vault_roles)
  scope                = data.azurerm_key_vault.key_vault_corp.id
  role_definition_name = each.value
  principal_id         = var.azure_logic_apps_service_principal_id
}

Additional details:

The Azure DevOps service connection authenticates using the User Assigned Managed Identity.

The UAMI has both Contributor and Role Based Access Control Administrator roles assigned at the subscription scope.

The target principal is a Integration Account SPN - Azure Logic Apps

The roles being assigned include:

Key Vault Secrets User

  Key Vault Certificate User

  
     Key Vault Crypto User

     
     The role assignment operation fails with `Microsoft.Authorization/roleAssignments/write`.
```We would like to understand whether the conditional Role Based Access Control Administrator assignment could be preventing the role assignment operation, despite the required roles appearing to be included in the allowed role list, or whether there are additional requirements for creating role assignments through a federated Azure DevOps service connection using a User Assigned Managed Identity.

The same would work if i tried run from a user which has owner access. 

![User's image](/api/attachments/319ec215-9e05-4c3c-bd3c-02b4778b2642?platform=QnA)

Vinayteja Lellela 0 Reputation points Microsoft External Staff Moderator

2026-06-21T16:51:16.14+00:00
Hey! From what you’ve shared, Terraform is authenticating to Azure using an Azure DevOps service connection backed by a User Assigned Managed Identity (UAMI), but the managed identity is getting a 403 Forbidden when Terraform tries to create an RBAC role assignment:

AuthorizationFailed: ... does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write'

Does the conditional RBAC Administrator assignment block this?

Based on the provided docs, the key point is that assigning roles requires explicit permission to write role assignments—typically via Owner, User Access Administrator, or a custom role that includes:

Microsoft.Authorization/roleAssignments/write

Your UAMI currently has:

Contributor

Role Based Access Control Administrator (with a condition)

With the info provided, we can’t confirm whether your conditional RBAC Administrator still grants roleAssignments/write in the exact scenario Terraform is performing. However, the error you’re seeing is very specific: the identity lacks authorization for Microsoft.Authorization/roleAssignments/write on the target scope.

So even if the “required roles” appear to be allowed in your conditional assignment, RBAC conditions can still result in the assignment being effectively blocked for:

the exact scope being targeted (you’re assigning at a Key Vault scope, not just subscription),

the resource type involved,

or the principal type / role assignment characteristics Terraform is using.

Also note: your report mentions that the same Terraform run works when executed by a user with Owner access—this aligns strongly with the idea that Owner includes the necessary Microsoft.Authorization/roleAssignments/write permission that your managed identity path is missing.

Additional requirement: role assignment permissions must apply to the RBAC scope being used

The relevant managed-identity RBAC guidance included in the docs calls out that permission to create role assignments is needed “typically available with Owner or User Access Administrator … or a custom role that has Microsoft.Authorization/role assignments/write”.

And one of the listed “fix now” expert-solution summaries for similar authorization failures also points to the same permission requirement: the principal needs permission to assign the required roles.

What to try (practical troubleshooting steps)

Confirm the managed identity has role assignment write permission on the Key Vault scope (not just subscription). Your Terraform resource sets:

scope = data.azurerm_key_vault.key_vault_corp.id That means the attempted write is over the Key Vault scope.

Ensure the identity has Microsoft.Authorization/roleAssignments/write for that scope. Since the docs explicitly say this is typically granted via Owner or User Access Administrator (or a custom role with that permission), validate whether your conditional “RBAC Administrator” assignment actually results in that permission being granted for the Key Vault scope and the specific assignment operation.

Account for credential refresh / propagation (small chance, but easy check). The error text itself suggests: “If access was recently granted, please refresh your credentials.” If you just changed the managed identity RBAC, retry after a brief propagation window / ensure the service connection is using updated credentials.

1 answer

Your answer

Answer 1

Hello Sumit Gaur,

Greetings! Thanks for raising this question in the Q&A forum.

You've done a great job narrowing this down the setup looks correct on the surface (UAMI with Contributor + Role Based Access Control Administrator at subscription scope), yet Terraform gets a 403 when trying to write role assignments on the Key Vault. The root cause is almost certainly the condition on your Role Based Access Control Administrator assignment. Let me explain what's happening and walk you through how to fix it.

When you add a condition to the Role Based Access Control Administrator role, Azure evaluates that condition at the time of every roleAssignments/write call. If the role assignment includes conditions, they are evaluated, and access is only allowed if the conditions are met otherwise access is denied. The most common reasons the condition blocks a Terraform-initiated assignment even when the roles appear to be on the allowed list are:

The target principal type may not be permitted by your condition. Terraform is assigning roles to the Azure Logic Apps service principal, which is a ServicePrincipal principal type. If you are constrained in the principals you can assign roles to, the condition can prevent the assignment even if the role being assigned is correct. If your condition restricts assignments to only User or Group principal types, it will silently block assignments to service principals and managed identities.

Here are the steps to diagnose and fix this:

Step 1: Review the exact condition on your Role Based Access Control Administrator assignment

Go to Azure Portal > Subscription > Access control (IAM) > Role assignments. Find the Role Based Access Control Administrator assignment for your UAMI and click on it to view the condition expression. Look specifically for:

Which roles are allowed to be assigned
Which principal types are allowed (User, Group, ServicePrincipal)

Make sure ServicePrincipal is explicitly included in the allowed principal types, since the Logic Apps identity you are assigning to is a service principal.

Step 2: Verify the Key Vault roles are in the allowed roles list within the condition

Confirm that Key Vault Secrets User, Key Vault Certificate User, and Key Vault Crypto User are all explicitly listed in the condition's allowed roles. Even a small mismatch in the role definition ID (GUID vs display name) in the condition expression can cause the check to fail.

Step 3: Add principal_type to your Terraform resource

When you create a role assignment using an infrastructure as code technology like Terraform, it is important to specify the correct principal type. Otherwise, you might get intermittent deployment errors, especially when working with service principals and managed identities.

Update your Terraform resource to explicitly declare the principal type:

resource "azurerm_role_assignment" "role_assignment_integration_account_key_vault" {
  for_each             = toset(local.integration_account_key_vault_roles)
  scope                = data.azurerm_key_vault.key_vault_corp.id
  role_definition_name = each.value
  principal_id         = var.azure_logic_apps_service_principal_id
  principal_type       = "ServicePrincipal"
}

This ensures Azure does not have to look up and infer the principal type, which can also cause condition evaluation to fail or behave unexpectedly.

Step 4: Confirm the UAMI's Role Based Access Control Administrator role is active (not PIM eligible)

If you are using Privileged Identity Management (PIM), eligible assignments require the user to perform one or more activation actions before the role is usable — and managed identities cannot perform activation steps. Make sure the Role Based Access Control Administrator assignment for the UAMI is set to Active, not Eligible.

Step 5: Temporarily test without the condition

To isolate whether the condition is the exact blocker, you can temporarily remove it from the Role Based Access Control Administrator assignment on the UAMI and re-run the Terraform pipeline. If the pipeline succeeds without the condition, that confirms the condition expression is what's blocking the assignment. You can then re-add the condition with the correct principal type and role list.

Step 6: Check Entra audit logs for the exact condition evaluation failure

Go to Entra ID > Monitoring > Audit logs and filter by the UAMI's object ID and the time of the failed pipeline run. The log entries will show the exact condition attribute that was evaluated and why it was denied, which makes it much easier to fix the condition expression precisely.

If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,

Jerald Felix.

Share via

Azure DevOps - Managed Identity Linked Subscription not able to do role assignments

1 answer

Your answer