Skip to content

Microsoft Secure Score Series – 09 – Do not allow users to grant consent to unmanaged applications

In this series, I’ll be covering the Microsoft Secure Score improvement actions. Although Microsoft does a great job on telling you what to do, some actions have a much bigger impact and need to be balanced against business needs. Some actions might not even have value for your organization. In the end, Microsoft Secure Score is meant to strengthen your security, not a contest to reach the highest score possible. In this series, I’ll pick out random actions and try to make it as simple as possible, backed with notes from the field.

Articles in this series can be read separately since they are written at random order. The articles vary in case of impact and complexity and cover multiple categories. Here is a list of all the articles in this series:

01 – What is Microsoft Secure Score?

02 – Require MFA for administrative roles

03 – Enable Password Hash Sync if hybrid

04 – Ensure all users can complete multi-factor authentication for secure access

05 – Enable self-service password reset

06 – Enable policy to block legacy authentication

07 – Turn on sign-in risk policy

08 – Use Cloud App Security to detect anomalous behavior

09 – Do not allow users to grant consent to unmanaged applications

10 – Discover trends in shadow IT application usage

11 – Turn on user risk policy

12 – Turn on customer lockbox feature

13 – Set automated notifications for new and trending cloud applications in your organization

14 – Designate more than one global admin

15 – Do not expire passwords

Do not allow users to grant consent to unmanaged applications

Tighten the security of your services by regulating the access of third-party integrated apps. Only allow access to necessary apps that support robust security controls. Third-party applications are not created by Microsoft, so there is a possibility they could be used for malicious purposes like exfiltrating data from your tenancy. Attackers can maintain persistent access to your services through these integrated apps, without relying on compromised accounts.

Today we take a look at a serious problem in the modern IT landscape: consent to 3rd party applications. First, we need to understand what app consent is.

Let’s say one of your users is going to join the Microsoft Tech Community website. When the users sign up, the application requests a couple of permissions. These permissions are used to access resources on behalf of the user. In this case, Microsoft Tech Community asks for the following permissions:

  • Sign you in and read your profile
  • Maintain access to data you have given access to

You can review the given permissions for a user, using the Azure admin portal.

This seems harmless at first, but imagine a 3rd party application that asks for way more permissions and your users can accept this. This permission will be staying there, even when the users’ password changes. Even MFA won’t stop this kind of access.

Greedy hackers have found their way into this consent framework, and this can trick people to give permissions that later on can be used to steal information and data. This attack is also known as an “illicit consent grant attack“.

When you suspect an attack, you can use Microsoft Cloud App Security to hunt for permissions and setup alert rules. 

How to fix it?

Now that we understand how this works, let’s go on with prevention. You can prevent your users from granting access permissions on 3rd party apps. By using this setting, users will no longer be able to consent permissions to 3rd party apps. This can be done by using the Azure Active Directory admin center -> Azure Active Directory -> Enterprise Applications -> User settings

The same setting reflects in your Office 365 admin center under Settings ->Org settings -> User consent to apps

Users can no longer accept consent permissions to 3rd party apps. They get prompted with the following message:

Administrators can approve, block or deny the requests by using the Azure admin center.

What’s next?

Now in preview, you can setup Admin consent requests. This way, the users can request consent to administrators. The users can enter a motivation on why they need access to the app. Additionally, you can configure to receive email notifications when admin consent requests are created.

The user experience will look like this: ​

But wait! There’s more!

Until now, this setting was either all or nothing. Now it’s possible to configure Consent and permissions | Permission classifications. This feature is currently in preview. This way you can label permissions to “low impact” and grant users consent this specific permissions, while all other permissions have to be granted by admins.

Users can only consent to apps that were published by a verified publisher and apps that are registered in your tenant. Users can only consent to the permissions you have classified as "Low impact"

Let’s wrap up

If you want the most control and best security, disabling the user consent would be your best option. But this option backfires on your administrators because they have to approve each consent. When adding the verified publishers and low impact permissions, you can take away some (or most) of that work. This will depend mostly on whether your apps have verified publishers, and what you define as low impact permissions.

Kenneth van Surksum already did a thorough article on the new additions for admin consent a few weeks ago. I suggest you check that one out too. Next to that, please take a look at the Microsoft documentation:

Stay safe!

1 thought on “Microsoft Secure Score Series – 09 – Do not allow users to grant consent to unmanaged applications”

  1. Hi,
    We went for the most restrictive option, Disable User Consent, but we are not getting any “Secure Score”-points. We tried to switch to “User ca consent to apps from verified…” and back again, but we still don’t get any points. :-(. Do you know what the problem could be?

Leave a Reply

Your email address will not be published. Required fields are marked *