Controlling Access to Microsoft 365 for Entra ID Apps

A New Series About Different Aspects of Access Control

Many Practical 365 articles describe how to meet specific requirements for administrative tasks or scenarios by automating processes using a registered application. Such solutions typically have many moving parts, including features from Entra ID and Microsoft 365 workloads like Exchange Online and SharePoint Online.

In this series, I’ll explore the fundamentals of granting permissions to Entra ID user accounts (the “normal” administrator or support agent) and applications for task automation. You, as the reader, should be aware of which features are available and where the limits are.

Entra ID: The Heart and Backbone

Entra ID (aka Azure AD) is the central “directory store” containing all objects and resources (e.g., user accounts, managed identities, applications subscriptions, etc.) used by tenants. You can think of Entra ID as Active Directory on steroids. This isn’t surprising because Active Directory is now a 25-year-old directory designed for on-premises use while Entra ID is purpose-built to manage cloud deployments, including some very large implementations. Besides objects and resources, Entra ID holds configurations for identities and security. One well-known example is Conditional Access Policies.

Entra ID Roles

To manage objects and resources within Entra ID, an account needs permission. Many permissions are available, and Entra ID combines sets of permissions into roles to make it easier to assign permissions to accounts and groups. Microsoft provides a variety of Microsoft Entra roles. As of today, there are 118 built-in roles. Microsoft is constantly improving its services. The number of roles might differ between your tenant and other tenants!

You can find all roles in the Entra admin center by following this link. Figure 1 shows the roles listed in the admin center:

When you select a role, you can check who has it currently assigned under the “Assignments” tab. Under “Description,” you can find the detailed list of permissions for the role (Figure 2).

Of course, you can retrieve the list using Microsoft Graph:

# connect to Microsoft Graph
Connect-MgGraph -ContextScope process -Scopes RoleManagement.Read.Directory -NoWelcome

# count the number of roles
(Get-MgRoleManagementDirectoryRoleDefinition | measure-object).count

# display roles sorted by DisplayName
Get-MgRoleManagementDirectoryRoleDefinition | sort-object DisplayName

# store all roles in a variable
[array]$Roles=Get-MgRoleManagementDirectoryRoleDefinition

# show details for a role. The first one as an example
$Roles[0] | Format-List * -Force

# use the roleDefinitionID to retrieve all assigned permissions
Get-MgRoleManagementDirectoryRoleDefinitionInheritPermissionFrom -UnifiedRoleDefinitionId 62e90394-69f5-4237-9190-012177145e10 |
 Select-Object -ExpandProperty RolePermissions |
 Select-Object -ExpandProperty AllowedResourceActions

Note: To run the code above, you must connect to Microsoft Graph with at least RoleManagement.Read.Directory scope as outlined here.

Figure 3 and Figure 4 show the output from the commands:

Categories of Roles

Microsoft refers to “three broad categories” of roles:

• Microsoft Entra ID-specific roles: permissions granted only in Entra ID
• Service-specific roles in Microsoft Entra ID: permissions granted in Entra ID and a workload like Exchange Online or SharePoint Online
• Cross-service roles in Microsoft Entra ID: these roles have been granted permissions across multiple workloads

You can see this by the naming convention of the permissions. Figure 5 shows the role permissions for the Exchange Online Recipient Administrator role. Both Exchange Online and Entra ID permissions are included in the role.

Role Assignment

Multiple ways exist to assign roles. The simplest way is to add users or groups directly to a role through the “Add assignments” option (Figure 6):

By default, you can search for users and groups. However, you can also assign roles to “Enterprise Applications.” If you want to grant a role to an application, you need the Object ID of the app entry listed in “Enterprise Application” (not the identifier from “App registrations”) as shown in Figure 7. The reason why is that the assignment is to the service principal for an app instead of the app itself. Both enterprise apps and registered apps use service principals to hold role assignments.

As soon as you enter an object ID or name in the “Add assignments” menu, a new filter is shown (Figure 8):

Assignments made in this manner are permanent.  In other words, they remain in place until the assignments are removed by an administrator. Assigning roles should only be done for “Enterprise Applications” (including the service principals for Azure automation accounts). The reason is simple: allowing role assignments for registered apps could create a scenario where an app is very over-permissioned and privileged.

If the need exists to assign an administrative role to a user account, you should use Privileged Identity Management (read Brandon’s article) or Entitlement Management (read Vasil’s series).

In other articles, I will develop the story further to cover Entra ID custom RBAC roles and Administrative Units.