ManagedIdentityCredential authentication failed

Not specified by the original author.

TL;DR: Symptom: ManagedIdentityCredential authentication unavailable on an Azure host Cause: Code expects a managed identity but IMDS is unreachable: either no identity is assigned to the host, the VNet/proxy blocks the instance metadata endpoint, or several user-assigned identities exist and VERIFY VERIFY: metadata endpoint query works AND the SDK call returns data; debug log shows the managed-identity step succeeding.

The fix

SYMPTOM ManagedIdentityCredential authentication unavailable on an Azure host

CAUSE Code expects a managed identity but IMDS is unreachable: either no identity is assigned to the host, the VNet/proxy blocks the instance metadata endpoint, or several user-assigned identities exist and the code did not pick one.

CONFIRM IT CONFIRM: query the instance metadata endpoint from the host with the Metadata header - JSON response means IMDS works and the problem is assignment/selection. az vm identity show / app identity blade shows whether any identity is assigned.

FIX FIX: assign a system-assigned identity (or attach the user-assigned one); if multiple user-assigned, set AZURECLIENTID or pass managedidentityclient_id so the code picks the right one; open the firewall/proxy for the metadata endpoint. Locally, use DefaultAzureCredential so the chain falls through to az login instead of ManagedIdentityCredential directly.

VERIFY VERIFY: metadata endpoint query works AND the SDK call returns data; debug log shows the managed-identity step succeeding.

When to use this

• This covers exactly what the title says: Diagnose.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Diagnose; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Diagnose behavior.

Diagnostic skill indexed by the exact error string. Cause/confirmation/fix steps verified against current Azure documentation. Evidence: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

Not specified by the original author.

TL;DR: The app expects a managed identity but the IMDS endpoint is unreachable. Either the code is not running on Azure, or the VNet/proxy blocks the cloud provider's instance metadata endpoint. With several user-assigned identities, the code must pick: DefaultAzureCredential(managedidentityclientid="[client-id]") or the AZURECLIENT_ID env var. Verify: from the host, query the instance metadata endpoint with the Metadata header set, hitting the metadata endpoint's instance API.

The fix

Error text: ManagedIdentityCredential authentication unavailable. No managed identity endpoint found.

Causes:

1. Not on Azure. Running locally, the managed-identity step cannot work. Locally you want the chain to fall through to Azure CLI / env vars. If it does not fall through, something is forcing managed identity only (e.g. ManagedIdentityCredential used directly instead of DefaultAzureCredential).
2. IMDS blocked. The endpoint is the cloud provider's instance metadata endpoint (link-local, HTTP). Firewalls, proxies, or forced tunneling that block link-local break it. The fix is a network rule allowing the metadata endpoint, not code.
3. Identity not assigned. The VM/App Service has no managed identity assigned at all. az vm identity show / app identity blade. Assign system-assigned or attach user-assigned.
4. Wrong identity selected. With several user-assigned identities, the code must pick: DefaultAzureCredential(managed_identity_client_id="[client-id]") or the AZURECLIENTID env var. Without it, the platform default may be an identity with no roles.
5. Slow first token. The first IMDS call can take seconds; aggressive client timeouts fail before the token arrives. Do not set sub-second timeouts on identity calls.

Verify: from the host, query the instance metadata endpoint with the Metadata header set, hitting the metadata endpoint's instance API. If that returns JSON, IMDS is fine and the problem is identity assignment or client config.

When to use this

• This covers exactly what the title says: Azure ManagedIdentityCredential authentication unavailable.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Azure; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Azure behavior.

Proactive error-catalog skill. IMDS behavior verified against current managed identity docs. Evidence: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

Not specified by the original author.

Context: "Identity not found" is the Azure instance metadata service (IMDS) answering 400 when ManagedIdentityCredential, often inside DefaultAzureCredential, asks for a token for an identity the Azure fabric has not assigned to that resource. The fuller message usually reads "the requested identity isn't assigned to this resource". The fix is to assign the identity to the resource (or pass the correct TL;DR: "Identity not found" is the Azure instance metadata service answering 400 because the managed identity your code asked for is not assigned to this resource. Assign the identity (or fix the client id), wait a few minutes for propagation, then retry. This is almost never an RBAC or permissions problem.

1. Read the full error and note which identity was requested. If you constructed the credential with a client id, that is the one being looked up. If not, it is the resource's default identity.
2. Verify the identity is assigned to this resource. For a VM, run:

az vm identity show --resource-group YOUR_RG --name YOUR_VM

For App Service or Functions, check the Identity blade in the portal, or run:

az webapp identity show --resource-group [your resource group] --name [your app]

For Container Apps:

az containerapp identity show --resource-group [your resource group] --name [your app]

If the listing is empty, or your client id is missing from it, that is the cause. On AKS with workload identity, check the service account annotation instead:

kubectl describe sa [your service account] -n [your namespace]

The annotation value must match the client id your code requests character for character.

3. Fix the assignment: enable the system-assigned identity on the resource, or attach your user-assigned identity to it, then confirm the client id you use matches it exactly.
4. Wait a few minutes after assigning. Identity assignment takes time to propagate. Then retry the token call. Expected: a token is returned instead of the 400.

Reading the real IMDS error behind "azure identity not found"

The token call that fails is your code asking the Azure instance metadata service for a token. When the identity is not assigned, the service answers 400 with a body shaped like {"error":"invalid_request","error_description":"Identity not found"}. Two nearby errors mean different things and need different fixes:

• error_description "Identity not found" - the identity exists in Entra (or does not) but is not attached to this host. Fix the assignment, per the steps above.
• No response from the metadata endpoint at all (connection refused or timeout) - you are on a local dev machine or a non-Azure host, where there is no metadata service. Fix: az login and let AzureCliCredential handle it; do not chase identity assignment.
• 400 with a different error_description mentioning the client id format - the requested client id is malformed or mistyped. Compare it character for character against the assigned identity.

Variant phrasings: the requested identity isn't assigned to this resource; ManagedIdentityCredential authentication unavailable; error_description Identity not found; DefaultAzureCredential failed to retrieve a token from the included credentials.

Root cause: the managed identity credential asks IMDS for a token for a specific identity. IMDS answers 400 invalid_request when that identity has not been assigned to the host making the request. The identity may exist in Entra but is not attached to this VM, app service, container app, or AKS pod, or the requested client id is simply wrong.

Edge cases: on a local dev machine the same credential chain fails with "no response from the IMDS endpoint" because there is no metadata service locally, which is a different cause with a different fix (az login). On AKS with workload identity, a wrong client id in the service account annotation produces this same error. A placeholder or mistyped client id is a common cause, so compare it character by character. Recently assigned identities need propagation time before they work.

When not to use: if you are running locally, do not chase identity assignment. Use az login and AzureCliCredential instead. Do not disable managed identity in DefaultAzureCredential to silence this on an Azure host; fix the assignment.

Related skills

• Diagnose: DefaultAzureCredential failed to retrieve a token from the included credentials - the wider credential-chain failure this error often hides inside.
• azure.identity.CredentialUnavailableError: DefaultAzureCredential failed to retrieve a token - when the chain fails before IMDS is even reached.

"Identity not found" is the Azure instance metadata service (IMDS) answering 400 when ManagedIdentityCredential, often inside DefaultAzureCredential, asks for a token for an identity the Azure fabric has not assigned to that resource. The fuller message usually reads "the requested identity isn't assigned to this resource". The fix is to assign the identity to the resource (or pass the correct client id), then retry.

"error": "invalid_request", "error_description": "Identity not found"

Verified resolution: 1. Read the full error and note which identity was requested. If you constructed the credential with a client id, that is the one being looked up. If not, it is the resource's default identity.

2. Verify the identity is assigned to this resource. For a VM, run:

az vm identity show --resource-group YOUR_RG --name YOUR_VM

For App Service or Functions, check the Identity blade in the portal. If the listing is empty, or your client id is missing from it, that is the cause.

3. Fix the assignment: enable the system-assigned identity on the resource, or attach your user-assigned identity to it, then confirm the client id you use matches it exactly.
4. Wait a few minutes after assigning. Identity assignment takes time to propagate. Then retry the token call. Expected: a token is returned instead of the 400.

Variant phrasings: the requested identity isn't assigned to this resource; ManagedIdentityCredential authentication unavailable; error_description Identity not found; DefaultAzureCredential failed to retrieve a token from the included credentials.

Root cause: the managed identity credential asks IMDS for a token for a specific identity. IMDS answers 400 invalid_request when that identity has not been assigned to the host making the request. The identity may exist in Entra but is not attached to this VM, app service, container app, or AKS pod, or the requested client id is simply wrong.

Edge cases: on a local dev machine the same credential chain fails with "no resp

Source: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/identity/azure-identity/TROUBLESHOOTING.md