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.