Restricting Applications
Microsoft has put a great deal of effort into making their platforms expandable by supporting application development. This effort has led to a healthy ecosystem of third-party applications and services for the various flavors of Windows and for Microsoft 365… but any time you allow a third-party’s code to run in a system you own or control, you’re assuming risk, and that is true in the cloud as it is on prem. There are some simple and practical things you can do to reduce this risk.
The Basic Mechanics of App Authorization
App registrations in Entra ID are identity configurations that allow applications to integrate with Entra ID. When you register an application in Entra ID, you’re establishing a trust relationship between your app and Entra ID, creating a globally unique instance of the app in your directory. The registration process gives your application a unique ID that’s used to validate security tokens received from the service, as well as allowing you to associate credentials that the app can use to authenticate to the service.
When creating an app, you specify what permissions it may have. These permissions are applied when the app tries to access some kind of resource, either on behalf of a user (delegated permissions) or on its own behalf (application permissions). Permissions require the resource owner or an administrator to consent to the application’s access. The consent dialog is familiar to anyone who’s installed a third-party application or used Graph Explorer to play around with Graph; it allows an individual user or administrator to allow or block the application’s request. Microsoft’s documentation on the consent dialog is well worth reading because it clearly explains how the process works and what to look for when considering whether to accept a consent request.
Here’s a real-world example. I use the popular task management app Todoist. It offers a plug-in that integrates with Outlook and Teams to allow me to quickly create task items associated with mail items or messages. When I create a task from Outlook, the task contains a link to the source mail item, and Todoist does this via an app permission that allows it to read my mail items. I had to consent to give that app permission to read those items.
With all that said, you shouldn’t let users install or consent to applications on their own.
The Problems with User Consent
We’re all familiar with the biggest issue that comes up when users can install and manage applications on their own machines, especially if they have local admin access: it’s too easy for users to accidentally install malicious applications. Threat actors know this, which is why they create malicious applications. Worse still, some of these have actually been verified by Microsoft under its “verified publisher” program, while others have been distributed through stolen or compromised app publisher accounts. (There’s even an acronym for this: MACT, or “malicious applications in credible tenants!”) If you’re curious, there are publicly available explanations of how to create them if you want to see how easy it is.
Blocking User Consent
The simplest solution to this is to block users from consenting to applications on their own. Microsoft doesn’t do this by default, and the reason is obvious: it limits users’ ability to take advantage of the platform’s extensibility. However, the risk of allowing uncontrolled installation of applications is high enough that you should plan on doing this. You can use the Entra admin center or Graph PowerShell (with the Update-MgPolicyAuthorizationPolicy cmdlet) to set one of three states (Figure 1):
- All users can consent to any app. This is the default setting.
- Users may consent to applications from verified publishers. In this mode, users are allowed to consent to applications whose permissions are marked as “low impact,” or to applications that come from verified publishers, or to applications that are already registered in the tenant.
- Users can’t consent to any application.
Allowing users to consent to verified applications seems like a reasonable choice, until you consider that attackers have been able to successfully subvert Microsoft’s verification process. It also requires that you have a good understanding of which permissions are truly “low impact” in your environment. Allowing an application to read user email or files, for example, might be low impact for some users but very high impact for an application that can read the CFO’s mail or the CISO’s calendar.
Alternatives to Saying “No”
Instead of applying a blanket ban on user consent to applications, you can be more selective if you feel like the balance of risk versus reward warrants it.
First, you can turn on what Microsoft calls the admin consent workflow. When this flow is enabled, users who try to consent to an application will see a pop-up that prompts them for a justification, and then their request is routed to an admin queue where tenant administrators can review the requests. Administrators can approve or reject these requests individually. Approving a request enables the application for the entire tenant, exactly as it would if the admin went directly to the app registration page in the Entra admin center and granted admin consent there.
Second, you can consent on behalf of a specific user by using Graph PowerShell. This requires you to create a small script that creates the required service principal and then grants delegated permissions to it. The process is pretty straightforward but requires a good understanding of how app registrations and permissions interact.
Third, you can create app consent policies with Graph PowerShell. These policies work the same way as the settings on the tenant consent page shown in Figure 1, but can be scoped to specific Entra custom roles. For example, you could create a custom role called “Marketing Team”, assign it to the users in that team, and then add an app consent policy that allows team members to grant consent to verified applications that use low-impact permissions. This is less risky than allowing all users in the tenant to consent to verified applications, but it is not without risk because users may still be tricked into approving malicious applications.
Don’t Forget your Existing Applications
None of the steps I’ve outlined above help with the problem of applications that are already in your tenant. In addition to adding controls that restrict who can consent to apps, you need to use a script like this one to report on the apps that are already in your tenant and remove or restrict them as appropriate. Even if you’re not sure you are ready to apply consent controls, you should immediately investigate which apps are already in your tenant to mitigate any potentially nasty surprises.
