App Service Key Vault reference stuck at AccessToKeyVaultDenied despite correct, verified RBAC role assignment (tried two separate identities)

Muhammad Wasim Rashid 0 Reputation points
2026-11-08T21:58:54.94+00:00

I have a Linux App Service (Node 24, West Europe region "Denmark East") with two app settings configured as Key Vault references:

Email__AcsConnectionString -> @Microsoft.KeyVault(SecretUri=https://kv-xxxxx.vault.azure.net/secrets/xxxxx/)
Unsubscribe__Secret -> @Microsoft.KeyVault(SecretUri=https://kv-xxxxx.vault.azure.net/secrets/xxxxx/)

Both are stuck in status AccessToKeyVaultDenied ("Key Vault reference was not able to be resolved because site was denied access to Key Vault reference's vault"), checked via:

GET /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{site}/config/configreferences/appsettings?api-version=2023-12-01

What I've verified (twice, with two completely different identities):

  • Original system-assigned identity had Key Vault Secrets User correctly assigned, scoped directly at the vault. Still denied after 24+ hours and two app restarts.
  • I then removed the managed identity entirely and re-added it (forcing a brand-new principal ID), granted the new identity Key Vault Secrets User at the vault scope, and restarted again. Still denied, immediately.
  • Key Vault config: enableRbacAuthorization: true, publicNetworkAccess: Enabled, networkAcls unset (no restrictions), no deny assignments on the vault.
  • The App Service has no VNet integration (virtualNetworkSubnetId: null, vnetRouteAllEnabled: false) - no possible network routing issue.
  • keyVaultReferenceIdentity is unset (defaults to SystemAssigned), matching the identity holding the role - no ambiguity from multiple identities.
  • No Azure Policy deny effects found affecting this resource group.

Since the failure persists identically across two unrelated identities, each freshly granted the correct role, this doesn't look like a propagation delay or a misconfigured role assignment - it looks like something stuck on the platform side for this specific Key Vault/App Service pairing.

Has anyone seen this exact failure mode (correct RBAC, still denied, persists across identity recreation)? What finally resolved it for you?

Azure Key Vault
Azure Key Vault

An Azure service that is used to manage and protect cryptographic keys and other secrets used by cloud apps and services.

0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest

  1. AI answer

    2026-11-09T11:55:12.6733333+00:00

    Force the dedicated Key Vault-reference refresh, then correlate that request in the vault audit log; if no request appears—or it uses the current identity and is still denied despite its verified role—treat this as an App Service resolver/platform incident rather than recreating the identity again.

    1. Force the reference resolver to run

    A restart normally triggers a refetch, but App Service also provides a specific management operation for refreshing all Key Vault references. This is distinct from restarting the worker. App Service otherwise caches references and periodically refetches them.^1^

    Run:

    APP_ID=$(az webapp show \
  --resource-group <resource-group> \
  --name <app-name> \
  --query id -o tsv)

az rest --method post \
  --uri "https://management.azure.com${APP_ID}/config/configreferences/appsettings/refresh?api-version=2022-03-01"

    Immediately query the status again:

    az rest --method get \
  --uri "https://management.azure.com${APP_ID}/config/configreferences/appsettings?api-version=2023-12-01"

    Expected result: both references change to a resolved/healthy state. If they remain AccessToKeyVaultDenied, continue directly to the audit correlation rather than waiting another 24 hours.

    2. Identify what the resolver actually presented to Key Vault

    Enable the Key Vault AuditEvent diagnostic log if it is not already enabled, repeat the refresh, and inspect the resulting SecretGet events. Key Vault audit records expose the operation, HTTP result, caller IP, correlation ID, and identity claims—including the object identifier presented in the token.^2^

    Compare that object ID with the App Service’s current system-assigned principal ID:

    az webapp identity show \
  --resource-group <resource-group> \
  --name <app-name> \
  --query principalId -o tsv

    Interpret the result:

    • SecretGet succeeds: The vault accepted the request, but App Service continues reporting a denial. Capture the successful event and stale configuration-reference status for support.
    • SecretGet returns 403 with a different object ID: The resolver is using a different identity than expected. A 403 means the request was authenticated, but the presented identity or source address was not authorized.^3^
    • SecretGet returns 403 with the current system-assigned principal ID: Since that exact principal already has Key Vault Secrets User at vault scope and networking is unrestricted, preserve the audit event and role-assignment evidence for escalation.
    • No matching SecretGet appears after the refresh: This strongly localizes the failure to App Service’s reference-resolution path before it reaches the vault.

    Avoid assigning the role to the Microsoft Azure App Service enterprise application: that identity applies to platform certificate operations, whereas per-app secret access uses the Web App’s managed identity.^4^

    3. Run the App Service detector and escalate

    In the Azure portal, open:

    App Service → Diagnose and solve problems → Availability and Performance → Web app down → search for “Key Vault Application Settings Diagnostics”

    This is the documented detector for unresolved App Service Key Vault references.^1^

    If it does not identify a customer-configurable fault, open an Azure support request under App Service → Managed Identity Integration and include:

    • App Service and Key Vault resource IDs.
    • UTC timestamp of the forced refresh.
    • Refresh request/correlation ID, if returned.
    • Current system-assigned principal ID.
    • Role-assignment ID and scope.
    • Configuration-reference status response.
    • Matching Key Vault SecretGet audit event, or confirmation that none was generated.
    • App Service region and affected deployment slot.

    A backend resolver inconsistency has caused comparable Key Vault-reference failures in a specific region and required targeted platform recovery, so escalation is appropriate once the audit correlation rules out the actual caller, RBAC, and network path.^5^ That report concerned Azure Functions in another region, so it establishes the possible failure class—not that the same incident affects this App Service.

    Switching to a user-assigned identity is unlikely to fix this case by itself because two fresh system-assigned identities have already failed. It remains useful for lifecycle stability, but should be considered after the resolver incident is diagnosed, not as another immediate RBAC experiment.

    References

    1. Use Key Vault References as App Settings - Azure App Service
    2. Azure Key Vault logging
    3. Azure Key Vault REST API Error Codes
    4. Transition Azure Key Vaults to Azure RBAC - Microsoft Q&A
    5. Function app with system assigned identity has developed issue where Keyvault references in Environment Variables no longer resolve - Microsoft Q&A
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Allan Solomon Mejia 10,720 Reputation points
    2026-11-08T23:18:20.28+00:00

    Hello @Muhammad Wasim Rashid

    Your RBAC configuration appears correct: with enableRbacAuthorization: true, the App Service managed identity needs the Key Vault Secrets User role at the vault or secret scope. Key Vault references use the system-assigned identity by default, so an unset keyVaultReferenceIdentity is expected in this configuration.

    At this point, recreating the identity again is unlikely to provide useful evidence. Next, determine which identity Key Vault actually receives.

    Enable the Key Vault AuditEvent diagnostic log, force another reference refresh, and inspect the resulting SecretGet request. Key Vault logs include the caller identity, object identifier, application ID, caller IP address, HTTP status, and result description.

    Force the refresh with:

    POST https://management.azure.com/{app-resource-id}/config/configreferences/appsettings/refresh?api-version=2022-03-01

    App Service caches Key Vault references for up to 24 hours; this endpoint is the supported way to trigger an immediate refetch.

    Compare the oid or object-identifier claim in the Key Vault log with the current App Service principalId:

    • If they differ, the platform resolver is using a different or stale identity.
    • If they match and Key Vault returns HTTP 403, the log’s result description should distinguish an RBAC denial from a firewall/network denial. HTTP 403 means the caller was authenticated, but authorization or network policy rejected the request.
    • If no SecretGet event appears after the forced refresh, the request isn’t reaching the vault, which points away from the Key Vault RBAC assignment.
    • If the correct identity reaches Key Vault successfully but App Service still reports AccessToKeyVaultDenied, the remaining evidence points to the App Service reference resolver or cached resolution state. This is an inference, not a documented root cause.

    Also run the built-in Key Vault Application Settings Diagnostics detector under App Service → Diagnose and solve problems → Availability and Performance → Web app down. Microsoft specifically recommends this detector for unresolved Key Vault references.

    If the logs confirm the correct principalId, an allowed network path, and repeated failures after a forced refresh, open an Azure support request for the Microsoft.Web resource provider. Include:

    • App Service and Key Vault resource IDs
    • UTC timestamps of the refresh attempt
    • Current App Service principalId and tenant ID
    • Key Vault SecretGet audit record and correlation ID
    • Output of the config-reference status API
    • Region, OS, and App Service plan
    • Results from the App Service diagnostic detector

    The Key Vault audit record is the decisive evidence needed before classifying it as a platform-side resolver issue.

    References:

    Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

    Was this answer helpful?

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.