Table of Contents
Azure AD Tenant Creation is Useful
Updated: 14 December 2022
I really don’t know why so much fuss and bother erupted (mostly in Twitter) when a preview setting to control creation of new tenants appeared in the User settings section of the Azure AD admin center (Figure 1). The fact is that people have always been able to create new tenants. Developers, for instance, often take the opportunity to run the free Microsoft 365 tenant offered by Microsoft for development purposes. If you’re doing Graph-based development, you can keep the free tenant (complete with 25 Office 365 E5 licenses) going for as long as you want.
Update: Microsoft formally documented the preview of the tenant creation control in message center notification MC485089 (14 Dec 2022). It is covered by Microsoft 365 roadmap item 109541 with general availability expected in March 2023.
Few users will find their way to the Azure AD admin center to create a new tenant. And if you restrict access to the administration portal using the setting in Figure 1, Azure AD blocks non-administrator access to the portal (Figure 2), so those that attempt to access the admin center cannot do very much.
Azure AD and Multiple Tenants
An important factor to consider is that Azure AD is a massive multi-tenant environment. A tenant is a logical division of work spanning user accounts, groups, applications, roles, and so on. A basic Azure AD tenant is free. The limitations that exist come through licensing.
Some organizations are perfectly happy with a single tenant; others will split work across multiple tenants, perhaps to accommodate operating units within the company or to respect geographical boundaries. From a Microsoft 365 perspective, a single tenant is the best option because it sets the foundation for easy collaboration and sharing across the entire organization. To enable data residency requirements, Microsoft 365 offers multi-geo support for Exchange Online, SharePoint Online, OneDrive for Business, and Teams.
Creating a New Azure AD Tenant
If users can create new tenants and have access to the Azure AD admin center, they can go to the overview section and select Manage tenants. They’ll see the set of tenants that their account can access, including the home tenant and tenants where they have guest membership. Selecting the Create option invokes a wizard to collect information about the new tenant. All that’s needed is:
- An organization (tenant) display name. The name does not need to be unique.
- An initial service domain. This is the sub-domain of onmicrosoft.com and must be unique.
- The datacenter region to host the tenant.
- The type of tenant. In this example, I use a regular Azure AD tenant rather than one used for Azure B2C.
In Figure 3, I’m creating a new Azure AD tenant called Office 365 for IT Pros. The wizard detects a problem with the service domain. I don’t know if someone else has a service domain called office365itpros.onmicrosoft.com, but I own office365itpros.com and the domain is registered to my Microsoft 365 tenant, so that might be where the problem lies. In any case, it’s easily fixed by choosing a different service domain. No relationship exists between the tenant display name and its service domain. And although Microsoft 365 uses the service domain for objects like Microsoft Online Email Routing Addresses (MOERA) and SharePoint Online site names, user principal names and user email addresses can use other domains registered for the tenant.
The user that creates a tenant becomes its first global administrator. This doesn’t involve creating a new member account in the tenant. Instead, Azure AD creates a guest account for the account that creates the tenant and assigns the global administrator role to the guest account.
Creating a new tenant takes just a few minutes. Once the tenant exists, you can sign in and begin working with the tenant. For instance, you can connect to the tenant with the Microsoft Graph PowerShell SDK.
Connect-MgGraph -TenantId Office365itpros2.onmicrosoft.com
Welcome To Microsoft Graph!
Get-MgOrganization | Format-Table DisplayName, VerifiedDomains
DisplayName VerifiedDomains
----------- ---------------
Office 365 for IT Pros {Office365itpros2.onmicrosoft.com}
Microsoft makes workload packs available for developer tenants to populate the tenant with objects like mailboxes and sites. A tenant created from the Azure AD admin center is bare-bones and completely separate to the tenant that the creating owner belongs to. No subscriptions or licenses are transferred. The only (tenuous) link connecting the two tenants is the guest account. Before any useful work can be done in the new tenant, the administrator must create objects like accounts, groups, apps, and configurations, and buy licenses and subscriptions.
A good reason to create a tenant is to have a baseline to compare settings against. Over time, a production tenant accrues updates and unless the organization practices good change management, it’s hard to know exactly what has been changed in different areas. A new tenant allows the organization to check the starting position and compare it to values in the production tenant. In addition, unlike developer tenants, which expire after 90 days if not used, tenants created in this manner don’t expire.
Azure AD Authorization Policy
Returning to the original point, all Azure AD tenants have a default authorization policy to hold the settings that control what users can do. These are the settings revealed in the Azure AD admin center. You can see the value of the settings through the Graph Explorer by running a query against https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy (Figure 4).
The policy shown in Figure 4 shows that the allowedToCreateTenants setting is False. This setting only applies to users. Administrators can still create tenants if they wish.
The authorization policy is also accessible via the Get-MgPolicyAuthorizationPolicy cmdlet. Running the cmdlet requires that the app has the Policy.Read.All permission. See this article for an explanation about how the SDK deals with permissions.
Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions | Format-List
AllowedToCreateApps : True
AllowedToCreateSecurityGroups : True
AllowedToReadBitlockerKeysForOwnedDevice : True
AllowedToReadOtherUsers : True
AdditionalProperties : {[allowedToCreateTenants, True]}
To update the authorization policy, the app must hold the Policy.ReadWrite.Authorization permission. You can then create a hash table to hold the new settings and apply the settings by running the Update-MgPolicyAuthorizationPolicy cmdlet:
$RolePermissions = @{}
$RolePermissions["allowedToCreateTenants"] = $False
Update-MgPolicyAuthorizationPolicy -AuthorizationPolicyId "authorizationPolicy"
-DefaultUserRolePermissions $RolePermissions
Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions | Format-List
AllowedToCreateApps : True
AllowedToCreateSecurityGroups : True
AllowedToReadBitlockerKeysForOwnedDevice : True
AllowedToReadOtherUsers : True
AdditionalProperties : {[allowedToCreateTenants, False]}
Nothing Odd About Multiple Tenants
There’s nothing odd about having multiple Azure AD tenants, if you have good reason to run more than a single tenant. As noted above, Microsoft 365 runs best with a single tenant, but developers and other users might need access to their own space.
Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.