Microsoft’s Entra ID (formerly Azure Active Directory (AAD)) is probably the most important identity platform in the world. Any organization that uses Azure or Microsoft 365 products uses Entra ID as a core authentication/authorization platform.
The high importance of Entra ID is why I find the overall Application Registration/Service Principal experience so unacceptable. As you will see in this post, Microsoft has not engineered or exposed these objects in an easily comprehensible way, which leads people to misunderstand their purpose and scope.
The outcome is, of course, worse security for everyone.
What are Application Registrations and Service Principals?
This is not the intent of the post, so I will use a high level definition here.
Application Registration (App) | Service Principal (SP) |
---|---|
The globally 🌍 unique object in Entra ID for an application. | A specific instance of that application object in a single tenant.1 |
Apps are the foundational object here. You create an App in your tenant and that app is represented in other tenants (also in your own) by a corresponding Service Principal. Microsoft provides a good diagram here (image copied below).
Important things to know:
- Creating an application in the Portal automatically creates a SP in the same tenant.
- SPs also have their own credentials and authorizations. The application object is only the template. Therefore, a SP can have an Entra ID Role or API permissions (Graph, etc).
- Actions taken in a tenant (e.g. create a user) are done by the SP.
Why would you create apps/SPs?
In my experience, most organizations have four use cases:
- Service accounts/daemons — e.g. to manage Azure infrastructure or run scripts that must authenticate to AAD
- SAML/other authentication to internal apps – e.g. authenticate a user to a legacy Line-of-Business app
- Using 3rd party vendors that have authentication integrated with Entra ID – e.g. Dropbox, GitHub, etc
- Develop and publish applications to your customers – e.g. the opposite of #3
The Problems
The overall problem is that these objects are HARD. TO. UNDERSTAND and Microsoft’s UX decisions make them even harder to learn about by just doing. They also break traditional mental models of accounts. For example, Imagine if you created a user’s account and that action actually created two different object types with two different sets of permissions and credentials.
The Entra ID admin portal, which is probably where most admins/devs are first exposed to these object types, creates this confusion.
In the sections below, imagine you are a sysadmin new to Entra ID that is trying to figure this out on the job.
The names in Portal are confusing
In the Portal, App Registrations appear as App Registrations as expected.
However, Service Principals are instead put under Enterprise applications and the name Service Principal appears almost nowhere2. Enterprise applications is actually a sub-category of SP3, which is confusing.
In my experience, Service Principal is not a well understood term and I think this contributes to why.
In my opinion, the Portal experience for SPs is designed for the use case of 3rd party apps in your tenant, and most actions are around consenting to 3rd party apps. I think this explains some of the bad UX below.
Entra ID Portal search is inconsistent
Searching for an App/SP in the Portal is frustrating. You often will not be able to find the App/SP you want when using the Overview page’s “Search your tenant” feature.
This is because Microsoft does not use substring searches for Apps/SPs, which is not how the other directory object searches function.
Here is an example. I have an App+SP named: myUniqueApp and also a group named: myUniqueGroup
My group is found, but my App+SP are not. The reason for this is that the Graph API request for Apps+SPs uses a startswith(query) filter and the other objects use a substring filter on the display name (e.g. group name).
I have no idea why this is done and it is extremely annoying; it also leads people to incorrect conclusions, because they get a false negative result. They assume a substring search was done against all objects because other objects with this string in a substring position are returned.
Service Principal roles cannot be seen on Service Principal page
As mentioned above, SPs can have roles assigned to them (e.g. Helpdesk Administrator).
However, you cannot see roles assigned to a SP in the Portal. The reason why is…?? See an example below. My SP has Helpdesk Administrator, but you can only see that if you query an API4.
You may say, “Wait! why does it say your SP has Cloud Application Administrator and Reports Reader??”.
That is a great question! First, it does not say that! It says those roles can be assigned to “manage this resource”. It is not saying those roles are assigned to this object.
That is, of course, the opposite of what you would expect if you compare it to say…the User page, which uses the same icon and a similar title but does mean “roles assigned to this object”.
So unless you want to drop into a terminal session or enumerate through every AAD role in your tenant, you have no way to know what roles this SP is assigned!
Service Principal credentials cannot be seen in admin portal
In the screenshot above, you can also see that there is no panel option for certificates or secrets on the Service Principal object. In fact, there is nowhere in the UI to even suggest that it is possible for a SP to have credentials.
Even though SPs can have credentials, the only way to see them is via code (PowerShell, Graph API).
Most people do not know they can have their own credentials, because there is no way to see them in the most common admin interface: the Portal. When you combine that with the fact that Service Principals are, by default, excluded from Conditional Access Policies, it is a great persistence mechanism.
Microsoft does not publish a full list of First Party Apps
When you create a new Entra ID tenant, Microsoft automatically adds a lot (>600 as of this writing) of its own applications to your tenant. This is things you expect like Office 365 Exchange Online or Microsoft Teams. But also odd things like CCM TAGS and policy enforcer. This is done so that you don’t need to consent to every Microsoft service.
These apps are referred to as First Party apps, because they’re owned and controlled by Microsoft. There are some ways you can validate an app is First Party as described on this Microsoft page. However, there are two small, but important, disclaimers on that page: [emphasis mine]
The following table lists some, but not all, first-party Microsoft applications.
First-party Microsoft applications don’t always result in a service principal that’s created in your tenant. In this case, you’ll likely continue to see the applications in your sign-in reports.
This means that you could (and likely will) find a First Party app in your Microsoft logs that is not in Microsoft documentation and also does not appear in your admin Portal.
The only way to know it was put there by Microsoft is open a support ticket and ask.
First Party Apps have hidden permissions
When you query Microsoft applications via Graph API or the Portal you see they do not have configured permissions or API scopes. That is obviously confusing, since they must have permissions to something in order to work.
Eric Woodruff did excellent research on this here.
To summarize: not only can you not see First Party app permissions, some First Party apps had permissions that were much higher than you’d expect. Eric shows an example where the Device Registration Service Service Principal could add a user to the Global Administrator role. That privilege escalation issue is now fixed.
However, he also found, [emphasis mine]
Microsoft noted that it has other authorization mechanisms that exist behind the scenes for Microsoft applications. These mechanisms allowed us to perform the actions described in this article.
Microsoft rightfully highlighted that this capability is therefore not a material flaw within any of its authorization models. However, it acknowledged that externally, based on what we can view and have access to, the capabilities might appear to be in error. External to Microsoft, OAuth 2.0 scopes are absolute when interacting with Microsoft Graph, so without knowledge of other authorization systems, we can only infer.
This note from Microsoft is fascinating. They acknowledge customers have no visibility into what permissions Microsoft apps actually have internally and therefore we may make incorrect assumptions about what is or is not expected!
Basically, if it’s a Microsoft app, just practice zero trust. And by that I mean have zero trust in your instincts and trust that it’s meant to be.
Side note: Remember the time the US Government identified an intrusion at Microsoft because the government asked why an unknown app was suddenly showing up in their MailItemsAccessed events5?
Now imagine that analyst only saw that it was a Microsoft app and closed the incident as a false positive. Are we expected to ask Microsoft every time we see one of the >600 apps doing something odd? I have personally seen many Microsoft apps access mail, that don’t seem like they should access mail based on their name.
What should change?
First, Microsoft should improve the UI/UX experience for Apps/Service Principals. Most admins interact with their tenant in the Portal. Most discover what is available and possible through the Portal. Most people do not start learning a concept with code or even in the documentation. The Portal provides a structured picture of your tenant and it is therefore important that it reflects your actual tenant.
- It must be clear that Service Principals are their own first rate identity object and not just links to an App Registration.
- Expose SP roles and credentials in the Portal
- Fix the weirdly bad search experience
Second, they should provide a complete list of First Party apps, in one location, that customers may see in their tenants and a description of what the app is used for. I agree, it isn’t reasonable for us to understand all the internal auth, but when you see stuff like O365 Demeter you should have an idea what it is for. Sorry, but I don’t trust you. Also, set a better example for the kids.
Thanks for reading. Please send thoughts.
Footnotes
- Excellent Microsoft doc: https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals?tabs=browser ↩︎
- There are some tooltips that mention it. ↩︎
- https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals?tabs=browser#service-principal-object ↩︎
- The SP does appear under that Role when looking at the Helpdesk Administrator page, however, that is different in my opinion. ↩︎
- https://www.cisa.gov/sites/default/files/2023-07/aa23-193a_joint_csa_enhanced_monitoring_to_detect_apt_activity_targeting_outlook_online_2.pdf ↩︎
Leave a Reply