A increasingly frequent experience for Microsoft 365 administrators and users leveraging various third-party solutions is the need to approve some sort of permissions request presented to them as Enterprise Applications (also know as Service Principals) while navigating a workflow. A common example of this is when attempting to sign into a third-party website which leverages the Microsoft Identity platform for user authentication. Another growing scenario is related to how devices like phones and conferencing systems can connect to and access data in Microsoft 365 tenants.
For readers of this blog this may already be somewhat familiar as Microsoft has been moving many aspects of their cloud to use Microsoft Graph and OAuth 2.0 authentication models. This now applies to many of the millions of IP phones and video conferencing systems in deployment today which can communicate directly to services like Exchange Online and Skype for Business Online. (Most of the newest Teams devices already use native Microsoft clients and software which do not require additional enterprise applications.)
As these applications can have different needs there are potentially different methods which can be used to approve these requests for consent to information and identities. This article is meant to define some of the basics, explore various workflows, and highlight a relatively new option for handling a potentially growing amount of requests in an environment.
Background
As explained in this Microsoft article the overall consent experience can provide slightly different consent prompts. For example take a look at the requests provided by the same application to two different users in the same tenant .
The highlighted difference in the requests above reflects the fact that the user on the left is assigned an administrator role with specific elevated rights pertaining to enterprise application management and the user on the right is a regular user account without those rights. In short, the first user is allowed to consent to applications either on their behalf or on behalf of the entire organization while the second user can only provide consent on their own behalf.
-
- If the administrator on the left simply chooses to accept the request as is and leaves the consent checkbox blank then the resulting consent would be the same as the only option the user on the right has. This is referred to as User Consent.
-
- If the administrator instead chooses to click the consent checkbox and then accept the request then this is known as Admin Consent and will mean that the app is now essentially pre-approved for all users in the tenant.
When admin consent is provided then no other users in the tenant will be prompted to provide consent when they use a workflow which utilizes that application. If several users in the tenant need to follow a workflow which requires this app then this may be the preferred approach. Most third-party applications function fine in either model with the only difference being how many users are requested to provide consent.
Some applications may require tenant-wide permissions though to operate and thus only the admin consent model is applicable. In that case then only an application administrator would have the ability to accept it. The consent option would also be omitted from the request window as it is not optional in that case. A regular user attempting to approve the same app would instead receive a message stating that the app requires administrator approval. The examples below show a request provided to an administrator (with the consent option suppressed) versus a regular user being informed that only an administrator can approve this app.
Controlling Consent
The experience explained above is the default behavior in a Microsoft 365 tenant due to the fact that all users are allowed to consent to permissions requests on their own behalf. But an administrator can change the default behavior by choosing to disable the ability for regular user accounts to consent to any enterprise applications, regardless of the scope of required consent.
-
- To confirm the current configuration in a tenant sign into the Azure Portal as an administrator and then go to the Enterprise Applications > User settings section.
-
- Note the status of the “Users can consent to apps accessing company data on their behalf” setting. As seen in the example below this tenant has chosen to change the default behavior by disabling user consent.
When user accounts are unable to provide consent to approve enterprise applications, even apps which only require consent only on behalf of the user, they will see the following message with no option to accept the request themselves.
Providing Consent
For tenants with this configuration there are a few different options available to approve consent requests depending on the desired outcome.
Assign Admin Role
If only a specific user or users will need to routinely approve applications in the tenant then it may be ideal for a global administrator to delegate the task of approving applications to them. Other than Global admins there are currently three additional administrative roles which allow a user to provide consent to enterprise applications.
-
- Application admin – Full access to enterprise applications, application registrations, and application proxy settings.
- Cloud application admin – Full access to enterprise applications and application registrations. No application proxy.
- Application developer – Create application registrations and consent to app access on their own behalf.
The first two roles above are application administrators and can approve requests with admin consent and user consent, while the last role simply allows the account to approve requests using user consent. As the Application developer role provides the minimum set of rights from the options above it is likely ideal for simply just approving requests that regular users cannot.
-
- To assign an admin role sign in to the Microsoft 365 admin center and then go to Users > Active users to locate the desired user account (e.g. steve@msteams.net).
-
- Highlight the user account, select Manage roles, select Admin center access, expand Show all by category, and then enable the preferred role under the Identity category. In this example the Application developer role will be assigned.
The ability to consent to app requests only on their own behalf (which was previously available to all users with the original default configuration) is now provided to this user via the assigned Application developer role. Thus when prompted for consent in the future this user will only be able to accept the request for permissions to actions as them and their accessible data.
Once approved the Enterprise Applications section in the Azure portal can be used to locate and manage all apps in the tenant. The Permissions section under a specific app will show whether and app was approved using admin or user consent. The Granted by column includes a link which lists any user(s) in the tenant which have approved individual requests for this specific app.
Manual Consent
For regular user accounts which should not be granted any administrative rights in the tenant then an administrator will need to approve the requests on their behalf. There are a few different approaches which can be used for an administrator to manually provide consent to a specific third-party application request.
-
- When the user attempts to install the application an administrator could connect to their workstation remotely and then use the “Have an admin account?” link in the request to provide administrative credentials to approve it.
-
- An administrator could simply follow the same workflow as the user on their own workstation to reach the request window, either while signed in with an appropriate administrator account or by using the Have an admin account? link to enter administrator account credentials if signed in with a regular user account.
-
- An administrator can use a link which points directly to the consent prompt, which can often be provided by the third-party application’s vendor, in the format of https://login.microsoftonline.com/common/adminconsent?client_id=<ApplicationID>. For example to approve the Poly One Touch Dial Service third-party application the direct URL would be:
https://login.microsoftonline.com/common/adminconsent?client_id=500e702f-0145-4462-b2a6-d00e35b92d45
Admin Consent Requests
Somewhat recently Microsoft has added an alternative workflow which simplifies the process for users and administrators alike. This configuration creates a reviewal workflow that lets users submit consent requests which administrators can then review offline and then decide to approve or deny. This new feature is functional today, although technically still in ‘Preview’ mode at the time this article was posted.
-
- To enable the admin consent review workflow sign into the Azure Portal as an administrator and then go to Enterprise Applications > User settings.
-
- Select Yes for the “Users can request admin consent to apps they are unable to consent to”.
In order to save this change at least one user needs to be selected as a reviewer.
-
- Click the Select admin consent request reviewers link next to the “Select users to review admin consent” setting.
Only show users in the tenant which are assigned an admin role required to approve applications (Global, Application, or Cloud Application admin roles) will appear in the prepopulated list or search results. This insures that only users who can actually approve requests can be selected to review requests.
-
- Click the desired admin account(s) from the list to add them to the Selected administrators list and then click the Select button at the bottom.
-
- If desired, modify the remaining settings to control the behavior of notification, reminder expiration, or consent request expiration, and then click Save at the top to commit these changes to the tenant.
Now when a regular user account is presented with a consent request it will look different than any examples shown before. Instead of receiving a message that the regular users is not allowed to approve requests they now will be able to enter a note and submit a request for an administrator to review.
Once submitted the user is informed that an administrator has been notified to review the request.
Any administrators currently selected as request reviewers will receive an email notification explaining the request along with a link to the Azure portal to review the request in more detail.
Using either the link in the email or by browsing to Enterprise Applications > Admin consent requests in the Azure portal any pending requests can be reviewed and handled as needed by approved administrators.
In the example above a request for the Poly One Touch Dial Service application appears in the list. Highlighting the application in the list will display additional details as well as which user account submitted the request along with the provided justification from the user.
The administrator has 4 options available to them at this point:
-
- Select Review permissions and consent which will place them into the admin consent approval workflow to accept the application.
- Select Block which will add the application to the directory but in a disabled status which also prevents any future consent requests .
- Select Deny which will deny the exiting request yet still allow any user to resubmit requests for the same application.
- Do nothing and ignore the request. After the defined expiration (30 days by default) the request will be removed from the list.
When switching over to Admin Consent does this erase the current User consented permissions? I want to make this change, but don’t want to require re-approving all applications in our environment.
Admin consent overrides user consent so if you provide consent to an app as an admin then it’ll be applicable to all users in the tenant. Unless the requested permissions has changed between the two requests then it should be fine.
Hello,
I am trying to figure out and find what is it that application which require admin consent is actually access. I can’t find and information about that. Is there any way (google, help, idiotic assistant with 0% of correct answer) to find out what application will access so that I can or can’t give admin consent? I can’t give consent without knowing what app is going to do.
The individual permissions requested by the app are literally listed in the consent request. What the app is doing with those permissions, and why, would need to be answered/documented by the third-party providing the application.
Great article Jeff! This is an underestimated feature and risk in my opinion.
Have you seen the new option in the Azure-portal on this yet? This enables a lot more granular control. Can’t copy the screenshot in here so I’ll post the link:
https://portal.azure.com.eu.cas.ms/#blade/Microsoft_AAD_IAM/ConsentPoliciesMenuBlade/UserSettings
Might be good stuff for your next article? 😉
Yes, I may just update this article with the new features once I get a chance to test them out and they are not longer listed as ‘preview’ features.
Hey Jeff,
thanks for the great article. I am still new to the OAuth flows.
I´m interested in what the Admin Consent (on behalf of the organization) allows and application to access.
For example(Delegated permission): if an admin consent on behalf of the organization the access to the profile to an application. The application is only able to access the profile data of persons which have logged in to the application and therefore provided and token. So the Admin consent does not open a door to access all data of the org, right? It is more a convenience feature to get rid of the consent card for all users, right? Thanks for a short confirmation.
Oliver, it depends on what permissions the application is asking for. If the app requests something like “access all users calendars’ then that’s something which requires an administrator to approve anyway. Approving that via the consent model might not be possible (not offered as an option when approving) but if it an option then it would be irrelevant if selected. For apps which require access to do things on behalf of the user or to access an individual user’s data then it’s only applicable to the user accessing the application, not all users in the entire organization. Either they have to individually approve the app or an admin does it so users are not prompted when they are performing an action. A good example of this is the third party application used for 3PIP phones connecting to SfB Online and/or Exchange Online. If that app is approved via admin consent then any user can sign in with one of those phones, but the app can only access the data for that user. So, if 10 people sign into 10 phones then the app only has access to those 10 user’s data, and not the hundreds of other users in the tenant.
Hey Jeff,
This is an great walk through of the process, thank you for providing it.
I do have a question / concern?
In our environment, we have it setup to grant permissions to anyone wanting access to any app outside the normal 0365 suite. When we allow permissions, we see ourselves (the approves) in the app details and not the user who has request permission for the app. Then when we remove ourselves, the user who asked for permissions to the app, still has permission to it. Its like they have phantom access, we can not see or control pass the approval stage.
Your thoughts?
If you approve the application using admin consent then it’ll be available for all users in the tenant, regardless of whether the admin user who originally approved it is still a valid user account or not.