Microsoft Entra ID App Registration and Enterprise App Security Explained
One of the main reasons that application governance is often overlooked, as it relates to an organization’s cloud security posture, is because the topic is not fully understood. . However, it is vitally important to understand the fundamentals of Microsoft Entra ID (formerly Azure Active Directory) – tenants, app registrations, enterprise apps, and consent – and how they function properly together, so you can elevate your organizations security posture by implementing strategies to protect your cloud data.
This article is sponsored by ENow Software.
The fact is, it only takes one compromised user account to consent to a rogue app that syphons all the user’s SharePoint data or take over their mailbox. Business Email Compromise (BEC) amounts to $8 million in losses on a daily basis globally.
Understanding Microsoft Entra ID app registration and enterprise apps
In this article I explain the essential concepts of Microsoft Entra ID app registration and enterprise apps, and why this is important in terms of overall Microsoft Entra ID application governance.
Microsoft Entra ID vs Windows Server Active Directory
Microsoft Entra ID is an identity provider and management platform that you can use to authenticate users and authorize access to corporate applications. But it’s important to understand that Entra ID is different from Windows Server Active Directory (AD). The latter can be seen as an identity provider (IdP) that organizations install on their own on-premises servers, which they manage themselves, and it only serves their organization.
Entra ID is Microsoft’s cloud-based identity and access management platform, and it is completely different. It is the directory and identity management service that offers authentication and authorization services to various Microsoft services like Azure, Microsoft 365, and other cloud applications. It runs on several hundreds of thousands of Central Processing Units (CPUs) worldwide in Microsoft’s datacenters and as a global service it serves tens of millions of organizations.
What is an Entra ID tenant?
An Entra ID tenant is a specific instance of Entra ID containing user accounts, groups, devices, and apps, etc. The tenant is created automatically the first time you sign up for a Microsoft cloud service subscription. From there, it logically defines your organization within the service, just like an Azure subscription or Microsoft 365 organization does.
I’ve discussed Entra ID as an identity provider in the previous section; it is like Active Directory, but different. As an access mechanism, Entra ID is different too. It allows organizations to provide single sign-on (SSO) to applications, services and systems, represented as Enterprise Apps and App Registrations.
Prime examples of enterprise applications are Salesforce and Workday (or in my bubble Sessionize and Run.Events).
Entra ID enterprise apps vs. app registrations
There tends to be a lot of confusion around the differences and similarities between enterprise apps, application registrations and service principals, so I would like to clarify.
Enterprise apps
Enterprise apps generally refer to applications published by third parties. Enterprise apps allow organizations to define access to applications, services and systems for people in the organization.
Entra ID app registrations and service principals
App registrations are primarily used by developers who integrate into Entra ID and define the access using the user accounts, groups, and data. This access consists of one or more API permissions.
If an app registration is established, it creates an App ID and service principal, representing the app in the directory in the developer’s tenant. A service principal is also created in the user’s tenant so that API permissions can be granted to the application, when the app is a multitenant app. In this case, the service principal references the globally unique app object and defines:
- what the app can do in the tenant
- who can access the app
- and what resources it can access.
As for the relationship between app registrations and enterprise apps, the enterprise app is then utilized by admins to manage access to the application in the user’s tenant.
API permissions
API permissions need to be granted before an app registration, and thus the application, service, or system is able to access anything as users and/or on behalf of users. Without permissions, the app registration can’t access anything and would merely be a placeholder. The process of granting access to the Microsoft Graph API, with rather descriptive labels like User.Read, is done through consent.
Understanding consent
With the default Entra ID settings, people in the organization can consent to apps accessing their data, which means consent ‘grants’, and potentially over-permissioned consent grants, could be overlooked.
Below is a hypothetical but common scenario where these concepts play out:
- A developer or vendor creates an application that needs information from their customer tenant in order for the application to function the way it was intended. They create an app registration in their tenant.
- The app registration provides the URL to access the application and the permissions needed within the customer’s tenant. When a customer wants to use the application, they access the URL and is prompted to provide consent, i.e., to allow the application to access data in their tenant.
- Once the customer approves the application, an enterprise app and service principal are created in their Entra ID tenant. They can then use the enterprise app to control single sign-on access for users in their organization.
It’s important to note that the default settings in Entra ID allow not just admins the ability to integrate applications, services, and systems – but literally everyone in the organization can create enterprise apps and consent to permissions, including guests.
Because as noted at the beginning of the article, it only takes one compromised user account to consent to a rogue app that syphons all the user’s SharePoint data or take over their mailbox, and BEC amounts to $8 million in losses on a daily basis globally.
There is a difference between an admin consenting and others consenting. When admin consent is provided, the application, service, and/or system is available to everyone in the organizations and permissions can be consented to beyond the scope of one user. An admin would consent to the User.Read.All, instead of the User.Read API permission.
User consent merely grants permission to the application, service and/or system for the scope of the consenting user. Common supply attack patterns include targeting vendors of multitenant apps to syphon data from organizations at scale with unprecedented impact, as the SolarWinds hack indicated.
At least single sign-on access to admin-consented apps can be managed through groups using role assignments.
How do you know the current configuration of your Entra ID application estate?
Now that you understand the Entra ID application basics, what if I said there’s a very clear, easy path for remediation and discovery of potential application-related security challenges in Entra ID? Before I guide you in the right direction, there are two important questions to begin thinking about and wrapping your mind around:
- Have I minimized potential attack patterns by correctly configuring the settings for applications installed in my tenant?
- Knowing the differences between user and admin consented apps and what API permissions they have, and the potential for attack patterns.
- Have I adequately strengthened my organizations security posture by locking down access to admin-consented apps?
- Understanding your role as it pertains to properly securing and governing Microsoft Entra ID applications.
I will help you answer these questions in my next article, “How to Properly Secure and Govern Microsoft Entra ID Apps” on Petri.com to find out how to secure your Entra ID apps!