New Graph Permissions Pose Questions for Microsoft 365 Tenants

Granular Graph Permissions Appear Over Time But Are Useless Unless You Know About Them

Permission validation for applications is one of the tasks that tenant administrators know they should perform regularly. Two good reasons exist. First, applications can accrue permissions over time. Perhaps permissions creep isn’t quite as bad as it can be for the Microsoft Graph Command Line Tools app, but when an app holds many application permissions, the app could be used to access data that it shouldn’t. Second, over time, Microsoft introduces more granular permissions to give apps the access they need to work but no more.

An early example of more granularity within the Graph was the introduction of User.ReadBasic.All permission. Not every app that fetches account information needs full details, like assigned licenses. Many can run quite happily with access to account identifiers, user principal names, and display names, all of which are revealed through User.ReadBasic.All.

Users and groups are possibly the most common Entra ID objects accessed through the Graph APIs. It’s worth noting that over time the technical community gets better at protecting these objects through correct use of Graph permissions. Killing the perception that Group.Read.All is needed to access details of Entra groups is an example. As described in this article, Group.MemberRead.All is often sufficient.

Workload Restrictions

We’ve also seen workloads like SharePoint Online introduce granular permissions for sites, files and folders, and lists and list items.

Workloads also offer controls beyond Graph permissions. Examples include RBAC for Applications to limit the ability of permissions like Mail.Send or Mail.Create to access every mailbox in the tenant, and Teams application access policies to limit app access to online meetings, and there’s a bunch of steps that tenant administrators can take to limit app access to information.

Three New Graph Permissions

All of which brings me to the news that three new granular Graph permissions are available. Apps that create user accounts can use the User.Create permission instead of the much higher permissioned User.ReadWrite.All permission, while apps that need to modify (but not create or delete accounts) can use the User.ReadUpdate.All permission. Both permissions can be assigned through the Entra admin center (Figure 1).

Limiting App Permissions to Create New Registered Apps

The AppRegistration.Create permission exists but wasn’t available for assignment in my tenant through the Entra admin center at the time of writing. The permission was also not found in the set of app roles defined for the Graph service principal, which indicates that it had not yet been deployed to the tenant.

The App creation API documents the permission as the lowest required to create app registrations and it is available in both delegated and application forms. In a nutshell, the permission limits apps to creation new app registrations in an Entra ID tenant and is intended to avoid overuse of the broaderApplication.ReadWrite.All. Some additional details are available on the Permission Explorer site.

I don’t think that AppRegistration.Create will get as much use in day-to-day tenant operations as the two new granular permissions for user account will do, but it’s nice to see it being introduced.

Finding New Permissions

Developers and administrators might well ask how to discover when Microsoft issues new Graph permissions. Four options come to mind:

1. Write some code to check the app roles defined for the Graph service principal. For example, this code fetches the app roles and puts them into a variable that could be exported or reported upon (I’ll explain how to do this in a more comprehensive fashion in a future article):

$GraphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

[array]$AppRoles = $GraphSp.AppRoles | Select-Object Value, DisplayName, Id

$AppRoles | Format-Table DisplayName, Value -Wrap

1. Check the Microsoft Graph permissions reference. The GitHub source document usually precedes the online documentation.
2. Browse Merill’s Permission Explorer. The content is derived from the Microsoft Graph documentation, but it’s formatted to make the text more approachable.
3. Each time you assign permissions in the Entra admin center, check for new permissions. While it’s not very effective, I’ve certainly discovered new permissions using this method.

The service principal permissions report script (see this article) can also help by highlighting apps with specific permissions. The point is that we live with an evolving set of Graph permissions that are gradually becoming more granular. If organizations take security seriously, as they should, someone should be responsible for keeping an eye out for new Graph permissions and making people within the organization aware of what’s new and how more granular permissions might be used.

---

Microsoft 365 for IT Pros continues to earn 5-star reviews from readers—and for good reason. If you manage a Microsoft 365 tenant, you’ll benefit from practical, real-world guidance written by experts who work with the platform every day. The subscription includes extensive coverage of Microsoft 365 administration, security, compliance, and governance, plus a 450-page book dedicated to automating Microsoft 365 with PowerShell.