How to Find Your Microsoft 365 / Azure AD / Entra Tenant ID — 5 Methods (2026 Guide)
If you've ever set up SSO for a SaaS app, written an Azure App Registration, debugged an AADSTS500011 error, or filed a Microsoft support case, you've been asked for your tenant ID — and the first time most engineers hear the term, they spend ten minutes hunting through the Azure portal trying to figure out where it lives.
This guide gives you five reliable ways to find your Microsoft 365 / Azure AD / Entra tenant ID, including one that works without logging in to anything (so you can look up any tenant, not just your own). It also clears up the four GUIDs Microsoft loves to put in identical-looking config fields — tenant ID, object ID, application ID, subscription ID — and explains why your tenant ID is public by design.
What is a Microsoft tenant ID, exactly?
A tenant ID is a 36-character GUID like 1dc1b29c-c7d5-438a-9872-2b2502515766 that uniquely identifies one Microsoft 365 / Azure AD / Entra tenant in the entire Microsoft ecosystem. Every tenant — from a 5-user nonprofit to a 200,000-seat global enterprise — has exactly one tenant ID, and it is permanent for the lifetime of the tenant. You can rebrand, change your primary domain from oldname.com to newname.com, switch between licensing agreement types, or move clouds (commercial → GCC) and the GUID stays the same.
Microsoft has called this same value several different things over the years. You'll see all of these in docs, error messages, and config UIs — they all refer to the same GUID:
- Tenant ID — current preferred name (Entra-era).
- Directory ID — older Azure portal label, still appears in legacy screens.
- Azure AD tenant ID — pre-2023 terminology before Azure AD was renamed Microsoft Entra ID.
- Office 365 tenant ID — common in M365-admin-centre contexts.
- AAD tenant ID — abbreviation seen in older PowerShell modules.
- tid — the JWT claim name in ID tokens and access tokens.
If you're seeing any of these in a field that wants a GUID, it's the same value.
Method 1 — By domain, no login (fastest)
The fastest way is to ask Microsoft's public OpenID Connect discovery endpoint. Every domain that has been verified inside a Microsoft 365 / Entra tenant has a publicly readable JSON document at:
https://login.microsoftonline.com/{your-domain}/.well-known/openid-configuration
The 36-character GUID is embedded inside the issuer, token_endpoint, and authorization_endpoint URLs in that response. We built a one-line wrapper around it:
$ curl https://ogma.in/get-tenant-id/cyclades.one
1dc1b29c-c7d5-438a-9872-2b2502515766
For a structured payload (issuer, token endpoint, authorisation endpoint, cloud instance), add ?format=json:
$ curl -s 'https://ogma.in/get-tenant-id/cyclades.one?format=json' | jq
{
"ok": true,
"domain": "cyclades.one",
"tenant_id": "1dc1b29c-c7d5-438a-9872-2b2502515766",
"issuer": "https://sts.windows.net/1dc1b29c-c7d5-438a-9872-2b2502515766/",
"token_endpoint": "https://login.microsoftonline.com/.../oauth2/token",
"authorization_endpoint": "https://login.microsoftonline.com/.../oauth2/authorize",
"cloud_instance_name": "microsoftonline.com"
}
Or use the web form at /tools/tenant-id-finder — type the domain, get the GUID, click to copy.
This works for any tenant whose primary or secondary domain is registered with Microsoft. You don't need to be a member of that tenant. You don't need an Azure account. The data is publicly published because every OAuth 2.0 / OpenID Connect-aware app needs to read it to set up sign-in — that's the whole point of the OIDC discovery contract.
Method 2 — Microsoft Entra admin centre
The Microsoft-recommended in-portal location since the Azure AD → Entra rename in 2023:
- Sign in at entra.microsoft.com.
- In the left navigation, click Identity → Overview.
- The Tenant ID appears at the top of the page next to your tenant name. There's a copy-to-clipboard button next to it.
You need at least the Directory Reader role (most user accounts have this implicitly). If you can sign in to the tenant at all, you can usually see the tenant ID here.
Method 3 — Azure portal
The classic location, and the one most older Microsoft docs link to:
- Sign in at portal.azure.com.
- In the search bar at the top, type Microsoft Entra ID (or the legacy name, Azure Active Directory) and open it.
- On the Overview blade, the Tenant ID is on the Basic Information card. Older portals label it Directory ID — same GUID.
Useful when you're already in the Azure portal for some other reason and don't want to switch contexts.
Method 4 — Microsoft 365 admin centre
Less prominent than the Entra-side views but available if your account has only the Microsoft 365 admin role and not full Azure / Entra access:
- Sign in at admin.microsoft.com.
- Open Settings → Org settings → Organization profile.
- Scroll to find your Organization information; the tenant ID may be displayed depending on your role and tenant configuration. It's also visible in the URL of certain admin-centre pages as a query parameter.
If you don't see it here, fall back to Method 1 (domain lookup) — that always works and doesn't depend on what role you have.
Method 5 — PowerShell, curl, or any HTTP client (no login)
For automation pipelines, this is the cleanest path. You're calling the same Microsoft endpoint that Method 1 calls — directly, no third-party hop:
PowerShell
$Domain = 'cyclades.one'
$Issuer = (Invoke-RestMethod "https://login.microsoftonline.com/$Domain/.well-known/openid-configuration").issuer
$TenantId = $Issuer.Split('/') | Where-Object { $_ -match '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$' } | Select-Object -First 1
$TenantId
# 1dc1b29c-c7d5-438a-9872-2b2502515766
Bash + curl + jq
DOMAIN=cyclades.one
curl -s "https://login.microsoftonline.com/$DOMAIN/.well-known/openid-configuration" \
| jq -r '.issuer' \
| grep -oE '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'
Python
import re, urllib.request, json
domain = 'cyclades.one'
url = f'https://login.microsoftonline.com/{domain}/.well-known/openid-configuration'
data = json.loads(urllib.request.urlopen(url, timeout=5).read())
tenant_id = re.search(r'/([0-9a-f-]{36})/', data['issuer']).group(1)
print(tenant_id)
Go
package main
import (
"encoding/json"; "fmt"; "net/http"; "regexp"
)
func main() {
resp, _ := http.Get("https://login.microsoftonline.com/cyclades.one/.well-known/openid-configuration")
defer resp.Body.Close()
var d map[string]any
json.NewDecoder(resp.Body).Decode(&d)
re := regexp.MustCompile(`/([0-9a-f-]{36})/`)
fmt.Println(re.FindStringSubmatch(d["issuer"].(string))[1])
}
Or just hit the Ogma wrapper:
$ curl https://ogma.in/get-tenant-id/cyclades.one
1dc1b29c-c7d5-438a-9872-2b2502515766
Tenant ID vs Object ID vs Application ID vs Subscription ID
The most common reason engineers paste the wrong GUID into a config field is that all four of these look identical — 36-character lowercase hex with dashes, e.g. 1dc1b29c-c7d5-438a-9872-2b2502515766. Here's what each one identifies:
| GUID type | Identifies | Where you typically paste it | Wrong-value error |
|---|---|---|---|
| Tenant ID | The whole tenant (directory) | Authority URL: https://login.microsoftonline.com/{tenant-id}; tid claim verification; SAML metadata | AADSTS90002: Tenant '...' not found |
| Object ID | A user, group, service principal, or app object inside one tenant | Conditional Access exclusion lists; PIM role assignments; Graph API /users/{id} | Resource '...' does not exist |
| Application (client) ID | An app registration | client_id in OAuth flows; multi-tenant app config | AADSTS700016: Application '...' not found |
| Subscription ID | An Azure billing / resource scope | Azure Resource Manager URLs; ARM templates; az account set | SubscriptionNotFound |
Quick rule: tenant ID is "the whole company"; object ID is "a thing inside the company"; application ID is "a registered app"; subscription ID is "an Azure billing account". One tenant can have many of each of the others.
Is my tenant ID a secret?
No. Tenant IDs are public by design. Microsoft publishes the metadata at the OIDC discovery endpoint for every domain that has been registered as a tenant — no auth required. This is how every Microsoft authentication library on the planet (MSAL, ADAL, MSGraph SDKs, the .NET ConfidentialClientApplicationBuilder chain, the Python msal package, and so on) figures out which login screen to redirect users to.
Knowing a tenant ID grants zero access. Authentication still requires user credentials, MFA, Conditional Access conformance, and (where configured) device compliance. Anyone on the internet can find any tenant's ID; only authorised users can sign in. The security model assumes the tenant ID is known.
What you should treat as secret: client secrets, certificate private keys, refresh tokens, access tokens, and obviously user passwords. Those are the actual credentials.
When you'll need your tenant ID
- SSO / SAML / OIDC for a third-party SaaS app — most enterprise SaaS asks for "your Microsoft tenant" or "Azure AD tenant" during setup.
- Azure App Registration — the authority URL in single-tenant apps is
https://login.microsoftonline.com/{tenant-id}. - Microsoft Graph API — calling
/v1.0/tenants/{tenant-id}, or verifying thetidclaim in incoming tokens. - Microsoft support cases — engineers will ask for your tenant ID before they look at anything.
- Vendor support cases — Fortinet, CrowdStrike, Splunk, Cisco, and most SOC platforms ask for it when correlating Microsoft alerts to your environment.
- Cross-tenant access settings — when you allow a partner organisation, you list their tenant ID in your B2B config.
- Conditional Access by tenant — when a script targets a specific tenant by GUID rather than domain, for stability across rebrands.
- Microsoft Sentinel, Defender XDR, Purview integrations — external connectors usually authenticate against a specific tenant ID.
Tenant IDs in sovereign clouds
The discovery endpoint at login.microsoftonline.com only covers the global commercial cloud. Tenants in Microsoft's sovereign clouds have their own endpoints:
- US Government (GCC, GCC High, DoD) —
login.microsoftonline.us - China (operated by 21Vianet) —
login.partner.microsoftonline.cn - Legacy Germany cloud —
login.microsoftonline.de(deprecated; most tenants migrated to the global cloud)
The mechanism is identical — append /{domain}/.well-known/openid-configuration and parse the issuer URL. If you're not sure which cloud a tenant is in, try the global endpoint first; the vast majority of tenants worldwide are on it.
Common errors and what they mean
- AADSTS90002: Tenant '...' not found
- You're using a domain that isn't verified on any Microsoft tenant, or you're using the wrong cloud. Double-check the domain and try the
.onmicrosoft.comfallback (every tenant has one). - AADSTS500011 / AADSTS700016: invalid_client / Application '...' not found
- You probably pasted a tenant ID where a client ID was expected, or vice versa. Both are GUIDs but they're not interchangeable.
- "Tenant ID is required" in a SaaS app config
- Use the lookup tool above with your primary domain, or read it from the Entra admin centre.
- "Multiple tenants matched" in PowerShell
Connect-AzAccount - Your sign-in account exists in more than one tenant. Pass
-Tenant <tenant-id>explicitly.
Looking up tenant IDs in bulk
If you need to look up hundreds of tenant IDs (for example, you're a partner consolidating customer data), call Microsoft's discovery endpoint directly from your own infrastructure rather than going through any third-party wrapper. The endpoint is unauthenticated and Microsoft scales it to handle the entire planet's auth traffic, so it's the right place for high-volume lookups. Add a basic in-process cache keyed on domain — tenant IDs don't change, so caching for 24 hours is conservative.
The Ogma tool
We built two flavours of this lookup at /tools/tenant-id-finder:
- A web form for one-off lookups, with copy-on-click and inline OIDC endpoint info.
- A curl-friendly endpoint at
https://ogma.in/get-tenant-id/<domain>that returns plain text by default and JSON with?format=json.
Both call the same public Microsoft endpoint as Method 1 above — we're not running any backend that stores your data, scrapes Microsoft, or requires login. The point is just convenience: the curl form is easier to drop into Bash scripts and CI pipelines than parsing the OIDC JSON manually.
Beyond tenant IDs — Microsoft 365 services we deliver
Ogma is an authorised Microsoft Solutions Partner headquartered in Gurugram, India. If you're past the tenant-ID stage and need help with the underlying Microsoft 365 / Azure / Entra stack, we deliver:
- Microsoft 365 licensing and deployment in India — Business Premium for SMBs (under 300 users) and E3 / E5 / E7 for enterprise. INR billing, GST invoicing, no FX exposure.
- M365 pricing in India — including the new E7 Frontier Suite that bundles Copilot + Agent 365 + Entra Suite (GA 1 May 2026).
- Microsoft Purview deployment — DLP, sensitivity labels, Insider Risk, eDiscovery Premium, Audit, Compliance Manager.
- Purview DSPM for AI — Copilot risk visibility, oversharing detection, jailbreak alerts.
- Microsoft security stack — Defender XDR, Entra ID, Intune, Sentinel — deployed, tuned, and run as a managed service.
- Microsoft Azure CSP — Azure cloud reseller and managed services with INR billing.
Got a specific Microsoft 365 / Azure / Entra question that the tenant-ID lookup didn't answer? Reach out or call us at +91 80 0979 0979.
Stay ahead of cyber threats
One short email a week — curated Indian cybersecurity news, Fortinet releases, DPDPA updates. No fluff.