What’s going on inside the box? Is Service principal monitoring essential? If we rely on the SolarWinds event, then yes, this is necessary monitoring. The post will guide how to Monitor Service Principal with Azure Sentinel.
There are a few ways to monitor Service Principal access and changes. This post will provide some helpful information about the service principal and how to monitor with Azure Sentinel.
In general, we can distinguish between three types of AAD-integrated applications:

• Authored by Microsoft
• Authored by 3rd parties
• Written by users in our organization

Application registration is an application that must be registered with an Azure AD tenant. When you register your application with Azure AD, you create an identity configuration to integrate with Azure AD.
The application was registered. An Azure AD application is defined by its only application object, which resides in the Azure AD tenant. An application object is used as a template or blueprint to create one or more service principal objects.
A service principal is created in every tenant where the application is used. Like a class in object-oriented programming, the application object has static properties applied to all the developed service principles.
The application object describes three aspects of an application: how the Service can issue tokens to access the application, resources that the application might need to access, and the application’s actions.
The App registrations blade in the Azure portal is used to list and manage the application objects in your home tenant.
A service principal is a local representation, or application instance, of a global application object in a single tenant or directory. A service principal is a concrete instance created from the application object and inherits specific properties from that object.
A service principal is created in each tenant where the application is used and references the globally unique app object. The principal service object defines what the app can do in the specific tenant, access the app, and resources.
When an application is permitted to access resources in a tenant, a principal service object is created. You can also create principal service objects in a tenant using Azure PowerShell, Azure CLI, Microsoft Graph, the Azure portal, and other tools. When using the portal, a service principal is created automatically when you register an application.
The portal’s Enterprise applications blade is used to list and manage the service principles in a tenant.

The Real World

Now. Go to your Azure AD portal and take a look at your applications. How many applications do you have there? In a utopian world, you maintain an inventory of all these applications with an asset management database to know who the application is, what it is used for, and what API permissions are granted.
If you look at the Azure AD Sign-ins logs, you should view a report with Service principal sign-ins with all access and information such as time, status, IP address, and more.

The Enterprise applications blade is used to list and manage the service principles in a tenant. You can see the service principal’s permissions, user consented permissions, which users have done that consent, sign-in information, and more.

Most organizations are using non-interactive sign-ins, and there are some missing security controls for managed identities or and service principles comparing to user accounts because:

• No restriction of access by conditions
• Limited options of alternate authentication methods
• Every Service or scenario doesn’t support managed Identities in Azure.
• No sign-in log events to audit the authentication requests.

What changes? Recently Microsoft has allowed you to work with the AADServicePrincipalSignInLogs. That means you can enable and configure Azure Active Directory Logs for a service principal and work with log management.

Azure Sentinel Side

Now that we know we’ve all the capabilities for service principals logs, we can monitor, track and detect suspicious activities and many other Azure Sentinel actions.

Configure Azure AD

On Azure AD diagnostic settings, we need to enable and configure the collection of the following data:
NonInteractiveUserSignInLogs
ServicePrincipalSignInLogs
ManagedIdentitySignInLogs

Once the diagnostic logs are configured, we can check how it looks on the Azure Sentinel data schema. The new Data schema of the new sign-in logs
Even if there is no further documentation, the new sign-in logs’ data schema has already been documented in the Azure Monitor Logs reference.

• NonInteracticeUserSignInLogs > AADNonInteractiveUserSignInLogs
• ServicePrincipalSignInLogs > AADServicePrincipalSignInLogs
• ManagedIdentitySignInLogs > AADManagedIdentitySignInLogs

TIP: The name of the collection in the diagnostic settings and the table’s name are not equal.
Then we can run a quick and simple query to know what we’ve inside the AADManagedIdentitySignInLogs. From Azure Sentinel, run the following query.

Besides, I can run the query to find all Azure Activity logs related to a specific service principal with the following query:

AzureActivity | where Caller == “ae5673a4-8a82-XXXX-9b80-XXXXX” //Put your service principal here
| project TimeGenerated, Type, CorrelationId, OperationNameValue, ActivityStatusValue, Caller, CallerIpAddress, ResourceProviderValue

TIP: All Service Principal sign-ins are located in the “AADManagedIdentitySignInLogs” table.
We need to identify if someone access or touches a specific app with a particular ServicePrincipalName. The following query will return all the service principal sign-in information that does not originate from a known IP address.

AADServicePrincipalSignInLogs

| where ServicePrincipalName == “YourApp”

| extend countryOrRegion_ = tostring(parse_json(LocationDetails).countryOrRegion)

| extend state_ = tostring(parse_json(LocationDetails).state)

| extend city_ = tostring(parse_json(LocationDetails).city)

| project TimeGenerated, ServicePrincipalName, countryOrRegion_, state_, city_, IPAddress

| extend AccountCustomEntity = ServicePrincipalName

| extend IPCustomEntity = IPAddress

Now that we’ve got some logs and know which query to let’s put it all together on the Analytic rule. From Analytic Rule, we need to create a rule based on schedule Query, and from there, we need to add the following query, choose the severity, configure the collect time.

Once it’s configured, we can simulate to test the query and show how it looks like.

In summary, the analytic rule will be as the following example below.

Need more Azure Sentinel guides? Go to Azure Sentinel on Elli Shlomo Blog