Razi Rais
All writing
October 6, 2026 5 min read Digital Identity

Entra ID Tip: Who's Behind That Tenant GUID?

You open the Azure portal, follow a subscription link, and reach a directory you do not recognize. The account looks right. The destination does not.

The address bar gives you a clue:

https://login.microsoftonline.com/<tenant-guid>/oauth2/v2.0/authorize

That GUID identifies the directory handling authentication. It does not tell you much about the organization behind it.

You could ask an administrator to identify it, if you knew which administrator to ask. You could try signing in, except the unexpected directory might be the reason authentication is failing.

There is a more direct way. Microsoft Graph can return a tenant’s display name and default domain without requiring you to sign into that tenant.

The tip

Authenticate with a workforce account in a directory you can access. Then call:

GET https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='{target-guid}')

The required Graph permission is:

CrossTenantInformation.ReadBasic.All

The response contains basic tenant information. For example:

{
  "tenantId": "11111111-2222-3333-4444-555555555555",
  "displayName": "Contoso",
  "defaultDomainName": "contoso.com"
}

This is an illustrative response, not information from a real lookup.

The useful distinction is that you authenticate in one tenant and identify another. The operation does not require membership in the target directory.

What happens behind the call

PowerShell authenticates through tenant A and sends a Graph token with a request to identify tenant B. Graph validates the permission and returns basic tenant metadata without granting access to tenant B's resources.
Figure 1. Tenant A authenticates the caller. Tenant B is the subject of the query. Select the diagram to open the full size image.

The Graph SDK requests an access token through your chosen workforce tenant. Microsoft Graph checks the token and the permission before returning the requested metadata.

The target GUID is a function argument. It does not switch your authenticated session into the target tenant.

For this operation, Microsoft documents that the calling user does not need an Entra directory role. That does not remove the application’s permission and consent requirements. Administrator approval may be needed.

Personal Microsoft accounts are not supported for the delegated lookup. Use a work or school account.

Try it in PowerShell

Install the authentication module if it is not already available:

Install-Module Microsoft.Graph.Authentication -Scope CurrentUser

Replace the placeholders below with actual tenant GUIDs:

$ErrorActionPreference = 'Stop'

$SignInTenantId = [guid]'<your-workforce-tenant-guid>'
$TargetTenantId = [guid]'<target-tenant-guid>'

Connect-MgGraph `
    -TenantId $SignInTenantId.ToString() `
    -Scopes 'CrossTenantInformation.ReadBasic.All' `
    -ContextScope Process `
    -NoWelcome

try {
    $Uri = 'https://graph.microsoft.com/v1.0/tenantRelationships/' +
        "findTenantInformationByTenantId(tenantId='$TargetTenantId')"

    $Info = Invoke-MgGraphRequest -Method GET -Uri $Uri

    [PSCustomObject]@{
        TenantId      = $Info.tenantId
        DisplayName   = $Info.displayName
        DefaultDomain = $Info.defaultDomainName
    } | Format-List
}
finally {
    Disconnect-MgGraph | Out-Null
}

The SDK handles the token. You do not need to extract it or paste it into a request manually.

-ContextScope Process limits authentication context persistence to the current process. The finally block disconnects the Graph session after the lookup.

What the answer does not tell you

A default domain is not a domain inventory. The result might be a custom domain such as contoso.com, rather than the original .onmicrosoft.com domain.

To list verified domains, you need a different operation:

GET https://graph.microsoft.com/v1.0/domains

Reading that inventory for the target tenant requires appropriate authorization in that tenant, typically Domain.Read.All. The cross tenant lookup permission does not provide it.

The display name also does not identify the current administrator, establish legal ownership, or prove that your account can access the tenant’s subscriptions.

Use the response to identify the directory. Do not read more into it than the API returns.

Two traps worth avoiding

A GUID does not tell you its object type

Tenant IDs and subscription IDs have the same format. A Visual Studio subscription ID is not an Entra tenant ID, even though both pass a GUID format check.

Confirm what the identifier represents before interpreting a failed lookup.

OpenID discovery is not a reverse domain lookup

The public discovery endpoint is:

https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration

It publishes authentication metadata, including authorization endpoints and signing key locations.

When you query it with a tenant GUID, its authorization URL typically contains that same GUID. Extracting the tenant segment gives you back the identifier you already supplied. It does not reveal the directory’s domain.

Is this a security issue?

The API exposes metadata intentionally. Microsoft documents it as a way to validate tenant information when configuring cross tenant access settings.

That does not make the information irrelevant to security. A recognizable organization name and domain can help an attacker connect an otherwise opaque GUID to an organization. Those details can also supply context for phishing.

The boundary is what the lookup authorizes. It permits basic identification. It does not permit reading the target’s users, modifying applications, accessing subscriptions, or bypassing MFA.

Tenant IDs and display names should therefore be treated as discoverable identifiers, not secrets that protect access. Equally, a familiar name in the response is not evidence that a directory should be trusted.

Discovery is not authorization, and recognition is not verification.

Back to the unexpected redirect

You now have something more useful than an anonymous GUID. You can compare the directory with the expected tenant, ask the resource owner to confirm the association, or add the resolved name and domain to a support ticket.

The lookup will not repair a tenant association or solve an MFA failure. It answers the question that comes before those investigations:

Which directory am I actually being sent to?

References and diagram source

Microsoft Graph tenant lookup API

Editable Mermaid source

Download the PNG diagram

Scalable SVG diagram


Worth reading again?

Get the next one in your inbox.

No noise. Whenever something's worth saying.

Unsubscribe any time. No marketing, no noise.