A Practical Approach to Monitoring the Entra Provisioning Service

Reading Time: 3 minutes

Microsoft Entra

Organizations who choose to leverage Entra's identity governance and administration (IGA) capabilities – in stead of the more mainstream SailPoint and Saviynt solutions, but perhaps as a logical successor to Microsoft Identity Manager – may notice that the Entra Provisioning Service lacks a service level agreement (SLA) and is missing from Microsoft's Status dashboard. As this service is the cornerstone to these IGA implementations, being aware of its non-availability is key.

 

About the Entra Provisioning Service

The Entra Provisioning Service offers automatic provisioning and deprovisioning for user objects and roles in Entra applications. This way, it supports these Joiner, Mover and Leaver (JML) flows using System for Cross-Domain Identity Management (SCIM) 2.0. When an application is configured for on-premises provisioning, the Entra Provisioning Service works together with the Entra Provisioning Agent to have SCIM 2.0 packets delivered to the SCIM 2.0 endpoints of on-premises applications.

 

About the Entra SLA

The Service Level Agreements (SLA) documents describe Microsoft’s commitments for uptime and connectivity for Microsoft Online Services. The agreement covers Microsoft Entra. However, its 99,99% availability currently only applies to times when users are unable to log in to the Microsoft Entra ID service, or Microsoft Entra ID fails to successfully emit the authentication and authorization tokens required for users to log into applications connected to the service. Basically, its scope is authentication and token issuance. Azure AD B2C and Entra Domain Services also have SLAs, but the Entra Provisioning Service falls squarely out of scope. Its SLA is non-existent.

 

About the Azure Status dashboard

Microsoft's Status dashboard provides an overview of the availability of Microsoft services per geographical region. It features Identity services, like Entra ID, Azure AD B2C, Azure AD Domain Services, Global Secure Access and Multi-Factor Authentication, but lacks a status for the Entra Provisioning Service.

 

The challenge with monitoring the Entra Provisioning Service

Based on the above information, Microsoft does not provide any guarantees or insights around the availability of the Entra Provisioning Service. It makes it chellenging for organizations to adopt the functionality as it may constitute a liability in an organization's information security operations.

When confronted with this challenge at a customer, I devised a way to monitor the availability of the Entra Provisioning Service in an end to end way as this organization utilizes the Entra Provisioning Agent and Azure API Management, too. Now, your organization can use this solution, too.

 

An overview for monitoring

One of the key metrics for the Entra Provisioning Service is that its provisioning cycles run every 40 minutes.

The solution consists of seven building blocks:

  1. An email address for the team responsible for the JML process towards SCIM 2.0-capable applications
  2. A security group in Entra that is exclusively used as the scoping mechanism for monitoring
  3. An Enterprise application in Entra configured for on-premises provisioning. This app is exclusively for monitoring purposes and does not constitute an actual on-premises application, but does (optionally) communicate to a SCIM 2.0 endpoint on the Azure API Management instance. This application should be scoped to the aforementioned security group
  4. The email address configured in the Settings for the monitoring enterprise application to receive notifications and to receive alerts on errors
  5. An Azure function that changes the group membership every 30 minutes for a single monitoring user object for a security group in Entra that is in scope for provisioning to the aforementioned Enterprise application
  6. An Azure function that monitors the Entra Provisioning logs through the Graph API, scoped to the aforementioned Enterprise application, every 20 minutes and sends a notification to the email address when there is no log activity for the past 125 minutes
  7. (optionally) A monitoring rule in Azure API Management on the monitoring endpoint that sends a notification when there is no activity for the past 125 minutes

leave your comment

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