New Limitations of the Entra ID Tenant Information API

What's happening?

Microsoft are working very hard behind the scenes to make their cloud services as secure as possible. This is all completed under their "Secure Future Initiative" program. We're a big fan of this. Anything Microsoft can do to make their customer's environments and Microsoft's backend services more secure, more protected, can only be a good thing! Especially in today's day and age where malicious actors and threats are becoming more prevalent.

What's changed?

As part of these secure changes, Exchange Online's Autodiscover service has been patched. Autodiscover's primary function allows Outlook clients to easily and quickly fetch configuration and mailbox settings, dependant on a user's email address or email domain.

However, Autodiscover also allows external "partner organisations" access to a specific API called "GetFederationInformation", this is an unauthenticated API allowing for the discovery of Exchange organisation specific information. Its main purpose is to allow (again) quick and easy configuration of Organization Sharing policies within Exchange.

This API was open to some level of reconnaissance... Calling this API returned a full list of domains available within that Exchange Online organisation.

The Entra ID Tenant Information API used this endpoint to populate the "additionalDomains" property. It allowed us to return all domains currently connected to an Entra ID tenant.

Well, not anymore...

Microsoft patched this (and rightly so IMO). This particular Autodiscover API has been updated to only return the domain that was queried. So instead of returning a collection of all domains in the tenant, it only returns the one you specifically asked for.

How does this affect the Tophhie Cloud API?

It affects the API in several ways, let's break it down.

1. If you're using the "domainName" query parameter, you can specify any domain you believe to be a part of that tenant, but the primary domain information will be returned.
   1. For example, "tophhie.co.uk" is available in our tenant but "tophhie.cloud" is our primary domain. Therefore, the response will be based on "tophhie.cloud".
2. If you're using the tenantId query parameter, the same rules as 1. applies. Only primary domain information will be returned.
3. The SharePoint Online specific information is now more unreliable. Previously, we would loop through all additionalDomains with an onmicrosoft.com domain and query the SharePoint domain for that. This is now no longer possible. So, unless the primary domain for a tenant specifically ends in ".onmicrosoft.com" the spoDomains and tenantUsesSpo properties may result in false negatives.

Here's an example of the Tophhie Cloud tenant's response, so you can see how things like right now.

{
  "tenantId": "90f6a6e0-dc7a-455b-bf7b-fffca219a32a",
  "federationBrandName": null,
  "tenantDisplayName": "Tophhie Cloud",
  "defaultDomainName": "tophhie.cloud",
  "bannerLogo": "https://aadcdn.msauthimages.net/c1c6b6c8-hevobs9da8zwrml7rbcoi2a7nkvgtchcglblyptxysy/logintenantbranding/0/bannerlogo?ts=638428166886925440",
  "tenantRegion": "EU",
  "desktopSsoEnabled": true,
  "verifiedEmailSignUpDisallowed": true,
  "tenantIsUnmanaged": false,
  "tenantLeaveUrl": "https://myaccount.microsoft.com/organizations/leave/90f6a6e0-dc7a-455b-bf7b-fffca219a32a",
  "tenantUsesExo": true,
  "mxRecords": [
    "tophhie-cloud.s-v1.mx.microsoft"
  ],
  "emailConfiguration": [
    {
      "domain": "tophhie.cloud",
      "mxRecords": [
        "tophhie-cloud.s-v1.mx.microsoft"
      ],
      "exoSmtpDaneDnsSecEnabled": true
    }
  ],
  "tenantUsesSpo": false,
  "spoDomains": [ ],
  "verifiedDomains": 1,
  "additionalDomains": [
    "tophhie.cloud"
  ]
}

As you can see, only the primary domain information is returned, and SharePoint Online properties are "inconclusive". However, the rest of the response remains factual and correct.

My Stance

I, 100%, welcome the secure changes that Microsoft are making to their cloud services! Not only does this change in particular prevent discovery or overexposure of critical tenant information, but it also shows Microsoft's commitment to updating and evaluating all the tiny aspect of their cloud services and ensuring everything is "secure by default".

Now, don't get me wrong, it's slightly frustrating. I've designed a tool to assist in the discovery and troubleshooting of an Entra ID tenant, and this change has had a knock-on effect to this tool... but I can't argue with security and privacy. After all, these are cornerstones of the apps I build.

I will continue to better this tool, and ensure its information is accurate, within the realms of what Microsoft allows. No loopholes. Therefore, no workaround will be found for the missing additional domains. It is being embraced!

What do you think of these new secure initiative changes?

Is there anything else you'd like to see in the Entra ID Tenant Information API?

Until next time 👋