The concept of Admin Consent can be a little confusing, and the official Microsoft documentation does a terrible job explaining it.
This article will answer the following questions:
- What is the purpose of Admin Consent?
- How does Admin Consent work?
- How do you review current Admin Consent settings?
- How do you configure Admin Consent?
We will use Easy365Manager as the use case to answer these questions.
Easy365Manager is a plugin for Active Directory Users & Computers that (version 1.5 and later) uses Microsoft Graph PowerShell to enable Office 365 management directly from AD.
What is the Purpose of Admin Consent
The purpose of Admin Consent is to keep tight control of actions that can be performed by Azure Applications, such as Microsoft Graph PowerShell or other Microsoft or third-party applications.
With delegated access, the Microsoft Graph PowerShell application can run your PowerShell commands in your security context. This has two main advantages:
- You can only perform actions for which you have the rights
- Any actions taken are logged with your ID in the unified audit log
But letting third-party (or Microsoft) applications run commands in your security context is not to be taken lightly – that’s why there is an additional layer of control: the Consent.
The consent acts like a white-list allowing an identity (e.g. adm.msk@easy365manager.com) to exercise permissions (e.g. User.ReadWrite.All) on a resource (e.g. Microsoft Graph).
A consent does not grant any permissions. It only allows you to use your existing permissions.
A consent can either be a User Consent granted to an individual user, or it can be an Admin Consent granted by an admin to all users.
How Does Admin Consent Work?
Whenever you use an Azure application, like Microsoft Graph PowerShell, someone needs to consent to the application acting on your behalf using your permissions.
The consent can take place as a User Consent (you consent yourself, assuming you have the rights to do so), or it can be an Admin Consent (an admin consents on your behalf).
Using Microsoft Graph PowerShell as an example, this is how it’s done:
You may notice one big problem here:
If an admin has already made a User Consent, she will no longer be presented with the option to grant an Admin Consent.
Why is this a problem?
Let’s say an administrator has granted herself a User Consent to manage Office 365 users. She later decides to implement an Admin Consent to let her entire staff run some PowerShell scripts to modify user properties.
Since the User Consent has blocked her path to granting the admin consent – and since the Azure Portal does not include a GUI to consent management – she’s now stuck with some really nasty PowerShell’ing to fix this problem!
Continue reading for more info on this…
How Do You Review Admin Consent Settings?
Your current application consent settings are visible via the Azure Portal and PowerShell
To review the consent settings using the Azure Portal, go to Enterprise Applications.
Then select Microsoft Graph PowerShell and click Permissions in the Security section.
(If you can’t find Microsoft Graph PowerShell read this article.)
Admin Consent will show you the admin consent (consent granted to all users by an admin).
User Consent will show you the personal consent granted to individual users.
The permission list is a read-only list with no option to make modifications!
To view the current application consent settings using PowerShell is a bit more tedious:
You need to identify the service principal ID of Microsoft Graph PowerShell, and you need to identify the service principal ID of the Microsoft Graph (as permissions could theoretically be assigned to other resources).
You also need to know what rights are needed to extract the information so you can connect with the appropriate scope (read this article for more info.)
This is a sample script to get you the consent settings for the Microsoft Graph PowerShell application (assigned on the Microsoft Graph resource):
Connect-MgGraph -Scopes "DelegatedPermissionGrant.ReadWrite.All Directory.AccessAsUser.All Directory.Read.All"
$MSGraphPS_AppId = "14d82eec-204b-4c2f-b7e8-296a70dab67e"
$MSGraph_AppId = "00000003-0000-0000-c000-000000000000"
$MicrosoftPowerShellGraph_Id = (Get-MgServicePrincipal -All | Where-Object { $_.AppId -eq $MSGraphPS_AppId}).Id
$Microsoftgraph_Id = (Get-MgServicePrincipal -All | Where-Object { $_.AppId -eq $MSGraph_AppId}).Id
Get-MgOauth2PermissionGrant -All | Where-Object { $_.clientId -eq $MicrosoftPowerShellGraph_Id -and $_.ResourceId -eq $Microsoftgraph_Id} | ft PrincipalId,ScopeThe output from the script will look similar to this:
PrincipalId Scope
----------- -----
User.ReadWrite.All Group.ReadWrite.All Domain.Read.All Directory.ReadWrite.All offline_access
10f136c2-55f0-41c4-9c96-6bab410c7c54 DelegatedPermissionGrant.ReadWrite.All Directory.AccessAsUser.All Directory.Read.All openid profile offline_access Directory.ReadWrite.All User.Read emailAdmin Consents are listed with an empty PrincipalId (since they apply to everyone).
User Consents are listed with a PrincipalId that identifies the user.
How Do You Configure Admin Consent?
As seen in the flowchart before, it’s very easy to grant an Admin Consent WHEN YOU HAVE NOT granted a User Consent to yourself earlier.
Simply connect to Microsoft Graph PowerShell with the desired scope, e.g.:
Connect-MgGraph -Scopes "User.ReadWrite.All,Group.ReadWrite.All"Then select “Consent on behalf of your organization”:
However, if you already have a User Consent, you need to configure the Admin Consent with PowerShell.
This is a very cumbersome procedure as the multivalued Admin Consent is written to a single-valued attribute. Therefore, any existing Admin Consents are removed from the application when you apply a new Admin Consent.
So you need to consider the following:
- Identify scopes that are not included in your current request but need to be maintained
- Identify scopes that are already configured with a higher privilege than the one you are applying.
- If, e.g., you’re applying “User.Read.All” but there already exists “User.ReadWrite.All” then you probably want to preserve that.
The poor interface to manage enterprise application consents will put a lot of admins in a tough situation… Which doesn’t make sense at all:
With the inclusion of Microsoft Graph PowerShell as an enterprise application (and MSOnline and AzureAD scripting killed by early 2023), the management of basic scripting rights should be accessible to admins of all levels (and not just semi-seasoned programmers.)
PowerShell Script to Manage Admin Consent
Easy365Manager version 1.5 and later are built on the Microsoft Graph PowerShell SDK.
In order to support delegation of Office 365 management we have created a PowerShell script to set up the required Admin Consent without modifying any existing configurations.
Feel free to modify the script and publish any changes as long as you credit the source page.
And, of course, if you like to work as efficient as possible, consider testing out the 30-day trial of Easy365Manager!
- Download and installation take only a few minutes.
- No infrastructure changes are needed.
- Integration with AD Users & Computers ensures super intuitive interface.
Our clients typically save dozens of hours every month by skipping tedious PowerShell’ing to do simple tasks like calendar delegation:
Download your 30-day trial here. You’ll be working more efficiently by the end of the day!