How To Find Permissions For Microsoft Graph PowerShell

Microsoft Graph PowerShell functions a little differently from the legacy PowerShell modules you might be familiar with. First, you need to establish what permissions you need to perform the tasks you want. Then, these permissions need to be explicitly called out either when you connect using the  -scope parameter or within the application you might be linking to.

The best practice is to use the principle of least privilege, meaning that you do not allow yourself the ability to perform tasks that you do not need to perform. For example, if you only need to read information about a group in Microsoft Entra ID, you do not need to assign yourself write permissions, as read permissions would meet your requirements.

By assigning permissions you do not need, you become overprivileged. This is something you often read about in the news. For example, an attacker has compromised a regular user’s system only to realise they can do more damage than they intended due to having access to privileged roles and data. 

By reducing the permissions you assign with Microsoft Graph, you mitigate the fallout in the event of a system becoming compromised and reduce the risk of accidental actions being performed, which could cause downtime or the loss of data.

In this tutorial, I will show you how to use various tools to determine the necessary and least required permissions to perform the tasks you need.

Use the Find-MgGraphCommand cmdlet to find permissions

PowerShell can be used to expose which permissions are required to run the commands we want to use in our scripts. Both the Find-MgGraphCommand and Find-MgGraphPermission can achieve similar results.

The Find-MgGraphCommand cmdlet allows you to target a specific cmdlet within PowerShell. You can then expand the permissions property of the cmdlet to evaluate related permissions. In contrast, the Find-MgGraphPermission cmdlet allows you to search for permissions matching the permission name and provides a description for the permission. 

The Find-MgGraphCommand cmdlet is much more practical, so I will focus on that here. I often use Find-MgGraphCommand instead of the dedicated cmdlet to find permissions as I usually know what command I need to run to perform a specific action task before knowing what permissions I need.

For example, to view all the permissions which pertain to the Get-MgBetaGroup cmdlet you can run the following:

Find-MgGraphCommand -command Get-MgBetaGroup -apiversion beta | `
select -first 1 -expandproperty permissions

From the output, you can see the permission names, which can be included within your authentication scripts or application and you can also see the full description which defines the permission. The -apiversion parameter was also included to target the beta version of the Microsoft Graph API as we declared a beta cmdlet in our command.

Find-MgGraphCommand
Find-MgGraphCommand

Other parameters can also be specified by using Find-MgGraphCommand, such as the -Uri parameter. This allows you to search for commands based on the URI path, which also exposes the related permissions. For example, to view all related cmdlets for the user URI path, you can run the following command:

Find-MgGraphCommand -Uri "/users/{id}"

Your output will be similar to the following and return results for both version 1.0 and the beta version of the Graph API.

Find-MgGraphCommand -Uri
Find-MgGraphCommand -Uri

Wildcards can also be used to expand your search results to find a specific string or search term. For example, if you want to find all commands that include the string ‘users’ somewhere in the name, you can run the following:

Find-MgGraphCommand -Uri .*users*.

Your output will look like the below:

Find-MgGraphCommand -Uri Wildcard
Find-MgGraphCommand -Uri Wildcard

You can see how useful this can be, as from the above, you may notice that there is a wider selection of commands available from the beta API, compared to v1.0.

Use the Microsoft Graph Explorer to find permissions

The Microsoft Graph Explorer tool can also be useful for looking up needed permissions. Let’s take the below example, I am performing a GET request with the following URL https://graph.microsoft.com/v1.0/me/drive/recent. This will return all of my recent files saved within my own OneDrive folder. Once I have selected the method and entered the URL, the Modify permissions tab will provide you with the necessary permissions to perform the task.

Graph Explorer My files
Graph Explorer My files

We can see that because I am only performing a GET request, the modify permissions tab is recommending me the necessary read permissions.

Now, let’s say I want to create a new folder at the root of my OneDrive. You can do this by using a POST request with the following request body:

{
    "name": "My new folder name,
    "folder": {}
}

We can now see that the modify permissions tab is showing us the necessary permission to create folders and files, these are Files.ReadWrite and Files.ReadWrite.All.

Creating a folder with Grahp Explorer
Creating a folder with Graph Explorer

The same process is true if you want to run a more advanced query, for example, below I am going to update the extension attribute of a managed Intune device:

Update a device with Graph Explorer
Update a device with Graph Explorer

If we select the modify permissions tab, strangely, we are only being told we need the Directory.AccessAsUser.All permission, meaning we would have the same permissions as the currently logged-in user.

Directory.AccessAsUser
Directory.AccessAsUser.All

Now, this goes back to what is know about permission types, where some permissions are available using the application method, they may not be available using the delegated method, and visa versa. This is true in the previous example and will lead nicely onto our next segment.

Use the Microsoft Docs to find permissions

The official Microsoft documentation at https://learn.microsoft.com is where you go to get finer details about the cmdlets, permissions and syntax for each command, although, this information can still be exposed using the other methods in the post.

If we take the previous example, where we updated a device’s extension attribute using Microsoft Graph Explorer (with delegated permissions), the modify permission tab only exposes us to the Directory.AccessAsUser.All permission. In this scenario, we cannot see what permissions are required if we want to use application permissions due to the limitations of the Graph Explorer tool.

However, we can use the Microsoft reference documentation for the Graph API to find the information we need. The following link will take you to the Update Device reference page: https://learn.microsoft.com/en-gb/graph/api/device-update?view=graph-rest-beta&tabs=powershell

This same experience is available on the Microsoft Graph PowerShell SDK reference documentation, here is the equivalent page: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.beta.identity.directorymanagement/update-mgbetadevice?view=graph-powershell-beta

On this page, under the permissions heading, you will see the following permissions table:

Permissions table for Graph API
Permissions table for Graph API

The table shows us that the application permission type provides the specific necessary permissions to perform the update device action, whereas delegated does not. So in some cases, the method we use is determined by the limitation of available permissions.

Daniel Bradley

My name is Daniel Bradley and I work with Microsoft 365 and Azure as an Engineer and Consultant. I enjoy writing technical content for you and engaging with the community. All opinions are my own.

Leave a Reply