Entra ID Introduces New Graph Permissions for User Accounts

New Graph Permissions for User Accounts Enable Granular Management

In January 2024, Microsoft introduced the User.ReadBasic.All Graph permission. The development was flagged in message center post MC704030. The new permission was important in terms of restricting access to user account properties when that information is not absolutely required.

Now without fanfare or even another message center notification, a set of new Graph permissions have appeared for the user resource type (user accounts). I came upon the new permissions when assigning permissions to apps in the Entra admin center (Figure 1).

A slightly different set of delegated permissions are available for assignment. The User.Read and User.Write permissions deal with updates to the profile (account settings) for the signed-in user. Remember, application permissions apply to all user accounts in a tenant while delegated permissions are used in interactive Microsoft Graph PowerShell SDK sessions.

The set of permissions include ones introduced earlier to help with granular management, such as User.RevokeSessions.All (revoke all sessions for a user account).

The New Granular Graph Permissions for User Accounts

According to the Graph change log, Microsoft added or updated some permissions for the user resource on December 23, 2024. These permissions are candidates for assignment to apps used by help desk personnel who need to maintain user accounts. The updated permissions

• User.EnableDisableAccount.All allows a user’s account to be enabled or disabled (sets the accountEnabled property for the account). This permission was added in February 2023. The latest update removes the need to use the Directory.AccessUserAs.All permission (allows the same directory access as the signed-in user) to read and update the accountEnabled property. The least privileged combination for delegated access to enable or disable accounts is now this permission with User.Read.All.

The new Graph permissions are:

• User-Mail.ReadWrite.All allows the management of the otherMails property for a user account. The property is used to hold one or more alternate mail addresses that is mandatory when enabling MFA for administrator roles. The alternative mail address is also used for self-service password reset.
• User-PasswordProfile.ReadWrite.All supports the management of password-related details for a user account, such as the password and whether the user must change the password the next time it’s used. If using delegated permissions, an additional administrative role is usually required to update password information, so make sure that an appropriate role is assigned to the help desk (using Privileged Identity Management for on-demand temporary assignments).
• User-Phone.ReadWrite.All allows updates to the businessPhones and mobilePhone properties of a user account. If used with delegated permissions, you’ll also need the User.Read.All permission.

The change log also notes the December 23, 2024 addition of the User.DeleteRestore.All permission to control the ability to delete a user account, restore a soft-deleted user account from the recycle bin, and remove a soft-deleted user account permanently. This permission is used in examples in the Automating Microsoft 365 with PowerShell eBook, so I’ve obviously come across it in the past.

Using the New Graph Permissions for User Accounts

To demonstrate the use of the new permissions, let’s consider the situation where you don’t want help desk personnel using interactive Microsoft Graph PowerShell SDK sessions to work with user data because of the way that the SDK accrues permissions over time. The solution is to create a new app and assign the app the necessary permissions to allow the agents to do their job. Then agents can sign into the Graph with the app to work in app-only mode and use application permissions.

Here we sign into the Graph using an app, authenticating with a certificate thumbprint loaded into the app. The only permission available is User.Read.All to allow agents to see details of all user accounts in the tenant. However, they cannot update any property of a user account.

Connect-MgGraph -AppId $AppId -TenantId $TenantId -CertificateThumbprint $Thumbprint -NoWelcome

Get-MgContext
ClientId               : aeeb6b93-5d43-409c-8548-674c931b7888
TenantId               : 22e90715-3da6-4a78-9ec6-b3282389492b
Scopes                 : {User.Read.All}
AuthType               : AppOnly
TokenCredentialType    : ClientCertificate
CertificateThumbprint  : 32C9529B1FFD08BCD483A5D98807E47A472C5318

After assigning the User-Phone.ReadWrite.All permission, an agent can update the phone numbers for any account.

Update-MgUser -UserId 'aa345971-b991-46cf-b1d7-b0d80d0d9245' -MobilePhone '+1 416 174 0012' -BusinessPhones '+1 215 145 1452'
Get-MgUser -UserId 'aa345971-b991-46cf-b1d7-b0d80d0d9245' | Format-Table Id, MobilePhone, BusinessPhones

Id                                   MobilePhone     BusinessPhones
--                                   -----------     --------------
aa345971-b991-46cf-b1d7-b0d80d0d9245 +1 416 174 0012 {+1 215 145 1452}

But attempts to update another property of the user account fail:

Update-MgUser -UserId 'aa345971-b991-46cf-b1d7-b0d80d0d9245' -OtherMails 'Random@contoso.com'
Update-MgUser_UpdateExpanded: Insufficient privileges to complete the operation.

If consent is now granted for the User-Mail.ReadWrite.All permission, the operation succeeds.

Let’s say that an agent needs to change the password for a user account. They build a password profile and run Update-MgUser again:

$NewPasswordProfile = @{}
$NewPasswordProfile.Add("Password", "RandomPasswordForAccount!")
$NewPasswordProfile.Add("ForceChangePasswordNextSignIn", $true)

Update-MgUser -UserId 'aa345971-b991-46cf-b1d7-b0d80d0d9245' -PasswordProfile $NewPasswordProfile
Update-MgUser_UpdateExpanded: Insufficient privileges to complete the operation.

Once the app has consent for the User-PasswordProfile.ReadWrite.All permission, the update succeeds. The need for an additional administrative role to update an account holding specific roles doesn’t apply because the interactive session uses app-only mode.

No Need to Upgrade Code

There’s no need to change existing scripts or runbooks to use the new Graph permissions for user accounts. If everything works, leave it as is unless you want to ensure that code runs with the lowest possible level of permissions. Put it on the list to consider!

---

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.