Microsoft adds more granular permissions for working with user objects via the Graph API

Just before Christmas 2024, Microsoft released a set of new, more granular Graph API permissions to address some of the most common user-related scenarios. It is the type of change I’d expect to read about in a blog article or something, but for some reason it was released without much fanfare. And while I usually check on the Graph changelog around the end of each month, i skipped December for… reasons. So let’s talk about these new permissions, just to help spread some awareness.

The following new scopes have been introduced, both in /beta and /v1.0, and both with delegate and application permissions flavor:

• User-Mail.ReadWrite.All – allows you to manage the otherMails attribute for the user. This property allows you to set the alternate email address that’s mandatory for admin role assignments, and is also used as part of SSPR, thus it is considered a sensitive one. For this reason, additional permissions might be required in some scenarios, as detailed in this article (i.e. the calling user might need a highly privileged admin role assigned).
• User-PasswordProfile.ReadWrite.All – allows you to manage any password-related properties for the user. Those include the password itself, as well as the force change password flag. Obviously, quite a sensitive property as well, and thus additional permissions might be needed in some scenarios.
• User-Phone.ReadWrite.All – allows you to manage the businessPhones and mobilePhone attributes of the user. In case you are sensing a pattern here, you’re not wrong – this is yet another “sensitive” property, subject to the need for additional permissions in certain scenarios.
• User.EnableDisableAccount.All – allows you to toggle the accountEnabled flag for the user. You guessed it,  this is another sensitive property. Do note that in delegate scenarios, you will also need the User.Read.All scope for write operations.
• User.DeleteRestore.All – allows you to delete, permanently delete or recover user objects from the recycle bin. It is of course a sensitive operation.

As you might have noticed above, all of these scenarios involve some very sensitive properties or actions against user objects. These new additions in effect allow you to perform these operations without requiring the Directory.AccessAsUser.All scope, which was more or less a requirement for delegate permission scenarios. At the same time, leveraging these new permissions does not mean that you can perform operations against all users unimpeded. Additional permissions are still required for all scenarios affecting privileged users, in both delegate and application permissions context.

Let us examine a simple scenario that will illustrate a use case for these new permissions, as well as highlight the decoupling from the all-encompassing Directory.AccessAsUser.All (aka impersonate) scope. Say we want to block the user account for a specific admin, perhaps because he left the company. To perform this operation via delegate permissions, until now the user executing the action required the aforementioned impersonation scope, as even Directory.ReadWrite.All permissions were not sufficient on their own.

In contrast, with the new scope, the operation succeeds:

Similar behavior is observed with the rest of the newly introduced permissions. In turn, they allow customers and ISVs alike to address scenarios where the executing application (or admin tool) required excessive permissions and left the door wide open for potential abuse. A step in the right direction for sure, but more is needed to address all possible scenarios.

Anyway, this is all for now. As with any other Graph permissions related query, you can find additional information over at the Graph permissions explorer, as well as (most of) the official documentation.