Exploring Azure AD applications and service principals
In this blog, I will be moving on from Office 365 permissions to something broader: Azure AD. Azure AD is the directory service behind Office 365 and takes care of identity provisioning and authentication. Actually, this definition is not entirely correct. In fact, Office 365 is just one of the thousands of services/applications that use Azure AD as their identity platform. In this sense, you can almost think of Office 365 as just a (set of) service(s) built on top of Azure AD.
Anyway, I won’t try to explain what Azure AD (AAD) is or how it works now, instead this blog aims to alleviate some of the confusion around the concept of AAD-integrated applications. In general, we can distinguish between three types of AAD-integrated applications:
- Authored by Microsoft
- Authored by 3rd parties
- Authored by users in our own organization.
Let’s start with the latter.
Azure AD Application objects
The most common reason for integrating an application with Azure AD is that doing so will greatly simplify the authentication process. With (literally) a few lines of code, you can ensure that your application can be accessed by every user in your organization, without having to come up with a way to gather credentials, transport and store them securely in some database, and perform authentication. Instead, users can simply use their Azure AD (Office 365) credentials, or even their on-premises credentials (depending on the authentication method configured for the tenant). You can also take advantage of a horde of security-related features such as Conditional Access or Multi-factor authentication. Not only that, you can also extend this process to users in other organizations, as well as “consumer” IDs.
In other words, Azure AD makes things easy for the developers, while ensuring a high level of security and trust. In addition to all that, integrating an application with Azure AD allows you to control access to different resources on behalf of the logged-in user. The authentication aspects are handled by the OpenID Connect protocol, while authorization is handled via OAuth 2.0. Additional information about those protocols can be found for example in this article.
In order for the application to be able to take advantage of all the cool capabilities offered by Azure AD, it must first be “registered” by some user in their Azure AD tenant. The process takes just few clicks in the Azure AD portal or a single line of PowerShell code – so technically you can create a new app registration in less than a minute. Registering a real-life application, however, will require some understanding of the OAuth concepts such as consent and permissions scopes, which go beyond the intention of the current article. You can get additional information on the application registration process in this article.
For our purposes, it’s only important to understand what happens when you register an application in Azure AD. Namely, two objects are created in the Azure AD instance. The first one, the application object, serves as a unique, global representation of the application and its properties.
In addition, a second object is created: a service principal object. This is basically a security principal (object used to delegate permissions) that defines the set of permissions that the application object will get in the current Azure AD instance. Which brings us to the next section.
Azure AD Service principals
The screenshot below shows the properties of the service principal object corresponding to the EWSHax application we viewed in the previous section. In addition, the permissions granted on the application have been shown by executing the Get-AzureADServicePrincipalOAuth2PermissionGrant cmdlet.
Note the correspondence between the properties of the two objects, in particular the values for the AppId, DisplayName and ReplyUrls. While some of these properties will accept any value, the AppId is unique across all of Azure AD, which indeed confirms the relationship between the application object and the service principal object. And this is where things get interesting.
While a single application object exists for every Azure AD integrated app, the relationship with the service principal object is one-to-many. Basically, the service principal represents the application across every tenant that uses it.
That representation is what enables applications to be accessed across tenants or the Software-as-a-Service model in Azure AD. The service principal object can only be created after a consent is given to said application, be it user or admin-level consent depending on the tenant configuration and the permissions the application will require. Once created, the service principal object will derive its properties from the “parent” application object in the “home” tenant, however any changes you make later on will not be automatically reflected. That is to say, you can’t simply create an innocent-looking application that doesn’t require any permissions at all, and then change it later on to have full access to users’ data – any permission changes will only be reflected after the service principal object is removed, and the application is consented to anew.
In effect, we have now introduced the concept of a multi-tenant application – an application that can have representation across multiple tenants. Our Office 365 reporting solution is one such example.
In fact, all of the “built-in” Office 365 applications are such examples, although not all of them are exposed in the endpoints that we, as customers, have access to. But just as any other application, Microsoft’s applications have their own service principal objects residing in our Azure AD instances. You can see those from the Azure AD blade (limited to the first 50 entries) or via the following PowerShell query:
Get-AzureADServicePrincipal -All:$true | ? {-not $_.Tags -eq “WindowsAzureActiveDirectoryIntegratedApp”}
A staggering 182 applications like these can currently be seen in my tenant, and even more exist behind the scenes. If you only want to see service principal corresponding to third-party applications that are integrated with your Azure AD instance, and not the default Microsoft ones, you can use the below, where we have added the ‘Homepage’ property, which is mandatory for any third-part multi-tenant application.
Get-AzureADServicePrincipal -All:$true | ? {$_.Tags -eq “WindowsAzureActiveDirectoryIntegratedApp”} | select AppId,DisplayName,Homepage
Any and all third-party applications that you have added to your Azure AD instance should be visible!
Reporting on Azure AD Applications
Now that we hopefully have a better understanding of what Azure AD applications are, let’s also talk about why it’s important to keep an eye on them. As seen from above, integrating an application with Azure AD can expose some of the user details, by means of allowing the application to leverage Azure AD for authenticating your users. What’s more important, some of the applications might request permissions to access any of the web APIs available within the service, and gain access to data such as email or files. While this should never happen without explicit user/admin consent, we have already seen some “rogue” applications out there, so one should educate the users to pay attention to the consent prompts, or even configure some policies to exercise control over Azure AD apps.
When it comes to reporting on Azure AD integrated applications, the Azure AD portal or PowerShell cmdlets expose all the information you need, including which users have consented to applications and what kind of permissions the application has been granted. If you want a dashboard, that’s easier on the eyes, and curated to only display third-party applications and their permissions, this is available as part of the Cloud App Security suite, however the only additional piece of information you can get from it is some vague information about how often the app is used across all the different companies that have purchased CAS. In other words, unless you are using some of the other functionalities CAS offers, the price of the feature is way too prohibitive to just get this additional insight.