Microsoft 365 allows custom and third-party applications using OAUTH 2.0 and OpenID to connect to services such as Exchange Online if given consent to do so.
What does this mean?
When users want to use third-party apps or websites, they can log in with an existing Microsoft 365 work or school account instead of creating another account to remember. Once this happens, a permission request screen usually appears like the one shown below.
Looking at the example above, if a user clicks “Accept” the app would be able to do the following
- Read your account profile information.
- Read basic company information.
- Read, update, create and delete events in your calendars.
- Read contacts in your contact folders.
As you can see, there’s information that companies may not want to be shared with third parties, so how can you prevent this?
The easiest way is to turn off “User consent to apps” from “Microsoft 365 admin centre” > “Settings” > “Org settings” > “User consent to apps”.
But what if there are some apps that your company wants users to utilise? This is where admin consent workflows are useful.
Admin consent requests
The settings for Admin consent can be enabled from the Azure Active Directory Extension in the Azure Portal. From the left-hand navigation select “Enterprise applications” > “User settings”
There are a few settings here so let us take a closer look.
- This enables the feature to allow users to submit requests, with this disabled the other settings do not apply.
- Add users who are eligible to review and approve consent requests. At the time of testing this function, individual users only can be selected, not groups.
- Enabling this send an email notification to the users selected in setting 2. Without notifications, approvers will need to check the “Admin consent requests” list.
- Enabling reminders will send reminder notifications to the selected approvers before the expiry of the request.
- Here you can set how long a request can remain unapproved before expiry. Once expired, users will need to submit additional requests. This can be set between 1 and 60 days.
Once enabled, the experience for the end user is slightly different. Instead of the ability to approve the request permissions, the user now sees an “Approval required” prompt where justification can be added before sending for approval.
Once “Request approval” is selected, confirmation is given, and the user is notified of the next steps.
The designated admin receives an email with details of the user, requested app, permissions required, requested date and expiry date. A direct link to the request in the Azure portal is included.
Clicking the link provides the reviewer with 3 options within the Azure Portal;
Review permissions and consent – This option takes the reviewer to the consent screen for the application allowing a decision to be made based on the permissions required. This can then be used to grant consent and allow the app to have access. By granting permission, the application is added to the company’s directory and is available to all users without the need for further consent. The requestor is then notified via mail and can continue to access the application using their work or school account.
Block – This option will block the request and will send the justification to the requestors. Additionally, this also block all future requests from other requestors.
Deny – Denies consent for all requestors but justification must be provided, future requests are allowed.
It is worth noting that from testing, if the request is from an account with the Global Administrator role assigned, the request is automatically allowed and does not follow the above workflow.
Disclaimer: Details are correct at time of publishing.
Paul Turner 