Update October 7 2020: This functionality is now GA, see Publisher verification and app consent policies are now generally available

In February this year, I wrote an article about Admin consent in Azure Active Directory. The article titled: “Did you already modify your Azure AD consent defaults settings? Here is why you should“, explained why giving end-users within your Azure AD the ability to give consent for every Application might not be such a good idea.

While disabling this option for the end-users is recommended by Microsoft, and having a workflow in place to review any requests and approve if found valid is a more secure solution it introduced an administrative burden since each request must be reviewed by one of the defined users in the list of users to review admin consent requests.

In order to address this, Microsoft made some changes to the way the Admin consent workflow is working which allows an Azure AD administrator more control over which requests must be approved and which are allowed automatically.

Note: This post reflects the status of Admin consent as of May 22, 2020. Functionality may change, even right after this post has been published.

Enterprise Applications User Settings

Within the user settings page of the Enterprise Applications the following changes have been made.

There is now an extra configurable option called: “Users can consent to apps accessing company data for the groups they own”. This options allows you to define the following settings:

• If this option is set to yes, then all users who are owners of a group may consent to allow third-party multi-tenant applications to access the data of the groups they own.
• If this option is set to no, then no user can consent to those application to access the data of the groups they own.
• If this option is set to limited, then only the members of the group selected can consent to those applications to access the data of the groups they own. When enabled, you can add selected groups in the User settings blade.

Consent and permissions

Under Enterprise Applications another blade has been added, titled: “Consent and permissions”

In this page the following options are available.

You can define user consent for applications to either:

• Do not allow users to consent for apps, this is the default setting and will require an admin to do the consent on behalf of the user
• Allow user consent for apps from verified publishers, for selected permissions. This is the new recommended option, which I will address later on
• Allow user consent for all applications, which means that users can give consent to any app who want to access organizational data.

Here you can also define the options group owners have:

• Do not allow group owner consent, which is the default settings. Where group owners cannot allow applications to access data in the groups they own
• Allow group owner consent for selected group owners, if selected an extra option appears allowing you to specify the groups in scope
• Allow group owner consent for all group owners, which allows all group owners to allow applications to access data in the groups they own.

Verified publishers

In the blogpost on the Techcommunity site last Wednesday (May 20, 2020) titled: “Enhanced programs to help Microsoft 365 admins verify third-party apps” Microsoft made some announcements related to the option “Allow user consent for apps from verified publishers, for selected permissions” which I described above.

From the article: “At Build Microsoft introduced a Publisher Verification program that allows developers to add a verified organizational identity to their apps. This helps admins and end users understand the authenticity of applications requesting access to your organizational data.”

Basically this means that developers can have their Microsoft Partner Network (ID) verified and associated with their application, and therefore the publisher can be considered trusted. If verified the publisher receives a blue verified badge on the Azure AD consent prompt and other screens. More information can be found here: “Publisher verification (preview)” and “Mark your app as publisher verified (preview)“

Permission classifications

When you enable the option “Allow user consent for apps from verified publishers, for selected permissions (Recommended)” you get an extra option to select the permissions to classify as low impact. Which will bring you to the Permission classifications page

On the permission classifications page you can define which permissions you find acceptable for your organization data. Microsoft provides the most requested application permissions with low-risk access which you can select and add to the list. These permissions are:

• User.Read – sign in and read user profile
• offline_access – maintain access to data that users have given it access to
• openid – sign users in
• profile – view user’s basic profile

Once added, you can also define extra permissions for which you find them to have a low risk and to which users can consent without an Admin review. For example, if you want applications to also view a users’ email address you can simply add that to the list

Conclusion

With these new options, (which are still in preview) Microsoft addresses the administrative burden which was introduced when administrators disabled the option for users to consent to any application accessing company data.

Whether the new options described in this article will work for your company, mainly depends on whether the application publishers will have their MPN id verified and will be working with low risk access rights within their application.

If this is going to work, this will allow for verified publishers who publish applications requiring low risk access to organization data to have the consent request to be automatically approved. This will  increase the chance of adoption.

For applications which require higher risk access rights, or even access rights beyond the user (for the whole tenant), doing a review on the application will still be necessary.