Update Entra ID User Role Permissions to Secure Your Tenant

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.