Make Your Tenant More Manageable by Tightening User Role Permissions

The ability of non-privileged user accounts to perform certain administrative tasks in an Entra ID tenant (Microsoft 365 tenant) is controlled by the user role permissions policy. This policy exists in every Entra ID tenant, and it comes with some default settings that are just plain silly for all but test tenants.

The settings I’m concerned about are found in the User settings page (Figure 1).

Apps, Tenants, and Security Groups

Three settings are up for debate. Should users be able to create registered apps, tenants, and security groups.

Only administrators should add registered apps to a tenant. Registered apps are enormously useful, especially the creation of an integrated Entra ID identity configuration that can authenticate against the Graph and other APIs. Attackers love apps too, and they like creating apps within compromised tenants and then assigning those apps the necessary permissions to exfiltrate data. The potential for app abuse is too high to allow “normal” users to create new apps might have made sense when attackers weren’t quite so interested in their use as an attack vector. The current threat horizon is such that it’s unwise to allow non-administrators to create new apps.

The same is true for tenants. What regular Microsoft 365 user sets out to create a new Entra ID tenant as part of their daily activities? The answer is none. Creating new tenants might be something that’s useful as part of a development project, but tenants created from the Entra admin center have no licenses and aren’t particularly useful. Developers are better off working against a Microsoft 365 development tenant. They’ll get 25 licenses to work with and the tenant will automatically renew if they work with Graph APIs. If someone can make a good case to create a new tenant, let them make it to a tenant administrator.

I’m less strict about restricting users from creating security groups. However, because security groups are used to control access to resources, it seems to make sense to restrict their creation too. And most Microsoft 365 tenants suffer from a surplus of groups caused by unrestricted creation of Teams. Why add to the debris accumulating in a tenant?

I suspect that Microsoft chose the default settings with the best intentions at a time when threat was less evident. It’s regrettable that the settings remain so permissive. My position is therefore that tenants should update the default settings and impose control over creation of apps, tenants, and security groups. Feel free to disagree.

Using PowerShell to Update User Role Permissions

It’s easy to correct the settings in the Entra admin center. To make sure that the settings are not changed, you could use an Azure Automation scheduled runbook to update the settings periodically. Changes to the authorization policy require consent for the Policy.ReadWrite.Authorization permission. Here’s the necessary Microsoft Graph PowerShell SDK code to disable the ability for users to:

• Create new Entra ID registered apps (AllowedToCreateApps)
• Create security groups (AllowedToCreateSecurityGroups)
• Create new tenants (AllowedToCreateTenants)

Connect-MgGraph –NoWelcome -Scopes Policy.ReadWrite.Authorization
# Create hash table for body
$BodyParameters = @{}
# Create hash table to hold role permissions for tenant users
$RolePermissions = @{}
$RolePermissions.Add("AllowedToCreateTenants", $false)
$RolePermissions.Add("AllowedToCreateApps", $false)
$RolePermissions.Add("AllowedToCreateSecurityGroups", $false)
# Add the role permissions to the body
$BodyParameters.Add("DefaultUserRolePermissions", $RolePermissions)
# Update default authorization policy
Update-MgPolicyAuthorizationPolicy -BodyParameter $BodyParameters 
# Check the results
Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions | Format-List Allowed*

AllowedToCreateApps                      : False
AllowedToCreateSecurityGroups            : False
AllowedToCreateTenants                   : False
AllowedToReadBitlockerKeysForOwnedDevice : True
AllowedToReadOtherUsers                  : True

For a detailed description of the user role permissions, see this page. Note the admonition not to change the allowedToReadOtherUsers to false. Doing so will have “unfortunate effects.”

Take Control Over Your Tenant

The temptation exists not to change default settings in an administrative portal unless the obvious need exists. That’s a reasonable position to take, but the simple fact is that the three default settings discussed here are outdated and illogical. Take control of your tenant and make sure to disable these capabilities. There’s no point in allowing people create objects unless there’s good reason to do so.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

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.