Application With Identifier Was Not Found In The Directory | Fast Fix Steps

What This Directory Error Message Actually Means

When a sign in or API call hits Microsoft Entra ID, the platform tries to match the identifier in the request to a registered application. That identifier can be a client id, an application id URI, or another resource id, depending on the flow you use.

If no application object or service principal in the current tenant matches that identifier, the platform throws the message that your application with identifier was not found in the directory. In plain terms, the directory does not know which app you are talking to, so the request stops.

This often surprises teams who recently changed tenants, moved app registrations, or copied settings from another project. The text looks scary, yet it almost always means configuration drift instead of a deep platform outage.

For developers, that missing link shows up as confusing sign in failures, broken local tests, or tools that worked yesterday and now stop at the login screen. For admins, it often appears right after changes to tenants, domains, or app ownership.

Why “Application With Identifier Was Not Found In The Directory” Appears

This error has a small set of common roots. Understanding these patterns makes it much easier to fix the current issue and prevent the same trap in later releases.

• Wrong Tenant — The sign in or token request goes to one tenant, while the app registration lives in another tenant, so the directory cannot link the two.
• Typo In The Identifier — A single mistaken character in a client id, app id URI, or resource id is enough for the lookup to fail.
• Deleted Or Moved App Registration — Someone removed the app, recreated it, or moved to a new tenant, while clients still send requests with old identifiers.
• Missing Service Principal — The app is multi tenant, yet the service principal for the consumer tenant never got created, so the local directory has no record.
• Mixed Clouds Or Endpoints — The code calls a public cloud endpoint while the app lives in a national cloud, or the opposite, so the identifier search happens in the wrong place.
• Using A Personal Account — The user signs in with a Microsoft account where the tenant does not host the app, so the platform checks the wrong directory.

Each of these roots still comes back to the same idea: the platform must read your identifier, look inside the correct tenant, and find exactly one matching record. If any of those pieces are off, the message appears.

Quick Reference Table Of Causes And Fixes

Symptom	Likely Cause	First Fix To Try
Only some users see the error	Users sign in to a different tenant	Confirm tenant id in the authority URL
Error after app rename or migration	Old identifier still in code or config	Copy new client id and redirect URIs
Multi tenant app fails in one customer tenant	Service principal missing or removed	Have the customer admin grant consent again
App works in public cloud but fails in national cloud	Authority points to wrong cloud endpoint	Switch to the correct login endpoint

Quick Checks To Fix The Error Fast

Before you adjust code or run scripts, run through a short set of simple checks. Many teams clear the message within minutes once these basics line up.

• Confirm The Tenant — Open the Microsoft Entra admin center, note the tenant id, and compare it with the tenant value or authority URL in your app settings.
• Copy The Identifier Fresh — From the app registration page, copy the application client id or app id URI again and paste it into your configuration instead of retyping by hand.
• Check The Sign In URL — Make sure your authority or instance value, such as login.microsoftonline.com or a national cloud variant, matches the cloud where the app lives.
• Verify The Account Type — If the app accepts only work or school accounts, signing in with a personal Microsoft account can route the request to another directory that does not host your app.
• Confirm The App Still Exists — In the tenant where you expect the app to live, confirm that the app registration has not been deleted or renamed in a way that broke linked resources.

Once you finish those checks, repeat the sign in or API call. If the message disappears, the fix likely came from aligning the tenant and identifier values more tightly.

Deep Fixes Inside Microsoft Entra Admin Center

When quick checks do not solve the problem, you can move to deeper fixes in the admin center. These steps assume you have at least application administrator rights in the tenant.

Recreate Or Restore The Application

If someone deleted the app registration, and no backup exists, you may need to create a new app and then update every client that relies on the old identifier. This takes planning, yet it returns control.

• Create A New App Registration — In the Entra admin center, register a new app, select the right account type, and record the new client id and app id URI.
• Rebuild Redirect URIs — Add every reply URL your site or native client uses so sign in flows map cleanly to the new app.
• Grant Required Permissions — Reapply API permissions that the previous app had, and ask an administrator to grant tenant wide consent again if required.
• Rotate Secrets And Certificates — For confidential clients, create new client secrets or upload certificates, then map them into your client configuration.

Plan the cutover window so you can swap identifiers at a quiet time. Keep both old and new configurations documented so you can trace any odd behavior that appears later.

Fix Service Principal Gaps For Multi Tenant Apps

Multi tenant apps rely on a service principal in each consumer tenant. If that local object is missing or broken, users in that tenant can trigger the message even while the home tenant app registration looks healthy.

• Have The Customer Admin Grant Access — Ask the tenant administrator to sign in to the app consent link so a new service principal is created in that directory.
• Check Enterprise Applications — In the customer tenant, look under Enterprise applications for your app name to confirm that a service principal now exists.
• Review Assignment Settings — If the app requires user assignment, make sure target users or groups are assigned so they can sign in.

Once a healthy service principal exists in the tenant, the platform can match the identifier to a local object and stop raising the directory error for those users.

Correct Cross Cloud Endpoint Settings

Organizations that span public and national clouds can slip into mixed endpoint setups. The identifiers might be correct inside each cloud, yet a single wrong authority value sends a sign in to the wrong region.

• Check The Authority Pattern — Confirm that your authority matches the cloud, such as login.microsoftonline.com for public or login.microsoftonline.de for the German cloud.
• Align The App Registration Location — Make sure the directory where the app lives matches the cloud endpoint you selected in your client configuration.
• Retest From Each Region — After you correct endpoints, run sign in tests from users in each region that previously saw the error to confirm a clean path.

Command Line And Code Fixes For Developers

Developers often see this directory message while running local tests, command line tools, or automated pipelines. In many cases the app reference in those tools still points at an older or wrong app id.

Check Azure CLI And PowerShell Context

Command line tools can hold on to old tenant settings. That can send requests to a directory that does not contain your app.

• List The Current Account — Run a command such as az account show or Get AzContext to see which tenant and subscription your session uses.
• Switch To The Correct Tenant — Use az account set or Connect AzAccount with a tenant id parameter to move the session to the right directory.
• Retry The App Command — After you switch context, run the failing command again to see whether the directory error still appears.

Align App Settings In Code Repositories

Configuration files often keep the first working client id for years. When teams recreate an app or move to a new tenant, those files still reference the old identifier by default.

• Search For The Old Identifier — Scan appsettings files, configuration variables, and pipeline variables for the old client id or app id URI.
• Replace With The New Client Id — Paste the new value from the Entra admin center into each place where the old id appears.
• Check Redirect URIs And Scopes — Confirm that redirect URLs and scopes in code match the new app registration so the platform can link each request to the right object.

Commit those changes and rerun your tests. When every reference points at the same app registration, the directory can make a clean match.

Preventing Future Directory Identifier Problems

Once you fix the current error, put a few habits in place so the message application with identifier was not found in the directory does not return every time the team tweaks settings.

• Track App Registrations Clearly — Keep a simple catalog of apps, tenants, client ids, and app id URIs so new developers do not guess which values to use.
• Use Shared Configuration Templates — Store authority URLs, tenant ids, and identifier formats in shared templates instead of hand written strings in many places.
• Limit Manual Typing — Copy and paste identifiers directly from the admin center so you avoid tiny mistakes that break directory lookup.
• Review Changes Before Tenant Moves — When you migrate tenants or restructure identity, plan how app registrations, service principals, and client settings will move so nothing points at a dead app.
• Test Multi Tenant Paths Regularly — For apps with many customer tenants, run regular sign in tests from sample accounts in each tenant to catch missing service principals early.

A run book helps here. Write down which tenant each app uses, where the app registration lives, and how client ids and app id URIs should look in configuration files. Share that document with every new team member who touches identity settings.

With these habits in place, the error message turns from a frequent fire drill into a rare edge case that you can diagnose and fix calmly when it appears.