AADSTS700016: Application Not Found in Directory – Tenant Mismatch Despite Clean Setup

Question

I HAVE PURCHASED A AZURE SUPPORT PLAN AND I STILL CANNOT CONTACT SUPPORT FOR THIS ISSUE.. THE ADMIN PORTAL JUST KEEPS RUNNING ME ROUND AND ROUND AND ROUND AND ROUND AND ROUND AND ROUND AND ROUND AND ROUND AND.... YOU GET THE IDEA!

Hello Azure Support,

I am experiencing a persistent authentication issue with Azure Bot Service and Azure AD that I am unable to resolve, despite following all documented best practices and advanced troubleshooting steps.

Summary of the Issue:

• I receive the following error when my bot attempts to authenticate:

AADSTS700016: Application with identifier '<App Registration Client ID>' was not found in the directory '<GUID or "Bot Framework">'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.

• The error references a directory/tenant ID that does not exist in my Azure environment.

What I Have Already Done:

1. Created new Azure subscriptions (not just new resource groups) in the correct tenant (CloudPlanet UK Ltd., Tenant ID: ).
2. Created new App Registrations with unique, never-used-before names in the correct tenant.
3. Created new Azure Bot resources in the correct tenant and subscription, always selecting “Use existing app registration” and linking to the new App Registration.
4. Added the Direct Line channel to the new bot resource, created new sites/secrets, and updated all downstream integrations.
5. Updated all environment variables (.env, PM2, etc.) to use the new App ID, secret, and tenant ID.
6. Deleted all old resources, bots, app registrations, and even subscriptions to ensure no stale or “ghost-linked” resources remain.
7. Restarted all services and processes after every change.
8. Confirmed in the Azure Portal that all resources are in the correct tenant and subscription.

Despite all of this, the error persists and always references a directory/tenant that is not present in my account.

What I Need:

• Please investigate and clear any backend cache, “ghost-link”, or internal reference that may be causing Azure Bot Service or the Direct Line channel to attempt authentication in the wrong tenant/directory.
• Please confirm that my App Registration and Azure Bot resource are correctly linked in the CloudPlanet UK Ltd. tenant (Tenant ID: ).
• If there is a known issue or workaround for this “ghost-link”/tenant mismatch problem, please provide it.

Supporting Details:

• App Registration Client ID:
• Azure Bot Resource Name:
• Tenant ID:
• Subscription ID:
• Full error message (including Trace ID, Correlation ID, and Timestamp):

Screenshots and logs are available upon request.

---

This is a critical production blocker. I have exhausted all documented and community troubleshooting steps. Please escalate to an engineer with access to backend tenant/resource mapping.

Thank you for your urgent attention.Hello Azure Support,

I am experiencing a persistent authentication issue with Azure Bot Service and Azure AD that I am unable to resolve, despite following all documented best practices and advanced troubleshooting steps.

Summary of the Issue:

• I receive the following error when my bot attempts to authenticate:

AADSTS700016: Application with identifier '<App Registration Client ID>' was not found in the directory '<GUID or "Bot Framework">'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.

• The error references a directory/tenant ID that does not exist in my Azure environment.

What I Have Already Done:

1. Created new Azure subscriptions (not just new resource groups) in the correct tenant (CloudPlanet UK Ltd., Tenant ID: )
2. Created new App Registrations with unique, never-used-before names in the correct tenant.
3. Created new Azure Bot resources in the correct tenant and subscription, always selecting “Use existing app registration” and linking to the new App Registration.
4. Added the Direct Line channel to the new bot resource, created new sites/secrets, and updated all downstream integrations.
5. Updated all environment variables (.env, PM2, etc.) to use the new App ID, secret, and tenant ID.
6. Deleted all old resources, bots, app registrations, and even subscriptions to ensure no stale or “ghost-linked” resources remain.
7. Restarted all services and processes after every change.
8. Confirmed in the Azure Portal that all resources are in the correct tenant and subscription.

Despite all of this, the error persists and always references a directory/tenant that is not present in my account.

What I Need:

• Please investigate and clear any backend cache, “ghost-link”, or internal reference that may be causing Azure Bot Service or the Direct Line channel to attempt authentication in the wrong tenant/directory.
• Please confirm that my App Registration and Azure Bot resource are correctly linked in the CloudPlanet UK Ltd. tenant (Tenant ID: fe6c57cf-633d-457e-819d-1d4046667584).
• If there is a known issue or workaround for this “ghost-link”/tenant mismatch problem, please provide it.

Supporting Details:

• App Registration Client ID:
• Azure Bot Resource Name:
• Tenant ID:
• Subscription ID:
• Full error message (including Trace ID, Correlation ID, and Timestamp):

Screenshots and logs are available upon request.

---

This is a critical production blocker. I have exhausted all documented and community troubleshooting steps. Please escalate to an engineer with access to backend tenant/resource mapping.

Thank you for your urgent attention. Note: Tenant redacted on support side.

Answer 1

Hi Todd Harrison

Here is my Observations based on below threads.

1. https://learn.microsoft.com/en-us/answers/questions/5594722/aadsts700016-application-with-identifier
2. https://learn.microsoft.com/en-us/answers/questions/1838989/how-to-fix-aadsts700016

Probable causes

• The AADSTS700016 error occurs when Azure AD cannot find the application ID in the tenant directory.
• The error commonly results from using the wrong identifier (e.g., client secret, object ID, or SAML entity ID instead of the actual Client ID).
• A frequent cause is that the authentication request is being sent to the wrong tenant, leading to a tenant mismatch.
• The app may not be registered in the tenant you're authenticating against, especially with multi‑tenant or cross‑tenant setups.
• When integrating with Outlook Calendar or similar services, developers sometimes mistakenly use a Client Secret instead of a Client ID, causing Azure AD to fail validation.
• In SAML/OIDC setups, misconfigured Issuer URI, App ID URI, or Reply URLs can cause the app to appear nonexistent in the directory.
• Azure Bot Service can sometimes retain stale tenant references, producing a “ghost‑link” tenant mismatch error.
• Multi‑tenant apps require explicit admin consent from other tenants before they can authenticate.
• Confusion between AppId, ObjectId, and Service Principal ID frequently leads to incorrect configuration.

Recommendation

• Ensure the value passed to client_id is the Application (client) ID GUID — not the client secret, object ID, or entity ID.
• Verify the authority URL points to the correct tenant: https://login.microsoftonline.com/{correct-tenant-id}/
• Confirm that the application is properly registered under App Registrations in the tenant you're using.
• If the app is multi‑tenant, ensure the external tenant admin has granted consent using: https://login.microsoftonline.com/common/adminconsent?client_id={client-id}
• In SAML apps: make sure the Entity ID, Issuer, and Reply URL match exactly between Azure AD and the identity provider.
• If you recently recreated an app, ensure no old app IDs remain in the code, config files, or service setups.
• For Azure Bot Service: if a stale tenant reference persists, you may need Microsoft Support to clear backend mappings.
• Double‑check the difference between:
  • AppId (client ID) → used for authentication
    • Object ID → identifies the app object
      • Service Principal ID → identifies the enterprise app instance
• Remove and re‑add the application if the directory has conflicting or duplicate entries.

Hope it helps address the issue. Please create a new thread in Identity/Entra side if the issue persists.

Thank you.