Relationship between Azure Active Directory and Directory (Tenant?)

New Contributor

So I've read through this post but still slightly uncertain of the relationship (


I see Azure AD is mentioned everywhere and I understand it's purpose. However, Microsoft has the option to Switch Directory and that basically takes me to a new Tenant under my account which has it's own Azure AD that is not connected to the other.


So, is it that the Switch Directory option is just another way of saying "Tenant"? Was it that Microsoft ran out of words to call it so they just settled on Directory?


So maybe I just need clarification:

Is each Directory it's own self-contained unit whose only relationship with other directories is that they are under the same account?


Is a Directory really another name for Tenant?


Whenever I research it and I see anything that says "Directory", someone always mention Azure AD in their response/answer, but there seems to be some confusion there, or at least, it is confusing me.

9 Replies
best response confirmed by Blakemar (New Contributor)

Hi @Blakemar ,


I understand your confusion. I agree there are several "terms" in Azure that seem to overlap or could be synonyms. In addition, you might see these terms used inconsistently in the Portal UI or documentation.


I always try to approach it from the practical point of view, for example:

  • Can I create a new Azure AD tenant and if yes, how is it related to my existing environment?
  • Can I create several directories under that tenant?
  • Can I have several domains under my tenant?

I like to use this article written for AAD developers as a reference:


I saw some confusing or even wrong replies in the "linked" topic like someone claiming you can have several directories under one AAD tenant.


I see it this way: Azure AD tenant = directory, and there is a strict 1:1 relationship between them (you cannot create several directories under a tenant). Each tenant has it's globally unique 'tenant ID' (in some places in the Portal referred as 'directory ID', but the ID is the same.


When you use 'Switch directories' option in the Portal, you are authenticating to a different AAD tenant (your account was invited as a guest there via Azure AD B2B Collaboration), so you will see different subscriptions and resources, and have different permissions, when you do so. Since most organizations have one production tenant (but some like ISVs can have more), you are switching to a different "company". That's how I see it.


You can, however, have several domains under one tenant / directory. You always get a default one {something}, but you can onboard custom domains (like upon proving you own that domain.

Hi @Blakemar 


To best of my understanding, you are correct - when switching directory, you are switching switching tenant i.e going from to which are separate, distinct units that do not shared users/resources etc.


This gives the definition of tenant/directory. 


Azure tenant

A dedicated and trusted instance of Azure AD that's automatically created when your organization signs up for a Microsoft cloud service subscription, such as Microsoft Azure, Microsoft Intune, or Office 365. An Azure tenant represents a single organization.


Azure AD directoryEach Azure tenant has a dedicated and trusted Azure AD directory. The Azure AD directory includes the tenant's users, groups, and apps and is used to perform identity and access management functions for tenant resources.


For all intents and purposes, they are pretty much the same as far as I can determine.


Hope this helps,



Edit - just saw @David Pazdera answered a more informative response while I was typing this out - looks like I wasn't too far off the mark though :) 

@David Pazdera Thanks. That was really helpful.

@HidMov Thanks. You were on point too :smile:

Can you describe the relationship when it comes to B2C tenant? Is that a different animal? My 1st tenant shows my B2C tenant as a *resource*, which is very confusing. Is there a heirarchy here, where the one tenant 'owns' another tenant? They both have their own AD and resources like you describe above, but the fact that the one tenant is a resource for another is weird, and I've never seen a good description of it.

Hi @buzzripper,


Azure AD B2C is indeed a different animal :).


It is meant for building consumer-facing apps that support different external IdPs like social accounts (FB, Twitter, etc.).


I do agree this sounds confusing, especially if you check the tutorial for creating a new B2C tenant. You must have a regular AAD tenant with an Azure subscription attached to it first before you can create a new B2C tenant like any other Azure resource. Once you create it however, you don't manage it like other resources but you need to switch to that directory and manage it separately.


Also, when you create your B2C tenant, it is empty, so there is no overlap of identities (users, groups) that exist in your AAD tenant (sometimes also reffered to as AAD B2E, Business-to-Enterprise).


Your applications (e.g. web apps) that are leveraging B2C functionality, can be deployed to any Azure subscription or even on-prem or Third Party clouds, as long as you register your app to that B2C tenant.




@David Pazdera 

Thanks for that reponse, that clarifies things a lot.


One other thing I'm confused about with B2C is: is B2C also the token server? Does it provide both the id_token and the access_token? If I understand things right, you designate what which of the user's AD values go into the id_token via those XML files. But I'm unclear on how you get/populate an access_token - these values usually come from the application, so not sure how that's accomplished.

To Create and Register Apps, use Microsoft Identity Platform for Identity and access management, which referred to as Azure Active directory (Azure-Ad) tenant. A Tennant represents an organization. If your account is associated with multiple tenants, you can select your account name to open a menu where you can switch between tenants is similar to the earlier option as Change Directory. Each tenant has its own tenant ID.



Think of B2C as the /authorize endpoints. Each policy (sign-in, sign-up, etc.) is a different, custom /authorize endpoint. Therefore, B2C is really just a collection of services that "wrap around" an AAD tenant. The client_credentials grant isn't supported but it is supported by the underlying AAD tenant that comes with your B2C service. Likewise, that AAD tenant is going to provide the /token endpoints.


Under the hood, they're a little different, too. They have to scale much larger than an org AAD tenant, so they are distributed (internally). 

You can see the custom /authorize endpoints (these are yours to create or modify into "user flows") by going into a policy and running the policy. Yes, my tenant is chickenwing 🤷‍