A look at the Azure Well-Architected Framework in the context of multiple Azure AD tenants

The past decade has been very rewarding in working with Microsoft Azure. Each month – sometimes each week – we get new capabilities, updates, and innovations. Sometimes the pace is too staggering, and many people struggle to keep up with the latest developments. Myself included. Therefore I’m somewhat thankful that often the past innovations are still heavily influencing and defining new capabilities. Think of DNS, compute capacity, and Active Directory, for example.

I often use the Azure Well-Architected Framework – which you can find at https://aka.ms/WAF – as inspiration and reference when working with different designs and architectures. It’s a great library of insightful data while also requiring a solid grasp on almost everything in Azure at the same time. I find it an enjoyable challenge.

Identity is key

Identities are fundamental to perhaps all projects I work with. Since the dawn of Azure AD, circa 2010, the unspoken approach has been to have one enterprise identity. Before the public cloud, we had the luxury of building multiple on-premises Active Directory-based identities – perhaps within two or more forests. Often the reason was to segregate and separate distinct environments, and users would then have multiple identities to choose from.

With Azure AD, this is no more. Users identify their login with their email – in most cases. And that email is the account to access everything.

I wanted to dive deeper into the Azure Well-Architected Framework (or just WAF for short – and I know this might be unclear if you’re searching for Web Application Firewall-related content) and how identities are intended to be used based on written best practices. Let’s take a look!

The basics: identity checklist

Once you navigate to the WAF landing page, identity-related guidance can be found in one centralized place: Security > Design > Identity and access management.

The Checklist is an excellent place to start. It’s a short (just nine items) list, packing essential wisdom on how to manage identities. And at the heart of this is the following:

It’s concise. Have one single enterprise directory, and keep all your identities there. This translates to having a single Azure AD tenant with all of your identities.

Drilling further, WAF points to another Microsoft Docs article titled Identity management best practices. The key topic here is centralized identity management:

And we arrive at the same, somewhat obvious conclusion: aim to establish a single Azure AD instance (tenant). This is also a good practice in managing security: a single place for licenses, roles, access, conditional access, and so forth.

But what if you need multiple Azure AD tenants?

There are, however, justified reasons for having multiple Azure AD tenants. The first and most prominent reason is with Microsoft 365 in education environments. The principle is for larger organizations – with over 1 million users – to split into a multi-tenant architecture. One primary reason is to increase security by having student and faculty data separate. See details here.

Yet, even here, the strong recommendation is to create a single tenant:

Elsewhere, multiple Azure AD tenants might become relevant when doing mergers, acquisitions, and divestitures (a fancy word for ‘let’s sell this piece of business we don’t like‘). Even then, the recommendation is to consolidate when it becomes possible:

In closing

Each week, I keep coming back to WAF to dive deeper into Azure recommendations and best practices. Having spent time figuring out if or when multiple Azure AD tenants would make sense, it’s become more evident that a single tenant is (still) the best and practically only recommended approach. The edge cases – large tenants with over a million users – are still there, but they’ve also become rare.

To deploy multiple Azure AD tenants might be justified in exceptional cases, perhaps due to legislative reasons or data residency. Yet, I’d still strive to have a single Azure AD unless it becomes not possible.