Tenant ID: A Public Secret

Each tenant in Azure have a unique ID. This value is treated as a secret by some - and public ny others. But how easy is it to find, and what permissions are required Read more
13 Nov, 2024

Introduction

A while ago, I had a conversation with an old colleague about which information regarding an Azure tenant should be kept secure and which information is already publicly available, whether we like it or not.

While we agreed on most points, we had differing opinions about how secret a tenant ID should be.

In this post, I’ll explain why you shouldn’t spend time or effort trying to keep your Tenant ID a secret. I’ll also show you how to find the Tenant ID of any organization using nothing more than the domain.

Background

So what is a Tenant ID, and why is it relevant to know it?

A Tenant ID is the unique identifier that distinguishes your tenant from every other tenant in Azure. It is essentially a randomly generated GUID that Microsoft creates when the tenant is set up, and, like the tenant name, it is unique.

So why do you need to know it?

When working in Azure, you might be invited as a guest in multiple tenants. By getting into the habit of specifying the Tenant ID, you ensure that you always connect to the intended tenant. If you are using a Service Principal, the Tenant ID is mandatory for the connection.

Examples

Let’s look at some examples.

For these examples, we will use the following Tenant ID: 3893bf31-4d67-4495-9c7e-41300de844dc.

Connect to a Specific Tenant Using PowerShell AZ Module

When using the Azure PowerShell AZ module, this is the connect command you would use to specify the tenant:

You can read my post about the AZ module for more information about that topic

Connect to a Specific Tenant Using PowerShell Microsoft.Graph Module

We can do the same using the Microsoft Graph module, where the commands are quite similar to those in the AZ module, except you would define the scope of the connection.

So far, everything is simple — we’ve simply added -TenantId to the connect command, and we’re ready to go.

Connect to a specific tenant using Powershell Microsoft.Graph module with Service Principal

Now, let’s try something more realistic, and use a Service Principal for the connection. You will notice that we need to get a token for the connection, which requires us to identify the correct tenant ID.

Note: This is an example, please don’t store the Client secret in clear text in any scripts

How does it work?

The example above highlights one reason why some people argue that the Tenant ID should be kept secret—since it’s a value that could potentially be used during sign-in.

However, let’s debunk the idea that the Tenant ID is actually a secret.

In each of the following scenarios, I’ll be using my test domain, which has the domain name dev.mmt-consult.dk attached.

Find the Tenant ID Using a Known Domain

Let’s give it a try. All you need is PowerShell, a browser, or any terminal that can connect to the internet.

We’ll use the domain from earlier. To find the Tenant ID, visit the OpenID configuration page, which is used for collaboration with other organizations:

https://login.windows.net/Your-Domain/.well-known/openid-configuration

In this example, replace “Your-Domain” with the domain you want to retrieve the Tenant ID from, and open the page.

And voilà, the Tenant ID is displayed in several attributes!

Result from https://login.windows.net/Your-Domain/.well-known/openid-configuration

However, using a web browser can be a bit tedious, so let’s script this process using PowerShell.

To do this, we need to specify which attribute we’ll be targeting. In this case, we’ll use the “userinfo_endpoint” attribute, though you could choose any of the marked attributes. The format will always be the same, allowing us to use the “/” character as a delimiter to extract our desired value.

And that’s it. However, this doesn’t help us much, as we don’t have any credentials for this tenant. But the key takeaway is that it makes little sense to try and hide the Tenant ID. In fact, if someone with malicious intent can’t figure this out, then you likely don’t have much to worry about from them at all.

Find the Tenant Name Using the Tenant ID

Let’s try to reverse the above. Suppose you have the Tenant ID but don’t know the tenant’s name and would like to find it. (Note: This is not the domain name associated with the tenant, but the tenant’s name itself.)

While I haven’t found any public APIs that directly provide this information, the Azure portal offers a way to look it up. You could also use the developer tools in your browser, but honestly, there’s no need for that. But here’s the process:

  1. Go to portal.azure.com and sign in.
  2. Open the Microsoft Entra ID blade
  3. Now open: External Identities
  4. And find Cross-tenant access settings

Click to add a new organization

Add organization and type the tenant ID

In the window that appears, enter the Tenant ID of the organization you want to look up. Entra ID will perform a lookup and display the tenant name.

Microsoft did a lookup, and returns the tenant Name based on the provided tenant ID

You don’t need to add the organization; simply typing the Tenant ID will return the tenant name. As you can see, my dev tenant is named “Tastensen – development”.

Conclusion

In conclusion, trying to hide your Tenant ID—something that is publicly accessible—is a futile effort and a waste of resources. These resources could be better spent on more meaningful and impactful projects.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

About Martin Meiner Tästensen

I am a positive minded It professional, with more than 10 years of experience in various IT roles. I love to build, create and see how an idea can become a system affecting hundreds or thousands of employees – and at the same time try to make the system work as smooth as possible to give the best end user experience. My Primary focus for the first decade of my career has been towards classic infrastructure where I worked with a deep knowledge level on both network and servers – where the latter has ranged from physical servers, over OS layer and all the way to the services installed on the server.