Is my tenant ID a secret? Should I be worried it's discoverable?

No, tenant IDs are public by design. Every OAuth 2.0 / OpenID Connect-aware app needs to know yours to redirect users to the right login screen. Microsoft publishes the metadata at https://login.microsoftonline.com/{your-domain}/.well-known/openid-configuration for every domain that's been registered as a tenant — no auth required. Knowing a tenant ID grants zero access. Authentication still requires user credentials, MFA, and Conditional Access. Anyone can find any tenant's ID; only authorised users can sign in.

How does this tool find the tenant ID without me logging in?

It calls Microsoft's public OpenID Connect discovery endpoint with the domain you supply, parses the JSON response, and extracts the GUID embedded in the issuer URL. This is the same mechanism every Microsoft authentication library uses internally to set up sign-in. No API keys, no scraping, no Microsoft Graph permissions needed — and zero traffic touches your tenant.

Where can I find my tenant ID inside the Microsoft portals?

Three places: (1) Microsoft Entra admin centre at entra.microsoft.com → Identity → Overview — Tenant ID is shown at the top. (2) Azure portal at portal.azure.com → Microsoft Entra ID → Overview. (3) Microsoft 365 admin centre at admin.microsoft.com → Settings → Org settings → Organisation profile (less prominent). All three show the same GUID. This tool gives you the same value without needing to log in or even have an account in that tenant.

What's the difference between tenant ID, object ID, application ID, and subscription ID?

Tenant ID identifies the whole tenant (the directory). Object ID identifies a specific user, group, or service principal inside that tenant. Application (client) ID identifies a specific app registration. Subscription ID identifies an Azure billing scope. They all look the same — 36-character GUIDs — but live at different layers of the hierarchy. The wrong one in a config will produce confusing 'AADSTS500011' / 'invalid_client' errors during auth.

Why does the tool say 'no tenant found' for some domains?

Three common reasons: (1) the domain isn't registered with any Microsoft 365 / Azure AD tenant — only domains added and verified inside a tenant resolve. (2) The tenant uses a different primary domain — try the <name>.onmicrosoft.com form, which every tenant has. (3) The tenant exists in a sovereign cloud (Microsoft 365 GCC, China operated by 21Vianet, US Government) — those have separate discovery endpoints we don't currently query.

Does this work for Microsoft 365 GCC, China 21Vianet, or US Government tenants?

Not currently. This tool only queries the global commercial cloud at login.microsoftonline.com . Tenants in login.microsoftonline.us (US Gov), login.partner.microsoftonline.cn (China 21Vianet), or login.microsoftonline.de (legacy Germany) need their own discovery endpoints. Most tenants worldwide are on the global commercial cloud, so this covers the vast majority of lookups.

All Tools

Microsoft Tenant ID Finder

Look up the Microsoft 365 / Azure AD / Entra tenant GUID (a.k.a. Directory ID) for any domain. Same answer the Azure portal gives you — without the login. Also available as a one-line curl: <code>curl https://ogma.in/get-tenant-id/<your-domain></code>

5 ways to find your Microsoft 365 / Entra tenant ID

The fastest is the lookup tool above — just enter your domain. But you can also pull the same GUID from the Entra admin centre, the Azure portal, the Microsoft 365 admin centre, or by calling Microsoft's public OpenID Connect discovery endpoint directly from PowerShell, Bash, or any HTTP client. All five return the same value; pick whichever fits your workflow.

METHOD 1

Use the form above (no login)

Type your primary domain (or any verified domain on the tenant — .onmicrosoft.com works as a fallback) into the input above. The 36-character tenant GUID returns in under a second. No Microsoft login required because Microsoft publishes the metadata publicly via OpenID Connect discovery — same data path your auth libraries already use.

METHOD 2

Microsoft Entra admin centre

Sign in at entra.microsoft.com → Identity → Overview. The Tenant ID is shown at the top of the page next to your organisation name. This is the modern Microsoft-recommended location since the Azure AD → Entra rename in 2023.

METHOD 3

Azure portal

Sign in at portal.azure.com → search for and open Microsoft Entra ID (formerly Azure Active Directory) → Overview. The Tenant ID lives on the Basic Information card. Sometimes also labelled "Directory ID" in older screens — same GUID, just legacy terminology.

METHOD 4

Microsoft 365 admin centre

Sign in at admin.microsoft.com → Settings → Org settings → Organization profile. Less prominent than the Entra-side views but useful if you only have the Microsoft 365 admin role and not Entra access.

METHOD 5

PowerShell / curl / Bash (no login)

Same approach this tool uses internally — call Microsoft's public OpenID Connect discovery endpoint directly:

# curl + jq
curl -s "https://login.microsoftonline.com/your-domain.com/.well-known/openid-configuration" | jq -r .issuer

# PowerShell
(Invoke-RestMethod "https://login.microsoftonline.com/your-domain.com/.well-known/openid-configuration").issuer

# Or just use ours (returns plain text, no jq needed)
curl https://ogma.in/get-tenant-id/your-domain.com

The 36-character GUID embedded in the issuer URL is your tenant ID. This works against any tenant whose domain is registered with Microsoft — you don't need to be a member or admin.

Tenant ID vs Object ID vs Application ID — what's what?

All four GUIDs you'll see in Microsoft auth contexts look identical (36-character lowercase hex with dashes), but they identify different things. Mixing them up produces confusing AADSTS500011 / invalid_client errors during sign-in. Quick reference:

Tenant ID — identifies the whole tenant (the directory itself). What this tool returns. Sometimes shown as Directory ID.
Object ID — identifies a specific user, group, service principal, or application object inside that tenant. Different per object.
Application (client) ID — identifies a specific app registration. Used as client_id in OAuth flows.
Subscription ID — identifies an Azure billing/resource scope. Different from tenant ID; one tenant can have many subscriptions.

When you'll need your tenant ID

Configuring SSO / SAML / OIDC for a third-party SaaS app that asks for "your Microsoft tenant".
Setting up an Azure App Registration / API permissions when the docs ask for the tenant in the authority URL.
Calling Microsoft Graph with the /v1.0/tenants/{tenant-id} path or in the tid claim verification.
Filing a support case with Microsoft, Fortinet, CrowdStrike, or any SOC vendor that needs to identify your tenant.
Wiring up Conditional Access policies in scripts that target a specific tenant by GUID rather than domain.
Connecting Microsoft Sentinel, Defender XDR, or Purview integrations from external tools.

Looking to actually deploy or migrate to Microsoft 365? Ogma is an authorised Microsoft Solutions Partner — see our Microsoft 365 India, M365 pricing, Purview deployment, and Microsoft security stack services. CSP licensing in INR with GST invoicing.

Frequently Asked Questions

Common questions about the Microsoft Tenant ID Finder tool.

It's a 36-character GUID — for example <code>1dc1b29c-c7d5-438a-9872-2b2502515766</code> — that uniquely identifies a Microsoft 365 / Azure AD / Entra tenant. Every Microsoft 365 tenant has exactly one tenant ID, and it never changes, even if you rebrand or change your primary domain. You'll also see it called Directory ID (in older Azure portal screens), AAD tenant ID, Office 365 tenant ID, and Entra tenant ID — they all refer to the same GUID.

No, tenant IDs are public by design. Every OAuth 2.0 / OpenID Connect-aware app needs to know yours to redirect users to the right login screen. Microsoft publishes the metadata at <code>https://login.microsoftonline.com/{your-domain}/.well-known/openid-configuration</code> for every domain that's been registered as a tenant — no auth required. Knowing a tenant ID grants zero access. Authentication still requires user credentials, MFA, and Conditional Access. Anyone can find any tenant's ID; only authorised users can sign in.

It calls Microsoft's public OpenID Connect discovery endpoint with the domain you supply, parses the JSON response, and extracts the GUID embedded in the <code>issuer</code> URL. This is the same mechanism every Microsoft authentication library uses internally to set up sign-in. No API keys, no scraping, no Microsoft Graph permissions needed — and zero traffic touches your tenant.

Yes — that's the primary use case. The endpoint <code>https://ogma.in/get-tenant-id/<domain></code> returns just the GUID followed by a newline, ideal for shell pipes. Append <code>?format=json</code> to get a full machine-readable payload (issuer, token endpoint, authorisation endpoint, cloud instance). PowerShell users: <code>(Invoke-RestMethod "https://ogma.in/get-tenant-id/$Domain").Trim()</code> or call Microsoft's endpoint directly with <code>(Invoke-RestMethod "https://login.microsoftonline.com/$Domain/.well-known/openid-configuration").issuer</code>.

Three places: (1) Microsoft Entra admin centre at entra.microsoft.com → Identity → Overview — Tenant ID is shown at the top. (2) Azure portal at portal.azure.com → Microsoft Entra ID → Overview. (3) Microsoft 365 admin centre at admin.microsoft.com → Settings → Org settings → Organisation profile (less prominent). All three show the same GUID. This tool gives you the same value without needing to log in or even have an account in that tenant.

Tenant ID identifies the whole tenant (the directory). Object ID identifies a specific user, group, or service principal inside that tenant. Application (client) ID identifies a specific app registration. Subscription ID identifies an Azure billing scope. They all look the same — 36-character GUIDs — but live at different layers of the hierarchy. The wrong one in a config will produce confusing 'AADSTS500011' / 'invalid_client' errors during auth.

Three common reasons: (1) the domain isn't registered with any Microsoft 365 / Azure AD tenant — only domains added and verified inside a tenant resolve. (2) The tenant uses a different primary domain — try the <code><name>.onmicrosoft.com</code> form, which every tenant has. (3) The tenant exists in a sovereign cloud (Microsoft 365 GCC, China operated by 21Vianet, US Government) — those have separate discovery endpoints we don't currently query.

Not currently. This tool only queries the global commercial cloud at <code>login.microsoftonline.com</code>. Tenants in <code>login.microsoftonline.us</code> (US Gov), <code>login.partner.microsoftonline.cn</code> (China 21Vianet), or <code>login.microsoftonline.de</code> (legacy Germany) need their own discovery endpoints. Most tenants worldwide are on the global commercial cloud, so this covers the vast majority of lookups.

Yes — extract the domain from the email and look it up. For <code>[email protected]</code>, query <code>contoso.com</code>. The domain after the @ symbol is what Microsoft's discovery endpoint resolves. This works for any verified domain on the tenant, not just the primary one.

No. The tenant GUID is permanent for the lifetime of the tenant. Even if you rename the organisation, change primary domain, migrate licenses, or shift between agreement types, the GUID stays the same. The only way to 'change' a tenant ID is to provision a new tenant entirely — which is a major migration project, not a setting toggle.

The OpenID Connect discovery endpoint at <code>https://login.microsoftonline.com/{domain}/.well-known/openid-configuration</code> IS the official Microsoft mechanism — it's part of the OAuth 2.0 / OIDC standard and Microsoft maintains it as a public service. Tools like this one (and several others) just provide a friendlier UI and a one-line curl alternative. You can absolutely call it directly from your own scripts; we recommend that for production code paths.

Free, no signup, no API key. Rate limited to a sensible per-IP threshold to prevent abuse — well above any legitimate human or batch-script usage. If you need to look up thousands of tenants programmatically, consider calling Microsoft's discovery endpoint directly from your own infrastructure; that's the same call we'd be making on your behalf.