Share via

Recovery service vault IAM role permissions issue

ANIMESH 20 Reputation points
2025-11-18T16:31:46.9666667+00:00

A user's subscription level contributor role granted via PIM is not getting inherted on the recovery service vault present in that same subscription. Hence the user is not able to perform virtual machine recovery and getting an error related to virtualmachine/write permission and not able to create the virtual machine from the backup snapshot. While another user who has same subscription level contributor role (not granted via PIM) is able to restore the VM.

What could be the probable reason ?

Azure Backup
Azure Backup
An Azure backup service that provides built-in management at scale.
Answer accepted by question author
  1. Suchitra Suregaunkar 3,545 Reputation points Microsoft External Staff Moderator
    2025-11-19T04:45:35.55+00:00

    Hello ANIMESH

    Thank you for posting your query on Microsoft Q&A platform.The issue occurs because restoring a VM from a Recovery Services vault requires write permissions on the target resource group, not just on the vault. Even if the user has a Contributor role at the subscription level via PIM, the restore can fail due to one of these reasons:

    1. Deny Assignments or Locks
      • Azure RBAC deny assignments override any allowed permissions. If a deny assignment exists at the subscription or resource group level, it will block Microsoft.Compute/virtualMachines/write.
      • Resource locks (Read-only or CanNotDelete) on the target resource group also prevent VM creation.
    2. PIM Activation Scope or Session
      • The user must activate the Contributor role for the correct scope (subscription) and refresh their session after activation. If the token is stale, permissions won’t apply.
    3. Custom Role via PIM
      • If a custom role was assigned instead of the built-in Contributor, verify it includes Microsoft.Compute/* actions.

    As a workaround try below checks and let me know if it is helpfull.

    1. Verify the restore destination scope: From the restore wizard, note the target RG (often named AzureBackupRG_<region>_<n>). Ensure the PIM user has write access there and that no locks exist.

    Reference: https://learn.microsoft.com/en-us/azure/backup/backup-azure-arm-restore-vms

    1. Check for deny assignments (blocks even with Contributor).
    • Portal → Subscriptions → Access control (IAM) → Deny assignments
    • Portal → Target RG → Access control (IAM) → Deny assignments If a deny blocks Compute/Network/Storage writes, remove/adjust the source (e.g., deployment stack).

    Reference: https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments?tabs=azure-portal

    1. Remove resource locks that block writes.
    • Portal → Target RG → Locks → remove Read‑only / CanNotDelete as appropriate.

    Reference: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json

    1. Re‑activate PIM correctly and refresh the session.
    • Activate Contributor at the subscription scope (or the RG scope you’re restoring to).
    • After activation, sign out/in of Portal (or az login again) and retry so the token reflects the active role.

    Reference: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-eligible-activate

    1. Confirm the role definition: If using a custom role, ensure required actions exist (Compute/Network/Storage writes).

    Reference: https://learn.microsoft.com/en-us/azure/backup/backup-rbac-rs-vault

    Note on Backup security controls (MUA/Resource Guard): These protect critical operations (stop protection, delete restore points) and are not typically the cause of VM create failures. If you have enabled MUA and are attempting a guarded operation, follow Resource Guard guidance.

    Reference: https://learn.microsoft.com/en-us/azure/backup/multi-user-authorization?tabs=azure-portal&pivots=vaults-recovery-services-vault

    The VM restore failed because the PIM‑activated user didn’t have effective write permission at the restore destination due to either a deny assignment or a resource lock, or because the PIM activation scope/session wasn’t applied. Fix: Identify the target RG, remove any deny assignments or locks that block writes, re‑activate PIM at subscription scope and refresh the session, and verify that the role (built‑in or custom) includes Microsoft.Compute/virtualMachines/write and related actions.

    So, please share the exact target RG and whether any deny assignments/locks are present?

    Thanks,

    Suchitra.

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2025-11-18T16:32:11.5433333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The issue you're experiencing with the user's subscription level contributor role not being inherited on the Recovery Services vault could be related to how Azure Role-Based Access Control (RBAC) and Privileged Identity Management (PIM) interact. When roles are granted via PIM, they may not always apply the same way as roles that are assigned directly. Here are some probable reasons for the issue:

    1. PIM Role Activation: The user may not have activated their PIM role correctly or may not have the role activated at the time of the recovery operation. PIM roles need to be activated to take effect.
    2. Scope of Role Assignment: The contributor role might not have been assigned at the correct scope. If the role is assigned at the subscription level but not explicitly at the Recovery Services vault level, it may not grant the necessary permissions for operations specific to the vault.
    3. Permission Inheritance: Azure RBAC permissions can sometimes behave unexpectedly due to the way permissions are inherited. If the Recovery Services vault has specific deny assignments or if there are conflicting permissions, it may prevent the user from performing certain actions.
    4. Role Propagation Delay: There can be a delay in role propagation when roles are assigned or activated via PIM, which might temporarily prevent access until the permissions are fully propagated.
    5. Custom Role Requirements: If the operation requires specific permissions that are not included in the standard contributor role, such as Microsoft.Compute/virtualMachines/write, the user may need a custom role that includes these permissions explicitly.

    Given that another user with the same role (not granted via PIM) can perform the recovery, it reinforces the idea that the issue is likely related to how the PIM role is activated or scoped.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.