Understanding the AADSTS90002 Tenant Not Found Error

If you see the AADSTS90002 error, it’s basically Microsoft’s way of saying, “Hey, I can’t find your tenant!” This pops up mostly in Microsoft 365, Azure Active Directory, or Entra ID environments when you try to log in or connect a service, but your tenant can’t be found. In plain English: the system doesn’t see any tenant that matches the details you gave it.

So, what’s a “tenant” in all this? Think of a tenant as your organization’s little space in the big Microsoft cloud—like your unique identity, with its own set of users, apps, and configurations. When the service tries to check your login or connect, it looks up that tenant by its ID or domain. If it doesn’t find it, here comes AADSTS90002 waving its flag.

This can happen for a bunch of reasons. Maybe somebody entered the wrong sign-in URL. Or the tenant got deleted or suspended—sometimes by accident! Sometimes it’s simple: the subscription for that tenant expired, or something went sideways during app registration or configuration. Developers occasionally hit this error if their app points to the wrong tenant or the wrong Azure AD environment during sign-in.

For admins, users, or anyone wrangling authentication in Microsoft 365, knowing that this error almost always means “Microsoft can’t find the place you’re looking for” is half the battle. Don’t panic—usually, the problem is a missing or wrong tenant ID, a deleted tenant, or a hiccup in the configuration. Once you get how tenant lookup works, you’re set up to find the problem spot and fix it fast.

How to Fix the AADSTS90002 Error Step by Step

Ready to chase down that AADSTS90002 error? Good news: most fixes are within your reach, even if it looks technical at first glance. First up, always double-check that you’re signing in with the correct tenant ID and using the right sign-in URL. Typos, copied values from old docs, or a mix-up between test and production environments are famous for causing this mess.

Next, make sure the tenant actually exists and is active. Sometimes, tenants get deleted, suspended, or the subscription attached goes stale. Head into the Microsoft admin center—or have your IT admin do it—and confirm the tenant status, any active subscriptions, and if your license is still good. This is usually the spot where someone realizes, “Oh, that tenant was decommissioned last quarter!”

If everything still looks off, check your app configuration. Are you using multi-tenant apps? Did you register them under the right Azure AD instance? Sometimes developers hardcode a tenant ID in code or a config file, and accidentally push the wrong value to production—especially in cloud deployments with multiple environments.

Automations, service principals, and CI/CD pipelines can throw this error too. If your scripts or apps suddenly start breaking, make sure your service principal credentials haven’t expired or been revoked. It’s common for a forgotten renewal or a deleted registration to trigger tenant lookup failures in non-interactive workflows.

Don’t overlook your network—odd as it sounds. Corporate proxies or DNS filters that block Microsoft login endpoints can trick you into thinking your tenant vanished. Give your network settings the once-over, flush DNS caches, and verify everything’s able to talk to Microsoft’s identity platforms. A missed proxy exception or a DNS misroute can send you on a wild goose chase.

If you want a deeper dive on identity security and common missteps that can tangle up your Azure AD experience, check out this discussion on how to manage conditional access and identity debt. These insights help you keep your identity layer healthy and proactive—so errors like this don’t catch you off guard.

Start with the basics, be methodical, and you’ll usually get the “Tenant Not Found” beast under control before lunch. And if you hit a wall, involving a subscription admin or support is your next best move.

Frequently Asked Questions and Answers About Tenant Not Found Issues

If you’ve ever puzzled over the AADSTS90002 error, you’re not alone. Folks always have questions—especially when their tenant “should” exist, but Microsoft keeps saying otherwise. Let’s run through the top things people wonder or worry about with this infamous error.

First off: “Why am I seeing ‘Tenant Not Found’ when I know my tenant exists?” This usually comes down to tiny details, like using an old or misspelled domain name, a region mismatch, or cached settings in your browser or app. Sometimes, DNS takes time to update after tenant changes. Always double-check the sign-in details and give cache or DNS flush a try before sweating the big stuff.

Another big one: “Can I recover access if I’m not an admin?” Usually, non-admins are limited. If the tenant got deleted or the subscription lapsed, only someone with admin rights can bring it back to life. Still, if you’re locked out because of minor issues—like incorrect URLs or outdated service principals—you might be able to nudge an admin or fix a config without waiting for top-level help.

Admins often want to know if there are ways to prevent these errors. Absolutely—proper tenant ID validation, thoroughly documenting your application setups, and testing sign-ins in isolated environments can make a world of difference. Developers should consider best practices, like using environment variables for configuration and validating tenant links during deployment, not just production.

For folks automating things or running CI/CD, expired client secrets or revoked service principal rights are common culprits. Make a habit of auditing your service principals, renewing credentials before they expire, and keeping logs handy to spot tenant resolution failures quickly.

Don’t forget network snags. DNS and proxy problems, or rigid firewall rules blocking Microsoft identity endpoints, can mimic a “tenant not found” error. Always check with IT for any recent network changes if you notice this cropping up out of the blue.