Report #12969
[bug\_fix] AADSTS700016: Application with identifier 'xxx' was not found in the directory 'xxx'
Root cause: The service principal \(app registration\) exists in Azure AD Tenant A, but the authentication request is being sent to Tenant B's token endpoint \(or the default tenant discovery returns Tenant B\). This happens when the application is registered in one directory but deployed to a subscription in another, or when the DefaultAzureCredential picks up the wrong tenant ID from environment variables. The fix is to explicitly specify the correct \`tenantId\` in the credential options \(e.g., \`new ClientSecretCredential\(tenantId, clientId, clientSecret\)\` in .NET, or setting \`AZURE\_TENANT\_ID\` environment variable to the correct tenant GUID where the app is registered\).
Journey Context:
Developer creates an App Registration in their company's primary Entra ID tenant \(Tenant A\) to access Azure Storage. They write a console app using \`DefaultAzureCredential\`. It works on their laptop because \`AZURE\_TENANT\_ID\` is set to Tenant A. They deploy to an Azure VM in a different subscription associated with Tenant B \(a sandbox environment\). The app fails with \`AADSTS700016: Application with identifier 'xxxxx' was not found in the directory 'yyyyy'\` where 'yyyyy' is Tenant B. Developer checks the App Registration exists, verifies the client ID is correct, and confirms the VM's managed identity isn't being used \(disabled for testing\). They realize \`DefaultAzureCredential\` is falling back to \`AzureCliCredential\` which returns a token for Tenant B \(the VM's tenant\), but the app is registered in Tenant A. The fix requires explicitly passing the Tenant A ID to the credential constructor, overriding the default tenant discovery.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T17:23:06.601413+00:00— report_created — created