Table of Contents
Connect-MgGraph Runs into Scope Problems
If, like me, you’re a fan of the Microsoft Graph PowerShell SDK, you’re probably aware of the problem of permissions creep that exists. Interactive Graph sessions use the Microsoft Graph Command Line Tools app, a first-party app specifically created for this purpose. The first time the Connect-MgGraph cmdlet is run in a tenant, Entra ID creates the service principal for the app. Like all other Microsoft and third-party apps (aka enterprise apps), the service principal for an app is the representation of the app in a tenant and holds the permissions for the app. Interactive sessions only use delegated permissions.
Over time, users who sign into interactive sessions probably find that they need extra permissions to run cmdlets. The Connect-MgGraph cmdlet has a Scopes parameter to allow users to request consent to use permissions. For example:
Connect-MgGraph -Scopes GroupMember.Read.All, User.ReadBasic.All
If the service principal doesn’t already hold the requested permission, Connect-MgGraph displays a screen to allow the user to grant consent to use the permission (Figure 1).
If the requesting user holds an administrator role with consent rights (like Application administrator), they can grant consent for the tenant. The requested permissions are then added to the set of delegated permissions held in the scope property of a grant object for the service principal and are included in the access tokens generated by Entra ID for interactive Graph SDK sessions.
The constant addition of permissions to the grant object is the source of the permissions creep problem. It’s not a new problem. I wrote about it in September 2021.
Permissions Creep Through Consents
Over time, the service principal accumulates many permissions. People are quite happy to request permissions, but few will come back later to say that the permission is no longer required and should be removed. So, the service principal accrues permissions over time.
A highly permissioned service principal is not necessarily a problem in itself. The permissions are delegated, meaning that they limit the signed-in user to accessing data that they already have access to. App-only mode is required to access tenant-wide data with the Microsoft Graph PowerShell SDK, which means using an app or an Azure Automation account.
As I am sure is the case in other tenants, the service principal for the Microsoft Graph Command Line Tools in my tenant experienced the full effects of permissions creep. I wasn’t bothered, until suddenly I was unable to consent to add any more permissions. Attempts to run Connect-MgGraph with the Scopes parameter in a privileged or non-privileged PowerShell session (using V7.6.2) resulted in a failed sign-in with an InteractiveBrowserCredential error:
Connect-MgGraph -Scopes AuditLogsQuery-SharePoint.Read.All WARNING: Note: Sign in by Web Account Manager (WAM) is enabled by default on Windows. If using an embedded terminal, the interactive browser window may be hidden behind other windows. Connect-MgGraph: InteractiveBrowserCredential authentication failed: User canceled authentication. An Internal Limit is the Root Cause
Too Many Permissions
Investigations revealed that a limit of approximately 140 delegated permissions applies to the service principal used by the Microsoft Graph Command Line Tools app. The exact limit varies depending on the permissions granted. I hit the limit at 140 permissions, but I can’t guarantee that the threshold won’t be reached at 139 or 141 permissions. In fact, in another tenant, I got to 146 permissions.
The point is that adding large numbers of permissions to the service principal can cause the Connect-MgGraph cmdlet to fail to connect. The error message is misleading because the failure has nothing to do with browser authentication. Instead, the cmdlet barfs internally and doesn’t add the scopes to the service principal.
The workaround is to run the Update-MgOauth2PermissionGrant cmdlet to remove some delegated permissions from the service principal to bring it below the limit. Once some scopes are removed, Connect-MgGraph -Scopes will run. Of course, if you remove five permissions and then attempt to add five more, you’re flirting with that limit.
A Bug or a Blessing?
I believe this problem to be a bug in the Connect-MgGraph cmdlet in V2.38 (and probably earlier releases) of the Microsoft Graph PowerShell SDK. I’ve reported the issue to Microsoft and hopefully the issue can be addressed in a future release. Or perhaps Microsoft will document the limit and say that tenants must manage the set of permissions for the service principal instead of engaging in perpetual permissions creep. Who knows where that might lead!
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.