Issue with servicePrincipals and appRoleAssignedTo in some Entra Tenants

[stas-sultanov]

Bicep version

0.39.26

Resource and API version

• Microsoft.Graph/applications@beta → works in Entra tenant A & B
• Microsoft.Graph/servicePrincipals@beta → works in Entra tenant A fails in Entra tenant B
• Microsoft.Graph/appRoleAssignedTo@beta → works in Entra tenant A fails in Entra tenant B

Auth flow

Automated deployment
Bicep executed on Azure DevOps Agent using a service principal (workload identity federation)..

The same configured service principal (same permissions and roles) is used in both Entra tenants.

Deployment details

Insufficient privileges to complete the operation.
Graph client request id: cbf743cc-bffd-443c-a2dd-b1da094d75ac.
Graph request timestamp: 2025-12-30T14:06:55Z.

Describe the bug

Using the same Bicep template, same service principal, and same permissions:

• Deployment works in Tenant A
• Deployment fails in Tenant B

Failures occur only for:

• Microsoft.Graph/servicePrincipals
• Microsoft.Graph/appRoleAssignedTo

The same operations executed via direct Microsoft Graph REST API
(using PowerShell / az rest) succeed.

Expected behavior:
ARM/Bicep Graph deployments should behave consistently across tenants and align with direct Microsoft Graph API behavior.

Actual behavior:
Tenant-dependent failures occur only when using the ARM-based Microsoft Graph provider.

To Reproduce

No idea.

Additional context

• Admin consent to SP used by Azure DevOps is granted in both Entra tenants
• Same permissions, roles, API version, and payload
• Same service principal identity
• Tenant settings reviewed and appear identical
• The issue occurs only when operations are executed via Azure Resource Manager
• Direct Microsoft Graph API calls do not exhibit this tenant-dependent behavior

This suggests additional tenant-level enforcement applied only to
ARM-mediated Microsoft Graph operations.

[dkershaw10]

Stas Sultanov (@stas-sultanov) could you share your Bicep template (or relevant parts) please?

[stas-sultanov]

Dan Kershaw [MSFT] (@dkershaw10) , sure

extension microsoftGraph

@description('Name of the User Assigned Managed Identity to create')
param managedIdentityName string = 'test'

// Create a User Assigned Managed Identity
resource ManagedIdentity_userAssignedIdentities_ 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
  name: managedIdentityName
  location: resourceGroup().location
}

// Reference existing Microsoft Graph service principal
resource Graph_servicePrincipals_ 'Microsoft.Graph/servicePrincipals@beta' existing = {
  appId: '00000003-0000-0000-c000-000000000000'
}

// Assign Graph Application.Read.All to the Service Principal which is used by Managed Identity
resource Graph_appRoleAssignedTo_ 'Microsoft.Graph/appRoleAssignedTo@beta' = {
  appRoleId: '9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30'
  principalId: ManagedIdentity_userAssignedIdentities_.properties.principalId
  resourceId: Graph_servicePrincipals_.id
}

[xqrzd]

I think I'm experiencing this same inconsistency. I have 3 Azure DevOps service accounts using workspace identity federated credentials (dev/stage/prod) that deploy App Registrations using Bicep. Recently we removed the last two API permissions in this list:

• Application.Read.All
• Application.ReadWrite.OwnedBy
• AppRoleAssignment.ReadWrite.All
• Directory.ReadWrite.All
• Application.ReadWrite.All

Every App Registration we've deployed to dev/stage has worked, and everything to prod worked except one that fails with:

{
    "error": {
        "code": "Forbidden",
        "target": "/resources/servicePrincipal",
        "message": "Insufficient privileges to complete the operation. Graph client request id: b0f4cb21-b35c-45c4-9bfd-b8db16f2f4b2. Graph request timestamp: 2026-01-29T20:44:06Z."
    }
}

(Code: DeploymentOperationFailed)

The Bicep to dev/stage/prod is identical (apart from the App Registration name), and all 3 DevOps App Registrations have the same API permissions. I've verified that the prod DevOps App Registration is an owner of the App Registration it's trying to update. I guess in the short term we'll have to add back the extra permissions so we can deploy, but this seems like a bug in Azure.

Note: In my case this is all the same Azure tenant, but 3 separate subscriptions.

Edit: Adding back Application.ReadWrite.All fixed the issue, but it makes no sense as other identical App Registrations deploy fine without it.

[eketo-msft]

Hey Stas Sultanov (@stas-sultanov), xqrzd,

Sorry, I missed this and unfortunately the logs have been purged from Jan. xqrzd can you repro the single tenant issue (diff subs) and I'll see where the authz failure is happening. Also, can you confirm that the SP doing the deployments is an owner on the app registration which is failing?

Stas Sultanov (@stas-sultanov), I could use a new repro as well for the cross tenant issue when you have some time. Feel free to @mention me to ensure it pops up on my feed, and I'll jump on it right away.

[xqrzd]

Sorry for the late reply, I'll work with IT to get the permission removed and test again. The SP doing the deploy is the owner of the app registration, and it has Application.ReadWrite.OwnedBy permission.