Azure AD applications and service principals

For this article, we will switch gears from the usual topic of Office 365 permissions to something broader in scope, namely 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 think of Office 365 as just a (set of) service(s) built on top of Azure AD.

Anyway, this article will not try to explain what Azure AD (AAD) is and how it works. Instead, it aims to alleviate some of the confusion around the concept of AAD-integrated applications. In general, we can distinguish between several types of such applications: authored by Microsoft, authored by 3rd parties and 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. Literally with a few lines of code, you can ensure that your application can be accessed by every user in your organization, without you 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. Moreover, you can also take advantage of a horde of security-related features such as Conditional Access or Multi-factor authentication. And, you can extent 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 just 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. Here’s an example one as viewed via the Azure AD PowerShell module:

PowerShell example of a service principal

In addition, a second object is created, namely 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 means of executing the Get-AzureADServicePrincipalOAuth2PermissionGrant cmdlet:

PowerShell example of service principal

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 cannot 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 multi-tenant application – application that can have representation across multiple tenants. The Radar (Cogmotive) reports application is such one example, shown on the screenshot below, as is the Discover & Audit offering:

PowerShell example

In fact, all of the “built-in” Office 365 applications are such examples, although not all of them are exposed in the endpoints 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):

Azure AD blade

Or via the following PowerShell query:

Get-AzureADServicePrincipal -All:$true | ? {-not $_.Tags -eq "WindowsAzureActiveDirectoryIntegratedApp"}

A staggering number of 182 such applications 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:

Get-AzureADServicePrincipal -All:$true | ? {$_.Tags -eq "WindowsAzureActiveDirectoryIntegratedApp"} | select AppId,DisplayName,Homepage

where we have added the Homepage property, which is mandatory for any third-part multi-tenant application. 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. A better-looking dashboard, curated to only display third-party applications and their permissions can also be found as part of the Cloud App Security suite, however the only additional piece of information you can get from it is some vague information as to 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.

Instead, you can simply generate the same set of report via PowerShell, and we have already published a sample script few months back. In addition to simply monitoring app usage, you might consider creating some alerts that detect any newly added applications, as well as imposing restrictions as to who can consent to applications and which users in the organization can register new Azure AD integrated apps. Unless you want to run into some unpleasant surprises down the road 🙂

2 thoughts on “Azure AD applications and service principals

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.