Apply the Principle of Least Privilege to Groups Administration
The built-in Entra ID Groups Administrator administrative role gives anybody assigned the role the permission to manage groups in an Entra ID tenant. Actions available to the role include creating, updating, and deleting groups as well as managing group memberships if the target group is not a role-assignable group.
Large organizations often have the requirement to restrict the permissions for specific group administrators to specific groups instead of all the groups in the entire directory. Popular examples are restricting access by region or by seniority. I.e. Senior administrators are allowed to manage more groups than juniors are. Or in a global organization, IT staff in Europe are only allowed to manage groups which are relevant to the European side of the business.
Restricted and Non-Restricted Administrative Units
Geographic or organizational-based management of groups can be achieved with Administrative Units. Think of administrative units as a container for users, groups, or devices (or a mixture of all three types of objects). Administrative units can be created as a restricted management administrative unit or as non-restricted, meaning that tenant administrators inherit the ability to manage the administrative unit. Groups that are members of a restricted management administrative unit can only be managed by accounts assigned the Groups Administrator role scoped to that administrative unit. That holds true even for administrator accounts that already have a directory wide Groups Administrator role assignment. Once an administrative unit has been created, it’s not possible to change the restrict management setting retrospectively.
Non-restricted management administrative units work the other way around. Instead of excluding certain groups from being managed by accounts holding the directory wide Groups Administrator role, they support the assignment of Groups Administrator roles that apply only to the groups which are members of the administrative unit. In other words, IT administrators with Groups Administrator roles cannot manage all groups. They’re only allowed to manage a portion of groups in your directory. The example explained in this article shows how to restrict IT administrators to only manage groups in an administrative unit called EuropeanGroups.
Figure 1 shows some target objects for IT administrators in Europe to manage without assigning management permissions for all groups in the tenant (directory wide Groups Administrator role). Adding groups to an administrative unit must be done manually by a Privileged Role Administrator. Sadly, including groups in the administrative unit dynamically is not possible. Dynamic administrative units only support users or devices.
Scoped administrative roles are assigned under Roles and administrators in the Entra admin center (Figure 2). This is where you assign the users or groups to manage the target groups of the administrative unit.
When a role is assigned from the administrative unit menu, the role is automatically scoped to that administrative unit. It’s currently not possible to create a scoped role assignment from the main Roles and administrators menu.
Adding scoped assignments to user accounts works well when IT administrators are managing groups through the Entra admin center. However, it’s a different story when you think about a programmatic approach involving service principals.
Managing Groups Programmatically Using Scoped Roles
Managing groups manually through the admin center is appropriate for frequent but quick actions like adding or removing members. But developers or system administrators might think differently. They might want to create scripts or Azure Runbooks to manage groups. In the usual course of events, processes using the Microsoft Graph API must be assigned specific Graph permissions before they can access or modify Entra ID objects.
The permission that’s normally required for an app to manage groups is called Group.ReadWrite.All. As the name suggests, this permission grants read-write access to all groups in your organization. In many situations, granting such a powerful permission is not what you want.
SharePoint does a much better job here with the special Sites.Selected permission, which allows a tenant to restrict an app’s access to certain sites. Sadly, this kind of granular access is not available in Graph permissions for Entra ID groups. It’s all or nothing. The only way in which you can restrict what an app can do with groups is by assigning it different Graph permissions. The other available permissions are to only read all groups, or to only create (but not manage) groups.
Assigning the Group.ReadWrite.All permission to an app used in unattended scripts can be quite the risk. Imagine there’s an error in the code and instead of deleting a single group, the script goes rogue and deletes dozens or even hundreds of groups. When using a registered app, it’s also important to consider the security aspect. If a malicious actor gets hold of the app’s client secret, they have read and write access for all your groups compared to just a subset of groups. If you have processes to perform group maintenance, consider using an Azure Automation runbook and authenticate with a managed identity to avoid potential problems caused by attackers finding app secrets, or better again, use an app management policy to stop developers using app secrets.
Assigning an Administrative Unit Scoped Groups Administrator Role to an App
Luckily, it’s possible to assign an administrative unit scoped role to an app. In that case, the app will not need any Graph permissions at all. It doesn’t look like it at first because Entra ID does not show the Enterprise applications tab until you enter some characters into the search box (Figure 3).
After the role assignment is added, the main Roles and administrators menu in the Entra Admin Center lists the app’s ServicePrincipal alongside the scope of the administrative unit (Figure 4).
As mentioned earlier, you must not assign any Graph permissions to the app. If you assign Group.ReadWrite.All to the app, you override the scoping of the Groups administrator role to the administrative unit and give the app the permission to manage all groups.
Confirming the Permissions
Since I’m only testing, I use a client secret to sign into Microsoft Graph. Of course, I had to create a client secret for the app registration first. With the example shown below, I establish a new session by entering the Application (client) ID and the client secret into the $credentials variable.
$tenantId = Read-Host -Prompt "Enter the tenant Id" $credentials = Get-Credential -Message "Enter the application (client) Id and secret" Connect-MgGraph -TenantId $tenantId -ClientSecretCredential $credentials -NoWelcome
Now I can test if everything works as intended by running some test commands. I tried to update a group which is a member of the administrative unit and one that is not. As expected, I was only able to update the one that’s part of the administrative unit (Figure 5).
Update-MgGroup -GroupId <group id> -Description "<description>"
Figure 5 also shows the Microsoft Graph context of the session (Get-MgContext). The Scopes property is empty, confirming that the app doesn’t have any Graph permissions assigned. Because the app has a scoped Groups Administrator role assignment, it can do the same actions in PowerShell that a user with the same role can do in the Entra admin center). Even a simple Get-MgGroup command fails with “insufficient privileges to complete the operation”. With that said, if I pass a group id with Get-MgGroup -GroupId <group id> the app can read the details of any group in the directory, even if it’s not part of the administrative unit. This only works if the Group Id is explicitly included in the command.
Summary & Downsides
Administrative units are a great tool to implement the least privilege principle because they allow you to limit which objects (users, groups, devices) can be managed by different IT administrators. On the other hand, the available application permissions for group-related operations are quite limited as they only allow you to allow apps to manage all groups. We’d love to see something like SharePoint’s Site.Selected permission for groups as well in the future.
In the meantime, assigning an administrative unit scoped role to an app is a manageable workaround to restrict an app to only the groups it needs to manage. When the app signs into Microsoft Graph, the scoped Groups Administrator role is available in that session and the app can modify its scoped groups, their group memberships or even delete groups, despite not having any explicitly assigned Graph permissions.
The downside of this is that the app cannot create new groups. This restriction can be partially overcome by assigning the Group.Create application permission to the app. While this allows the app to create new groups, it cannot manage the groups until the groups are added to the administrative unit.
