This wiki page represents a proposed change to the AAD tenant guidance.
When Should a New Azure AD Tenant Be Created?
This document is intended for IT professionals who are leveraging Microsoft cloud-based technologies. It addresses the question: when should a new Azure AD tenant be created?
Orientation and Terminology
Azure AD provides a variety of capabilities that include authentication & credential management, collaboration & application management, device management, information security, and enable cloud-based solutions. If you are familiar with Active Directory, Azure AD is the cloud-based, infrastructure-as-a-service (IaaS) version, providing many of the same kinds of capabilities, but with all the benefits of a cloud-based solution.
If you make use of Azure, you will be familiar with the term subscription. It’s the Azure customer “account” which ties together the various Azure services you are using. Here at the UW, you should get one via the Azure Subscription service as it provides contractual protections, a significant discount, and manages the Microsoft billing to UW budget process for you. The primary purpose of a subscription is to provide a common billing paradigm for use of Azure services. A subscription might have one or more tenants, directories, and domains associated with it.
A tenant is the organization that owns and manages a specific instance of Microsoft cloud services. It’s most often used in a inexact manner to refer to the set of Azure AD and Office 365 services for an organization, e.g. “we’ve configured our tenant in this way.” A given organization might have many tenants (the UW does), and when this is the case, the name of core domain of the tenant is usually used to remove any ambiguity. The name of the core domain comes in the form *.onmicrosoft.com, where the * varies. A tenant may have many subscriptions, exactly one directory, and one or more domains associated with it. There are multiple vendors which use the term "tenant" in slightly different ways, and there are even several Microsoft products using the term tenant. For the purposes of this guidance, we only mean an Azure AD or Office 365 tenant. To be explicit: Microsoft Windows Virtual Desktop tenants and Azure AD B2C tenants are not covered or restricted by this guidance.
A directory is the Azure AD service. Each directory has one or more domains. A directory can have many subscriptions associated with it, but only one tenant.
A domain (or accepted domain) is a DNS zone for which a tenant has proven ownership (by creating an arbitrarily named DNS record as requested by Microsoft). It represents the possible domain suffixes (or namespace) which directory objects can use. Each tenant has a core domain (onmicrosoft.com) and a default domain (which by default is the core domain, but which can be changed). Neither of these are necessarily the primary domain used by the tenant.
The primary Azure AD tenant used at the UW is uwnetid.onmicrosoft.com. It has a default domain of cloud.washington.edu. The primary domain used by this tenant is uw.edu. There are several other domains associated with this tenant like washington.edu and u.washington.edu.
From an institutional point of view, using a single Azure AD tenant has the following benefits:
- Single Microsoft cloud identity for UW users. Less confusion with a single credential. The user principal name (UPN) of that credential matches the email address that most UW users use, i.e. email@example.com.
- Better contractual coverage for certain Microsoft cloud services. We have licensing, pricing, and a data security agreement including FERPA and BAA coverage for specific Microsoft cloud services available in the primary Azure AD tenant, provided the services are ordered under the UW contract and coordinated through UW-IT.
- Reduced cost of integration and management. There’s a distinct cost of managing identities, and integrating them with the well-established UW infrastructure, as well as maintaining the expertise needed to keep up with the pace of change of Azure AD.
However, there are a number of specific scenarios where those benefits are not significant and for which a new Azure AD tenant may be recommended. The scenarios where this may be the case include:
- fixed term use for testing or application development
- there is a plan to divest, commercialize, or separate from the UW
- if you have a need for a capability which has no general offering or where there is no integration possible currently. Note that this scenario is a little tricky because it really depends on the nature of specific Microsoft cloud service and UW-IT plans to provide future offerings or assist with integrations. So we’d strongly recommend that you first ask via firstname.lastname@example.org
- by design, Azure AD B2C requires a separate tenant
- scenarios where the brand identity can not be “uw.edu”
- there is a compelling business need for a tenant-wide setting which differs from the UW’s primary tenant
There are also implications to having more than one Azure AD tenant. If you had a separate Azure AD tenant, among the implications are:
- You will not have UW NetID or Groups service integration and will need to provide your own identity and access management capabilities and processes. Note: there are ways via Microsoft’s B2B capability (external users) to share identities across Azure AD tenants, but this will require additional investment to manage and may not work with whatever capability you need
- You will need to secure contractual coverage for your tenant and any Microsoft cloud services in that tenant.
- You may also have to pay more to license the Microsoft Online products integrated with that Azure AD tenant as they will not be covered by the UW Enterprise agreement
- You will need to provide all the management of this Azure AD tenant, supplying personnel with enough time to gain the expertise to navigate this constantly changing technology
Among the most significant of those implications are contractual data protections as well as increased licensing costs for the UW, but all of them are worth consideration.
For most scenarios, you should not create a new Azure AD tenant, but instead leverage the primary UW Azure AD tenant. If you do have a scenario which you think falls into the scenarios noted above, you should discuss it with UW-IT first.
We’ll help you analyze whether there is a way to use the primary UW Azure AD tenant. If not, we’ll explore whether UW-IT should manage your Azure AD tenant or if we would delegate management of it to you. We can also explore whether it is possible to add your Azure AD tenant to the UW Enterprise agreement.
Microsoft Windows Virtual Desktop tenants and Azure AD B2C tenants are not covered or restricted by this guidance.
Send an email to email@example.com with “New Azure AD tenant” as the subject to start a conversation.
NOTE: Upon direction from the UW Provost and UW CIO, UW-IT will discover any Azure AD tenants provisioned under the uw.edu or washington.edu DNS domain and may take control of that tenant to protect the interests of the University of Washington.