In this article, you’ll learn how to enable Azure AD Admin consent, which helps prevent users from accidentally allowing someone to access their mailbox or other data by putting an admin-gated approval process in front of the login process to third-party applications that allow sign-in using Microsoft 365 credentials.
We will also look at how to enable newer functionality that allows you to allow users to access safer third-party sites with limited permissions, without admin approval.
The danger of allowing user consent
One of the most important things you can do to secure your accounts and data in Microsoft 365 is to enable Multi-Factor Authentication. If you don’t have licensing for conditional access, and want to enable this and other important security settings, then enabling Security Defaults is an excellent starting point.
Enabling multi-factor authentication is not the panacea of security, but it helps protect against the core threat of someone providing their username and password to a malicious website via a simple phishing scam. A range of technologies and configuration is needed to provide better protection.
One major risk to your Microsoft 365 tenant is the threat of someone creating a website designed to fool a user into consenting to data access. This route of attack can bypass multi-factor authentication and allow a sophisticated attacker – or one who has bought the right tools – to extract data from your tenant or act on behalf of the user who consents.
In the example below, we can see a fairly common non-malicious consent screen shown when we attempt to use our Microsoft 365 login details to access a third-party web application.
In this example, the application only needs to view profile information, which seems reasonable. However, most users will not examine the permissions requested on this page and simply press accept, potentially granting access to more than expected.
If you want to understand exactly what someone could consent to, then visit the Graph Explorer. The simple answer is almost everything.
Closing the possibility of a user consenting to a third-party dangerous application is not as simple as it sounds.
Whilst we could remove the ability for users to consent, there are many legitimate times that a user might need this capability, such as when using built-in applications on their mobile device.
Enabling Azure AD Admin Consent
A good intermediate measure can be to use Azure AD Admin Consent feature. You will find this in the Azure AD Portal, under Enterprise Applications>User Settings.
This is straightforward to enable, and involves disabling the ability for a user to consent, then enabling the workflow for the consent process.
In the example below, we’ve chosen in step one to entirely limit the ability for a user to consent by choosing No to the Users can consent to apps accessing company data on their behalf:
In step two, we’ve enabled the admin consent option, and selected users who can review and approve admin consent requests, and selected an expiry date.
The user experience when someone attempts to sign-in for the first time to an application or website that requires consent will be as shown below:
The user can then provide a business justification and request approval. The reason will be sent via email using the consent workflow to one of the administrators specified in the Azure AD portal.
New improvements at Ignite for allowing verified applications to bypass admin consent with low-risk permissions
At Ignite 2020 Microsoft announced improvements to Azure AD allowing to decide whether a Microsoft-verified application publisher can bypass the admin consent process above, when it’s a set of low-risk permissions.
Verified publishers show a blue tick on the application consent page:
After enabling admin consent above, you can then visit the Azure AD Admin Portal Enterprise Applications>Consent and Permissions page to enable this new functionality:
After choosing to allow user consent for verified publishers, you will need to select the limited permissions. When you first enable this, Azure AD will prompt you with recommended permissions, as shown below:
You will see in the example above, we’ve selected the User.Read permission, which corresponds to the permissions that the website was requesting in our example earlier in the article.
Upon returning to the Enterprise Applications>User Settings page in the Azure AD portal, we’ll now see that the consent option is now greyed out, and our admin consent workflow is still active:
This would mean that in our example earlier, the unverified website requesting relatively low-risk permissions would still require admin approval, much like a riskier site. However, for website owners that work with Microsoft to gain verification, a user would have been able to provide consent themselves, without admin approval.
if I enable requirement for Azure AD Admin consent – does this affect apps that users have previously provided consent to in the past, or does it only apply to apps requesting consent after the setting is enabled?
Hi once you get to this step in your screenshot published -Upon returning to the Enterprise Applications>User Settings page in the Azure AD portal, we’ll now see that the consent option is now greyed out, and our admin consent workflow is still active:
it shows that- User can consent to apps accessing company data on their behalf is set to no. But if you set the permissions for consent to allow from verified publishers it turns the greyed out area of User can consent to apps accessing company data on their behalf to YES. I assume this is because users are now allowed to approve consent(as defined via a verified publisher).
My question is you did these steps in the article but your screen shot shows in the greyed out area no( User can consent to apps accessing company data on their behalf ) but when i allow users to consent to published apps it actually toggles that area to yes which is not what your screenshot shows.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Things do change over time and relying on a screenshot from two years ago is not a great idea. You’ve got to go on what’s in front of you today. Also, there are new approaches which can be taken to control app consents, like the new App Governance add-in for MCAS https://office365itpros.com/2021/07/21/microsoft-launches-preview-app-governance/.
I am developing an App for a Client to read OneDrive files and it seems that I will need to give Admin Consent so that the app can access without login of users. Before I approach Admin of the client, I am trying familiarize myself with MS Azure by testing on my Office 365 Home license. would I be able to do this or would I need an Enterprise License to do so?
Unable to get status when admin approve consent from azure portal. Hence every time when user login, we are getting “Approval required screen”. Even Admin approved consent and email received to user that “Admin consent granted” but again while login, user is getting “Approval required screen”.
Is it any way to link or modify setting that approved users should not get “Approval required screen” again ?
Steve – this creates Admin consent for all users. Which is not the best thing. I already have apps registered, when I enable this I get approval and that creates Admin consent, allowing all users. But how do I allow only that specific user to the app? I tried adding to users and groups on the app, but this doesn’t grant delegated Oauth2 permissions.
what if the Admin account does not have a mailbox associated?
I am guessing the notification will fail…is there a portal where the permission can be periodically reviewed and approved or is it email only?
Set the ‘Othermails’ attribute on the admin accounts which dont have a licence / mailbox to reroute notifications sent to a admin account to the admins normal mailbox