The Tenant ID is a crucial element in OAuth authentication. For single-tenant applications, this ID is typically incorporated into the token endpoint as part of the authentication protocol.
https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/tokenRetrieving the TenantId from a domain is a straightforward process, often accomplished with a single PowerShell command line (e.g., a one-liner).
(Invoke-WebRequest -Uri “https://login.microsoftonline.com/$(Read-Host -Prompt ‘enter the domain name’)/.well-known/openid-configuration” -Verbose:$false | ConvertFrom-Json).authorization_endpoint.Split(’/’)[3]
Most auth libraries also handle this process for you.
The TenantId is a globally unique identifier (GUID) that frequently appears in logs and configuration settings. It by itself is difficult to interpret because it lacks the surrounding context necessary to determine which tenant it belongs to.
For example, you might observe the TenantId in the Entra sign-in logs
It would be beneficial to identify the owner of the Application Tenant ID (f8cdef31-a31e-4b4a-93e4-5f571e91255a) found in the log entry, especially since I am already aware of my own Tenant ID (1c3a...). Knowing the owner is crucial, particularly if the application seems suspicious.
To find this information you can now use a Graph Beta endpoint with the Graph SDK eg
connect-mggraph -scopes CrossTenantInformation.ReadBasic.All
Find-MgTenantRelationshipTenantInformationByTenantId -TenantId f8cdef31-a31e-4b4a-93e4-5f571e91255a
this would then return
Since this is a Graph request, it requires authentication and is therefore subject to throttling restrictions. However, this is a clear indication that the associated Tenant ID is valid and presents no cause for concern.
Another way to find this information without needing to authenticate is to use the Metadata Endpoint that is part of the Windows Azure Access Control Service (ACS). This looks like
“https://accounts.accesscontrol.windows.net/$TenantId/metadata/json/1”
When you use this on a particular tenantid you get
Which are all my Accepted domains in the Exchange Online.
The Azure Access Control Service (ACS) was officially retired on November 7, 2018. ACS was originally designed to allow anonymous access for retrieving federation metadata, including the identity providers associated with a specific namespace.
It has been replaced by the OpenID Connect metadata endpoint:
https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration
This new endpoint is useful for performing domain-to-TenantID conversions, but it doesn’t return the same information as the ACS metadata endpoint. Additionally, it doesn’t list the domains associated with a specific tenant ID..
It’s notable that the reason the old ACS endpoint remains operational isn’t specified, beyond potentially supporting legacy applications or for internal purposes. Although the Graph endpoint is the only viable choice for application use, the old endpoint is a useful utility for troubleshooting, particularly when investigating suspicious tenant IDs. This is because it provides the complete domain list, which can sometimes reveal scenarios where companies have merged and where suspect domains are hidden behind legitimate ones.
I’ve developed a PowerShell script to perform this check, which I’ve made available on GitHub here: https://github.com/gscales/Powershell-Scripts/blob/master/Get-M365TenantAudienceMetadata.ps1.
Get-M365TenantAudienceMetadata -TenantId 0bbc0f81-861f-4a11-8e05-964b5d206a38
The code will try to compress the matching second level (or third level domains) down to on entry just the reduce the noise in the results