Site icon Microsoft 365 for IT Pros

How to Use Separate Apps to Control Access to the Microsoft Graph PowerShell SDK

Interactive Graph Sessions and Separate Entra ID Apps.
Advertisements

Use Apps to Control the Permissions Users Have for Interactive Graph Sessions

By default, when an administrator runs the Connect-MgGraph cmdlet to create a delegated interactive Graph session, they authenticate using the Microsoft Graph Command Line Tools enterprise app. Usually, everything works well, even if permissions creep can be an issue.

Large organizations that want to limit interactive access to the Microsoft Graph PowerShell SDK should consider creating separate registered apps for this purpose. This is especially true when organizations need tailored access to the Microsoft Graph PowerShell SDK. For example, help desk personnel might need permission to manage users, groups, and devices but should not have access to other Microsoft 365 data.

Each app can have its own set of user and group assignments to control the ability to use the app to run interactive Graph sessions, and its own set of Graph permissions to allow access to data.

Using Registered Apps

A registered app is created and controlled by the tenant. Like the Microsoft Graph Command Line Tools, a registered app’s service principal holds the permissions available to users who connect to the Graph through that app.

Like the enterprise app, the organization controls the permissions consented to for each registered app. An app therefore becomes the key element to enable granular management of permissions in line with the principle of access via least privileged permission.

To create a registered app to run limited Microsoft Graph PowerShell SDK interactive sessions:

Connect-MgGraph -TenantId mytenant.com -AppId a69635f3-3ac8-4949-a82b-f31b396de57b

It’s possible to have too much of a good thing by creating a proliferation of registered apps for different users. Every app must be managed, and administrators should conduct periodic reviews of the permissions assigned to the registered apps used with the Microsoft Graph PowerShell SDK to ensure that the apps do not accumulate unnecessary permissions over time and experience the same permission creep often seen with the Microsoft Graph Command Line Tools enterprise application.

Redirect URIs

Prior to the introduction of Web Account Manager (WAM) support for the Microsoft Graph PowerShell SDK (soon to be the default for all interactive Graph sessions with the default app), the redirect URI used for apps that wished to connect to the Graph was https://login.microsoftonline.com/common/oauth2/nativeclient. This value still works with PowerShell V5.1. However, if you use PowerShell Core, WAM uses a different authentication flow, and the nativeclient redirect results in an AADSTS50011 error.

Microsoft’s documentation says that using http://localhost together with a WAM broker redirect URI of the form ms-appx-web://Microsoft.AAD.BrokerPlugin/<AppId> is the right approach. Figure 1 shows an example of the full configuration.

Figure 1: Redirect URIs for a Microsoft Graph PowerShell SDK app with WAM

Assigning Users to use an App for Graph Sessions

The Get-MgServicePrincipalAppRoleAssignedTo cmdlet can be used to report the set of user accounts that have direct assignments for an app. This example uses the Get-MgServicePrincipal cmdlet to find the identifier for the app’s service principal, which is then used to find the assignees. Two assignees are present. One is the tenant administrator. The other assignee is a security group. Each assignee has an app role of Default Access (00000000-0000-0000-0000-000000000000), which is all that’s needed to run the app.

$GraphSDKApp = Get-MgServicePrincipal -filter "displayname eq 'HelpDeskGraphSDK'"

$GraphSDKApp | Format-Table DisplayName, Id

DisplayName         Id
--------------      --
Help Desk Graph SDK 0c593b15-ec27-4481-9e12-31777c9f6503

$Assignees = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $GraphSDKApp.Id

$Assignees | Format-Table CreatedDateTime, PrincipalDisplayName, AppRoleId

CreatedDateTime     PrincipalDisplayName       AppRoleId
---------------     --------------------       ---------
07/09/2026 09:04:54 Tenant Administrator       00000000-0000-0000-0000-000000000000
07/09/2026 09:03:00 Help Desk Graph SDK Access 00000000-0000-0000-0000-000000000000

You can also add direct assignments for an app with the New-MgUserAppRoleAssignment cmdlet. Here’s an example:

$SP = Get-MgServicePrincipal -filter "DisplayName eq 'HelpDeskGraphSDK'"
$DefaultRoleId = "00000000-0000-0000-0000-000000000000"
$User = Get-MgUser -UserId Kim.Akers@office365itpros.com

New-MgUserAppRoleAssignment -UserId $User.Id -AppRoleId $DefaultRoleId -PrincipalId $User.Id -ResourceId $SP.Id

Figure 2 shows a delegated session created with PowerShell Core using Microsoft Graph PowerShell SDK V2.39. The user has signed in but has a limited set of permissions, including User.ReadBasic.All to allow them to see some details of user accounts across the tenant. The User.ReadBasic.All permission doesn’t support filtering against the UserType property, so the attempt to find member accounts fails.

Figure 2: Using a delegated Graph session with a custom app

Complimentary to the above, it’s also a good idea to secure the default Microsoft Graph Command Line Tools app to make sure that only certain users are authorized to run it. There’s no point in leaving the default app wide open when you’re busily creating new apps to give restricted access to designated teams.


Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Microsoft 365 for IT Pros eBook bundle.

Exit mobile version