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.

1. 1. Application admin – Full access to enterprise applications, application registrations, and application proxy settings.
   2. Cloud application admin – Full access to enterprise applications and application registrations. No application proxy.
   3. 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:

1. 1. Select Review permissions and consent which will place them into the admin consent approval workflow to accept the application.
   2. Select Block which will add the application to the directory but in a disabled status which also prevents any future consent requests .
   3. Select Deny which will deny the exiting request yet still allow any user to resubmit requests for the same application.
   4. Do nothing and ignore the request.  After the defined expiration (30 days by default) the request will be removed from the list.