Editor's Note: This blog post is a result of the collaboration between ServiceNow and Azure AD teams. Specifically, Ramiro Calderon, Principal Program Manager – Microsoft Identity Division, has authored and validated the most of the content below, for which ServiceNow Innovation team sincerely thanks him.
Problem Description
A great number of world-class enterprises have standardized on Azure Active Directory as their identity management solution, and ServiceNow as their ITSM platform of choice. Generally, the systems work well together: ServiceNow solution is the most commonly used partner service for Azure AD, as mentioned in this recent blog post. Once configured to work together, joint customers can seamlessly login into ServiceNow using their Azure AD credentials. This enables customers to work from virtually anywhere with access to the Internet, since both Azure AD and ServiceNow are cloud-based services. This ability to carry on work from anywhere has been critical for enterprise to continue operating without interruption in the face of unprecedented challenges that 2020 has brought.
But what if the systems provided the integration beyond just SSO? What if you could receive, respond to, and resolve Azure AD events and activities inside ServiceNow? For example, what if ServiceNow could properly alert enterprise IT of unexpected activity in the Azure AD tenant?
In this blog, we’ll describe the technical details of integrating Azure AD with ServiceNow to allow IT to properly triage activity of privileged accounts in Azure AD and report these events into ServiceNow. In subsequent blogs, we’ll explore the use of ServiceNow SecOps offering for broader security and identity incidents response.
Solution Overview
The integration between Azure AD and Service Now Event Management is outlined in the diagram below:
There are four components of the solution, all of which are likely already present at enterprises who use ServiceNow, Azure and Azure AD together.
- Azure Active Directory (Azure AD): obviously, the integration is only valuable if an enterprise has standardized on Azure Active Directory as their identity management system of choice.
- Azure Monitor is a comprehensive solution for collecting telemetry from your cloud and on-premises environments. The Azure Monitor integration with Event Management is used in this solution to create an alert in Azure and route this alert, using an secure webhook action, to customers’ ServiceNow instances.
- Event Management Connector App receives the alert from the Azure Monitor and creates an Event record inside ServiceNow. This app is available on ServiceNow store and provides a “Secure Webhook Action” mechanism that could be reused throughout Microsoft Azure estate. Note that this app has a dependency on ServiceNow ITOM Health with Event Management.
- ServiceNow ITOM Health with Event Management uses Artificial Intelligence for IT Operations (AIOps) to intelligently process events generated by IT infrastructure, including Azure AD, at scale.
Configuration of the Solution
To enable the integration, the environment needs to be configured following the steps below. Check out the appendix at the end of the post for screenshots of each step.
|
Step |
Configuration Task (click the link for screenshots) |
Link to product documentation |
|
In Azure AD | ||
|
1 |
Azure AD logs (sign-in activity, provisioning, and audits) flow to an Azure Log Analytics Workspace. Screenshot | |
|
2 |
Create an app registration object that represents the secure webhook hosted by ServiceNow event management. Screenshot | |
|
3 |
Set an app registration created in step 2 to use Azure AD v2 Access Tokens. Screenshot |
Understanding the Azure Active Directory app manifest - accessTokenAcceptedVersion attribute |
|
In Azure Monitor | ||
|
4 |
Create an Alert rule that triggers based on Azure AD log queries. Screenshot | |
|
5 |
Add an action group to the alert rule that calls a webhook hosted by ServiceNow, and map it to the app registration created in step 2. Screenshot | |
|
In ServiceNow | ||
|
6 |
Validate that Event Management is installed in your instance from the ServiceNow store | |
|
7 |
Configure the “Azure OAuth OIDC Entity” to point to the app registration created in step 2. Screenshot | |
|
8 |
Configure the “Azure OIDC Provider Configuration” with the Azure AD OIDC Metadata URL. Screenshot | |
|
9 |
Create a user in the sys_users to link the “Azure OAUth OIDC” entity to a logical user in ServiceNow. Screenshot | |
|
10 |
Update ServiceNow user created in step 8 to have the “evt_mgmt_integration” role. Screenshot | |
Data Flow of the solution
After the environment is configured, the data flows as follows:
- Azure AD Logs get populated per the activity in the tenant
- The log information flows to the Azure Log Analytics workspace
- A background job from Azure Monitor executes the log query based on the configuration of the Alert Rules in the configuration step (4) above.
- If the result of the query matches the alert logic (e.g. number of results or a measurement greater than the value), then the action group kicks in. Let’s assume that it kicked in, so the flow continues in steps 5 and below.
- The Azure Monitor background job requests an access token to Azure AD with an audience to the API defined in the configuration step (2) above
- The Azure Monitor sends an HTTP POST request to the webhook URL configured in the action group with the alert payload, with the access token acquired in step 5a.
- The endpoint listener in ServiceNow receives the HTTP Request and validates the access token based on the configuration steps (6)-(9)
- Validates that the token is signed with the keys obtained from the OIDC metadata endpoint
- Validates that the audience of the token (in the ‘aud’ claim) has the API identifier
- Validates that the ‘azp’ claim has the identifier of the well-known Azure Monitor background task
- If validation succeeds, then the alert payload is ingested by ServiceNow Event Management
Putting things together…
Now that you know how the solution works, you can create alert rules for various log queries depending on your requirements. Below are some sample queries that you can use for privileged access. Check out more samples in our GitHub repository:
Scenario 1: Detecting Azure AD Role Assignments outside PIM
If you have Azure AD Premium P2 licenses you can (and should ????) use Privileged Identity Management for all administrators. The following query reports any permanent assignment to global administrators:
let PIMSPObjectId = "e37f1832-6370-4145-b145-82197758790f"; //Customize this in your tenant with (Get-AzureADServicePrincipal -Filter "appId eq '01fc33a7-78ba-4d2f-a4b7-768e336e890e'").ObjectId
AuditLogs
| where Category == "RoleManagement"
| extend PropertiesJSON = parse_json(TargetResources)
| extend initiatedByJSON = parse_json(InitiatedBy)
| extend role = PropertiesJSON[0].modifiedProperties[1]['newValue']
| extend UPN = PropertiesJSON[0].userPrincipalName
| extend InitiatedByAppDisplayName = initiatedByJSON.app.displayName
| extend InitiatedByAppSPID = initiatedByJSON.app.servicePrincipalId
| extend InitiatedByUserDisplayName = initiatedByJSON.user.displayName
| extend InitiatedByUserUPN = initiatedByJSON.user.userPrincipalName
| extend InitiatedByUserID = initiatedByJSON.user.id
| where role == '"Company Administrator"' //You can add more roles here
| where InitiatedByAppSPID != PIMSPObjectId
| project TimeGenerated,CorrelationId,Identity,role, OperationName,UPN,InitiatedByAppDisplayName,InitiatedByAppSPID,InitiatedByUserDisplayName,InitiatedByUserUPN,InitiatedByUserID Scenario 2: Detecting Activity on Emergency Access Accounts
It is recommended to configure Emergency Access Accounts to manage exceptional situations such as accidental lockout. This accounts are very sensitive and any activity or sign in should be monitored. To monitor audits you can use the query below:
/replace the GUIDs below with the objectIds of the emergency access accounts
let monitoredAccounts = datatable(objectId:string)
[
"37b7abaf-a503-4611-9594-2edab360af74",
"c361e023-93e2-4998-ae46-3956c42bdce6"
];
AuditLogs
| extend initiatedByJSON = parse_json(InitiatedBy)
| where (
initiatedByJSON.user.id in (monitoredAccounts) or
TargetResources has_any (monitoredAccounts)
)To monitor sign in activity, you can use this one:
/replace the GUIDs below with the objectIds of the emergency access accounts
let monitoredAccounts = datatable(objectId:string)
[
"37b7abaf-a503-4611-9594-2edab360af74",
"c361e023-93e2-4998-ae46-3956c42bdce6"
];
SigninLogs
| where (
UserId in (monitoredAccounts)
)Wrap-Up
Hopefully, this gives you an idea of what you can do with this integration. Let us know what other scenarios would you like to see and we will add them to our GitHub repository and follow up posts!
Appendix: Configuration Walkthrough
Step 1: In Azure Portal, enable Azure AD Logs to flow through to the Log Analytics workspace
Step 2: Create an Azure AD App Registration in Azure Portal and note the critical values highlighted below
Step 3: Configure your Azure AD App to use v2 of Access Tokens
Step 5: Create an Action Group
Step 7: Inside ServiceNow, configure OAuth OIDC Entity with the Client ID of the Azure AD App you created
Step 8: Inside ServiceNow, set proper OIDC Metadata URL in the OIDC Provider Configuration record and make sure that the JWT Claim Validation Value is set to 461e8683-5575-4561-ac7f-899cc907d62a
Step 9: Make sure to enclose the value of the App ID inside square brackets since we forced our Azure AD to use v2 tokens
Step 10: Assign an evt_mgmt_integration role to the user
