Intermittent servicePrincipal creation failure with OwnedBy: backing application must be in local tenant despite being created there

Start by reviewing the Graph Bicep servicePrincipal resource handling and the linked CI runs, then inspect the supplied Graph request IDs with the Microsoft Graph team. The issue provides a reduced Bicep reproduction, though it has not been independently tested. Done means identifying why a local backing application is rejected and clarifying or correcting the behavior.

Summary

Microsoft Graph Bicep intermittently fails to create a service principal immediately after creating its backing application registration in the same tenant. The deploying service principal has the Microsoft Graph application permission Application.ReadWrite.OwnedBy, with admin consent.

The exact error is:

Authorization_RequestDenied: When using this permission, the backing application of the service principal being created must in the local tenant

Directory audit events confirm the application was created in the deployment tenant and the deploying service principal was added as its owner. A later deployment against the same application can succeed without any permission changes. We suspect a consistency or authorization issue, but have not confirmed the server-side cause.

Environment

• GitHub Actions Linux deployment runner, using workload identity federation to authenticate a service principal to Azure CLI.
• Graph Bicep extension: br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:1.0.0.
• Graph resource API version: v1.0.
• Deployer Graph application permission: Application.ReadWrite.OwnedBy; no Application.ReadWrite.All or Directory.ReadWrite.All.
• The permission assignment was granted on October 15, 2026 and remained unchanged across passing and failing runs.
• This occurs in Aspire's Azure deployment E2E test. It also failed on an older repository commit, not just the latest integration code.
• Bicep CLI version for the cited failing runs: not captured in this investigation.

Reproduction steps

1. Use a service principal with admin-consented Application.ReadWrite.OwnedBy, appropriate Azure deployment permissions, and an Azure subscription in the tenant where the application will be created.
2. Authenticate Azure CLI as that service principal (our runs use workload identity federation), selecting that subscription.
3. Deploy a Graph Bicep module that creates a new, uniquely named single-tenant application and immediately creates its service principal using application.appId.
4. Repeat with fresh application names to exercise the initial-create path. The failure is intermittent; some fresh deployments succeed on the first attempt.
5. When the failure occurs, inspect directory audit events: application creation and deployer ownership assignment succeed, but service-principal creation is denied.
6. Redeploy using the same application uniqueName, rather than creating another registration. In an observed run, a later attempt succeeded with no permission changes.

Reduced Graph Bicep resource shape

The following is reduced from the generated Bicep used by Aspire; it has not been independently tested as a standalone reproduction. The linked CI runs are the actual reproduction evidence.

extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:1.0.0' as microsoftGraphV1

param registrationName string

resource application 'Microsoft.Graph/[email protected]' = {
  displayName: registrationName
  uniqueName: registrationName
  signInAudience: 'AzureADMyOrg'
  api: {
    requestedAccessTokenVersion: 2
  }
  web: {
    redirectUris: [
      'https://example.invalid/signin-oidc'
    ]
    implicitGrantSettings: {
      enableIdTokenIssuance: false
    }
  }
}

resource servicePrincipal 'Microsoft.Graph/[email protected]' = {
  appId: application.appId
}

output clientId string = application.appId
output objectId string = application.id
output servicePrincipalId string = servicePrincipal.id
output tenantId string = tenant().tenantId

For example, deploy at resource-group scope with az deployment group create --resource-group <group> --template-file main.bicep --parameters registrationName=<fresh-unique-name>, then reuse the same parameter value when retrying. No explicit owner relationship is supplied in the template; the ownership noted above is observed in the tenant audit log.

Actual result and diagnostic IDs

The deployment fails at /resources/servicePrincipal:

{
  "error": {
    "code": "Forbidden",
    "target": "/resources/servicePrincipal",
    "message": "Authorization_RequestDenied: When using this permission, the backing application of the service principal being created must in the local tenant Graph request-id: 72c49ccb-93ad-431d-9459-d23a70a30c67 (2026-10-20T19:52:42) Graph client request id: c072578a-5b46-4b01-9044-2f323fd53db0. Graph request timestamp: 2026-10-20T19:52:42Z."
  }
}

For that request, the tenant audit log records application creation at 2026-10-20T19:52:42.131Z and assignment of the deploying service principal as owner at 2026-10-20T19:52:42.278Z. The application was subsequently readable in that same tenant. This is not an intentional cross-tenant application scenario.

• Failing main run.
• Another failure before the workaround.
• Run demonstrating successful retry: first deployment attempt hit this exact error; the next attempt succeeded. Initial deployment and redeployment checks then succeeded, although the overall run failed for a separate directory cleanup problem.
• Subsequent passing run: both deployments succeeded on their first attempt, demonstrating that a retry is not always required.

We did not find a relevant tenant permission or policy change in the audited period. That does not rule out a service-side change or an unaudited cause.

Expected result

Creation of a service principal for a newly created local application should work with the documented least-privileged Application.ReadWrite.OwnedBy permission. If there is a documented consistency requirement, please clarify how clients should detect and handle this specific failure.

Current workaround

In microsoft/aspire#21226, the existing deployment test retries the whole aspire deploy --clear-cache --non-interactive command at most three attempts, waiting 30 seconds between attempts, only when output contains the observed backing-application/local-tenant error. It reuses the same application uniqueName, allowing the next deployment to operate on the already-created registration. Other errors fail immediately, and the final failed attempt preserves a nonzero exit code.

We have not broadened tenant permissions. This is a test-level workaround, not a confirmed root-cause fix. The successful retry occurs after the failed deployment has finished unwinding and the additional 30-second wait; we have not established that 30 seconds alone is sufficient for replication.

Potentially related

microsoftgraph/msgraph-bicep-types#275 also involves service-principal authorization under Application.ReadWrite.OwnedBy, but reports “Insufficient privileges to complete the operation.” Our message specifically rejects the backing application's tenant locality. We are filing separately because we cannot establish that these have the same cause.

Could the team inspect the request IDs above and determine why the local backing application was rejected?