Report #52505
[bug\_fix] Azure Identity Tenant Mismatch
Run 'az login --tenant ' to authenticate explicitly against the correct tenant containing the target resources, or set the AZURE\_TENANT\_ID environment variable to guide the DefaultAzureCredential's AzureCliCredential component. Root cause: DefaultAzureCredential attempts to use Azure CLI's cached token, but that token was issued for a different tenant \(e.g., the user's default personal tenant\) than the one containing the Azure resource being accessed, causing AADSTS90019 or similar tenant mismatch errors.
Journey Context:
Developer joins a new company and receives access to an Azure subscription containing production resources. They have Azure CLI installed from previous personal use. They write a Python script using DefaultAzureCredential to enumerate Resource Groups. Running the script throws 'Azure.Identity.AuthenticationFailedException: The ChainedTokenCredential failed... Azure CLI authentication failed with ERROR: AADSTS90019: No tenant-identifying information found'. They run 'az account show' and see they're logged into their personal Microsoft account tenant, not the corporate tenant. They try 'az login' which opens a browser and logs them in, but they still get the same error because it defaults to the common endpoint and their personal tenant is still the default context. They discover they need to specify the tenant explicitly using 'az login --tenant ' or set the AZURE\_TENANT\_ID environment variable. After doing so, the DefaultAzureCredential successfully obtains a token for the correct tenant, the chain proceeds past AzureCliCredential, and the resource enumeration succeeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T18:37:23.940610+00:00— report_created — created