Microsoft Entra Workload ID - Lifecycle Management and Operational Monitoring

This blog post is part of a series about Microsoft Entra Workload ID:

• Introduction and Delegated Permissions
• Lifecycle Management and Operational Monitoring
• Threat detection with Microsoft Defender XDR and Sentinel
• Advanced Detection and Enrichment (coming soon)
• Incident Response (coming soon)

Inventory and initial review of Service Principals

I would recommend having a initial review for full visibility and insights of the service principals which has been already created, especially in an environment without an establish lifecycle workflow or governance framework.

Julian Hayward has published an awesome tool with the name “AzADServicePrincipalInsights” (AzADSPI) which allows you to create a report across all types of workload identities. This can be also used for regular reviews and integrated to your monitoring and review process.

The report covers analysis about owner, credentials, app and directory role assignments of Application and Service Principal objects (all different types).

AzADSPI provides a comprehensive report of application and service principal objects in your Entra ID environment

There are many questions you should try to answer by analyzing the report, for example:

• Who has ownership to application and service principals?
  • Do you have user accounts as owners to objects with critical (classified) permissions (such as User.ReadWrite.All) or directory role assignments?
• Which objects are owned by a service principal?
• Are you aware of the existing user-assigned identities in Azure and the resources which can to use them?
• Do you trust the Identity Providers and entities which are defined in Federated Identity Credentials?
• Are there orphaned Managed Identities?
• …

Results can be exported as HTML (with visualization) but also as JSON and CSV export. Julian is also providing pre-configured pipeline files for Azure DevOps and GitHub which allows to export the report data to a repository automatically. The approach is similar what I have built with AADOps for Conditional Access.

Pull Request in AzADSPI to compare changes of Workload Identity since latest pipeline run. In this example, a sensitive API permission and a short term client secret has been assigned.

The tool provides an classification for API Permission with critical and medium sensitivity which can be also customized.

Side Note: Options to integrate such enriched data to your Microsoft Sentinel environment (for example to build advanced logic or correlation in analytics rules) will be one of the major topics in the next part of this blog post series. I’ve shown this approach in scenarios for enrichment of analytics rules and hunting in my community talks about Workload Identities in the recent years. Last year, I’ve started to work on an automation for classification of privileged access based on Microsoft’s Enterprise Access Model. This feature will be part of my “AADOps” PoC project and covers all major RBAC systems in Microsoft Cloud (Azure, Entra ID, Intune, Graph API, Identity Governance) across all types of identities (including workload identities). But this is topic for another community talks and blog posts in the near future.

Tip: There’s is also a tool by Joosua Santasalo which gives you comprehensive insights to your application and workload identities with option to ingest the data to Log Analytics.

Lifecycle Management of Application Objects

In the following section, I would like to evoke simply the keypoints (including a short description) what should be considered in lifecycle management from my point of view.

Overview on tasks during the lifecycle phases of application objects (as an example)

Planning and Provisioning

Check requirements on application-level integration

• Verify the integration of MSAL or any other authentication library which passed the following security requirements:
  • Verify claims-based authorization (logic must check security identifiers including tenant and object id)
  • Support for latest features in protocol standards and Entra ID features, such as Conditional Access Evaluation for workload or application identities
• Check if the app publisher offers a publisher verification

Create a well-configured app registration

• Choose multi-tenant only if acceptable and consider limited security control with Conditional Access and User Assignment requirements. Those settings will be applied in the tenant of the Service Principal instance. Policies from the „home“ tenant of the app registration will not apply to users in other („resource“) tenants. In addition, you will have no sign-in events from those users.

  Tip: Merill Fernando has written a great blog post about “Entra ID multi- vs. single tenant app” which I can strongly recommended to read.

  • Consider to enable “Application instance lock” to protect sensitive properties of the multi-tenant app in other tenants.
• Follow Microsoft’s best practices for application configuration which covers security related aspects of Redirect URIs, authentication flow, Application and secret management.
  • Integration assistant in Entra ID portal should also support you in verifying the recommended configuration and go trough a checklist.
• Consider best practices in developing Zero Trust applications, especially token management (claims, lifetime, caching) are core aspects for app integration.
  • Avoid using weak claims (such as e-mail or UPN) to determine if the token subject is authorized. Validate the subject by using immutable claim values.
• Review and remove ownership to application and service principal objects. If needed, delegate permissions with object-scoped and least privileged directory roles (as already described in the first part of the blog post series). Consider using PIM approval flow for sensitive delegated permissions on application object (such as update credentials or change reply URLs) to implement four eyes principle and closely review all activities from eligible admin.
• Optional: Define a notificationEmailAddresses in the Service Principal object if you are implementing a SAML token-based application and you want deliver notification for certificate expiration.
• Optional: Use serviceManagementReference if you can build a link between application and service or asset by using a management ID (information will be visible for other users).

Classification and Service Mapping of Service Principals

• Classify policy requirements for user access to the application as custom security attribute. This could include attributes related to the target audience of the app or the policy requirements to access the application:

  

  The assignment of the custom security attribute allows you to use the classification in the App Filter for Conditional Access Targeting:

  

  Require trusted device and block access from BYOD to all classified sensitive business apps (based on classification in custom security attribute)

• Classify application permissions of the Service Principal (e.g. sensitive Graph API Permissions) to protect them by Conditional Access for Workload Identities. I’ve started to create a classification definition for Microsoft Graph API based on the Enterprise Access Model which will be applied by an automation (as part of my PoC project “EntraOps”):

  

  Workbook of EntraOps Privileged EAM helps to identify highly sensitive workload identities and their privileges in Azure, Entra and to Resource Apps. API permission to “User.ReadWrite.All” will be classified to “Control plane” (Tier 0) because of the wide range of permissions to modify user accounts. The identified sensitive service principals needs to be protected and monitored particularly.

  

  

  Custom security attributes will be used to “label” classification and target them in policy (for example, all control plane access should be blocked if Identity Protection has detected a high risk of the workload identity.

• Require user assignment for sensitive or restricted applications to the target end-user audience. This setting is also important if an application identity has sensitive delegated permission and you want to manage the scope of users.

  

  Groups can be used to assign permissions to get access to those apps or APIs. In addition, Identity Governance offers an effective way to request, manage and review user access to applications.

  

  Access to Graph Explorer and Microsoft Graph PowerShell is restricted and will be granted with access package for privileged role assignments

• Use a custom security attribute or notes attribute to store information about service owner or application developer. I would prefer to choose a custom security attribute to keep the relation private to avoid discovery and reconnaissance by attackers.

  • Other entity relations should be also stored in custom security attributes which could be later used in Microsoft Sentinel (WatchLists) for building correlations in analytics rules, hunting queries or scoping „Conditional Access for Workload Identities“. For example: Details about hosting or running the workload (pipeline name, environment or relation other cloud resources/accounts) and classification of permissions (according to own-defined sensitivity levels or tiering model):

    

    A service principal which will be used in Azure Pipelines for sensitive operations (in this case, Entra ID automation) offers information about the classification and details on the associated pipelines in the custom security attributes.

Issuing credentials

• Client Secret (only if other credential types are not supported): Use KeyVault to transfer and provide secret to the workload. Avoid long lifetimes by implementing a process and way to rotate the secrets regularly. Configure a secret expiration date to take advantage of notification trigger.

  There are some great blog posts by the community about client secret rotation. Check out the following articles and samples:

  • Azure AD application secret rotator for Azure web sites
  • How to automatically rotate Entra ID app registration client secrets using Azure Functions (with Java) and Key Vault – Jordan Bean Dev Blog
  • Implement automatic key rotation on Azure DevOps service connections by Koos Goossens
• Certificate: Use KeyVault or your trusted Certificate Authority of choice to create the private key and avoid delegating any permissions or options to export the sensitive cryptographic information. Only the public key needs to be imported to the associated app registration.
  • Choose the “new” RBAC permission model (over the classic “Vault Access Policy” permission model) to use Azure PIM and Azure Activity Logs for privileged access governance.
  • Implement a renewal process for certificates as already described in the scenario with client secrets.

  Side Note: Applications can also roll their own existing keys. More details about how to implement it and the usage of Application.ReadWrite.OwnedBy is very well described in a the blog post “Using Application.ReadWrite.OwnedBy and addKey methods for Graph API” by Joosua Santasalo.

• Federated Credentials: This credential type offers many benefits over secrets or certificates from security and operational perspective. Choose this credential type if your workload scenario is supported. A subject identifier should be chosen with a strong scope on your workload and a reliable and secure external Identity Provider (IdP) for establishing a trust relationship.

Restrict application (credential) management

App Instance Property Lock

Microsoft allows to lock properties of the “Service Principal” object for Multi-Tenant Apps. This prevents admins or owners of the object in the Resource Tenant from adding credentials and impersonate the application identity. This feature is in preview and well documented in Microsoft Learn.

App Instance property lock can be configured in the “Authentication” blade of the App Registration

Entra ID App Management Method Policies

Client Secret and Certificate management operations can be restricted for Application and Service Principals by using App Management Policies. This feature can be only configured by using Microsoft Graph and is limited to tenants with assigned Workload Identity Premium licenses.

A tenant-wide policy (tenantAppManagementPolicy) can be created which applies to all apps and service principals. It’s possible to define a policy which blocks new password credentials beginning from a specific date. The properties of the policy object and schema are described in the related resource type docs.

{
    "isEnabled": true,
    "applicationRestrictions": {
        "passwordCredentials": [
            {
                "restrictionType": "passwordLifetime",
                "maxLifetime": "P90D",
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            },
            {
                "restrictionType": "symmetricKeyAddition",
                "maxLifetime": null,
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            },
            {
                "restrictionType": "customPasswordAddition",
                "maxLifetime": null,
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            },
            {
                "restrictionType": "symmetricKeyLifetime",
                "maxLifetime": "P40D",
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            }
        ],
        "keyCredentials": [
            {
                "restrictionType": "asymmetricKeyLifetime",
                "maxLifetime": "P365D",
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            }
        ]
    }
}

Application Management policies (appManagementPolicy) can be created to have specific restrictions for certain application identities and can be linked to individual application or service principal objects. These policies will override the restrictions (by the tenant-wide policy) in scope of the linked object. Details on create, modify and link App Management policies are also described in the Microsoft Graph Docs.

Side Note: Vasil Michev has published a great blog post about this topic with the title “Entra ID App Management Method Policies Harden Application Security Posture” on Practical365.com.

Azure Policies for Workload Identity Federation

As far as I know, there are no options to restrict federated credentials on Application objects in Entra ID. But there is a solution if you are using user-assigned managed identities in combination with Federated Credentials. Azure Policies are the central policy engine at the level of Azure Resource Manager (ARM) as control and management plane. Uday Hegde has written an excellent blog post how to create and apply a policy to restrict federation with an approved set of issuers.

Operational Monitoring and Maintenance

There are a couple of sources and signals in Microsoft Entra products but also governance capabilities in Microsoft 365 Defender which should be included in the operational monitoring.

Entra ID Recommendations on Workload Identities

The following checks are included in the recommendations blade and are available in Entra ID P2 tenants:

• Remove unused applications (Microsoft.Identity.IAM.Insights.StaleApps)
• Remove unused credentials from applications (Microsoft.Identity.IAM.Insights.StaleAppCreds)
• Renew expiring application credentials (Microsoft.Identity.IAM.Insights.ApplicationCredentialExpiry)
• Renew expiring service principal credentials (Microsoft.Identity.IAM.Insights.ServicePrincipalKeyExpiry)

You’ll find the overview of recommendations in the Entra ID portal and as deep link in the “Workload Identities” blade from the Microsoft Entra portal:

Overview of Workload Identities in the Microsoft Entra portal

Recommendations covers a few checks for app registrations/service principals including unused permissions and credentials.

Details on impacted resources and remediation steps are available for every recommendation. Status will be automatically updated if the application or service principals have been modified according to the action plan. You can also change the status manually (active, dismissed or postponed).

All recommendations can be listed and updated (incl. status and owner) by Microsoft Graph API. This allows you to implement the insights to your existing operational monitoring or dashboard solution.

Using a filter on ImpactType give us the option to get only findings regarding resource types “Applications” which also includes Service Principals:

https://graph.microsoft.com/beta/directory/recommendations?$filter=impactType eq 'apps'

Programmatically access to the recommendation by using Microsoft Graph API by using Graph Explorer

As you can see in the previous screenshot, the impacted resources are missing. Another API call allows to get a list of the related entities. But you need to include the full ID of the recommendation, including the specific “Tenant Id” and “Resource Name” of the recommendation:

https://graph.microsoft.com/beta/directory/recommendations/<TenantId>_Microsoft.Identity.IAM.Insights.ApplicationCredentialExpiry/impactedResources

Details on the impacted resource (service principal or application) from the recommendation.

Usage & Insights about sign-in activities and credentials

Entra ID provides integrated activity reports in the “Usage & Insights” blade. Furthermore, the results of these reports are also accessible from Microsoft Graph API and can be integrated in your monitoring solution. The following activity reports are particularly related to workload identities.

Service principal sign-in activity

Last sign-ins (with Time Stamp and Request Id) from app-only (application permissions) or user access (delegated permissions) will be covered in the report. lastSignInRequestId can be used for searching the related user or service principal sign-in in the Entra ID sign-logs.

https://graph.microsoft.com/beta/reports/servicePrincipalSignInActivities

Entra ID application activity

This report shows a summary of all users’ sign-in attempts to an application including error codes.

Report displays the error description of the sign-in failures and counts and timeline of all user sign-ins

The API endpoint “applicationSignInSummary” allows to get a summary with counts on successful/failed sign-ins and success percentage filtered by a pre-defined period of time.

https://graph.microsoft.com/beta/reports/getAzureADApplicationSignInSummary(period='D7')

Summary of application sign-in report within the last 30 days (maximum time range).

Another API call to “applicationSignInDetailedSummary” is needed if you are interested to get all details about the sign-in counts and failures:

https://graph.microsoft.com/beta/reports/applicationSignInDetailedSummary

The response shows the single records of the report which will be aggregated regularly and includes additional details about the failureReason .

Application credential activity

Monitoring to expiring of client secrets and certificates is one of the essential operational tasks during the maintenance phase of application and workload identities. The following reports give a detailed overview of expiring credentials.

The Portal UI allows you to filter for the expiration time window, certificate types and recent sign-in activities. This feature is in preview and I’ve running into some issues with outdated data and filter.

All details of the report can be also listed by using the following Graph API call:

https://graph.microsoft.com/beta/reports/appCredentialSignInActivities

Credential activity report covers not only expiration of specific credentials, but it’s also shows the latest sign-in activity. Unfortunately, there are some issues with the quality of data, as you can see in the screenshot (example: lastSignInDateTime)

Entra ID Workbooks and Alerts for advanced operational monitoring

Sign-in of users (SigninLogs and NonInteractiveUserSignInLogs) but also service principals (ServicePrincipalSignInLogs) are covered by Entra ID and can be forwarded to a Log Analytics or Microsoft Sentinel workspace by using Diagnostic settings.

The following examples should give you an overview about the capabilities and options to use this data to visualize insights about your integrated apps.

App sign-in health

This is an integrated workbook from the Entra ID monitoring blade and visualizes the numbers of successful sign-ins and failures (like previous described Usage & Insights report “Application Activity”). But it offers longer time ranges (based on your workspace data retention), customized views and an overall status.

Tip: Error Codes will be only displayed in some scenarios of troubleshooting sign-in issues. Check out the references of AADSTS error codes but also the integrated lookup tool for resolving the code numbers.

Analyses of used Authentication Library

I’ve built a KQL query which is parsing the information about the implemented Authentication Library from the AADServicePrincipalSignInLogs sign-in logs.

This should help to identify outdated versions from Microsoft Authentication Library (MSAL) or legacy libraries (e.g., ADAL):

In my opinion, you should use the latest version to avoid security vulnerabilities, known issues with core features (such as token caching) and missing features (e.g., support for CAE). The query can be also used for visualization as you can see in the following sample:

Side Note: Recently, Microsoft has announced a check in “Entra ID Recommendation” for identifying ADAL Applications. Keep this in mind, if you are looking for implementations of this deprecated Authentication Library.

Issued CAE token

Continuous access evaluation (CAE) is also available for workload identities. But how to detect which non-human identity or session is using a CAE-capable token?

You can get insights about this one in the Entra ID sign-in blade by filtering on “Is CAE token” and check the “Additional Details” tab:

Unfortunately, the details if CAE token has been issued are not available in the Diagnostic Logs of AADServicePrincipalSignInLogs yet.

Governance of OAuth Apps and Permissions

Microsoft has been released “App Governance” as add-on feature for “Microsoft Cloud App Security” (now called “Microsoft Defender for Cloud Apps”) in Summer 2021. An additional licensing was required but this will be change for Microsoft 365 E5 and E5 Security customers on June 1st, 2023. The feature will be available as opt-in at no additional costs.

This tool gives you an comprehensive overview and insights about your applications in different areas (data and permission usage, access to sensitive data or delegated access by sensitive accounts).

“App Governance” is fully integrated to “Microsoft 365 Defender” portal and shows many compliance & security related insights.

Summary of applications gives you an overview about certification and publisher verification which should be important to review for multi-tenant and SaaS applications. But also, deep links to related “Entra ID recommendations” have been integrated.

Policy templates but also custom policies can be configured for monitoring and detection of different scenarios. Alerts for “unused apps”, “unused credentials” or “expiring credentials” are available as well. So, there are some overlapping features between Entra ID recommendations and App Governance. Therefore, app hygiene features will be only available in MDA for customers with Entra Workload ID Premium license.

Alert integration to Microsoft 365 Defender/Microsoft Sentinel, custom app scope and automated response (disable app) could be one of the reason to prefer the features in App Governance over Entra ID recommendations. More details about App hygiene policies are available from Microsoft Learn.

Statistics about data usage of an app to OneDrive (via Microsoft Graph API) and overview about users which has been defined as priority/sensitive account.

More policies and capabilities for detecting anomalous activities are available which will be described in the next part of the blog post about “Monitoring and Security of Entra ID Workload Identities”.

Remove unused permissions

Regular review of assigned permissions should be considered for workload identities. App Governance has a strong focus on permissions to API Permissions. But also, other privileges to RBAC assignments (such as Entra ID roles or Azure RBAC) and even Groups should be included in the access review.

MDA App Governance for Microsoft Graph API Permissions

App Governance gives you the option to analyze the usage of Graph API Permissions for Exchange Online, SharePoint, OneDrive and Teams in the recent 90 days. This can be also integrated as a policy to trigger an alert but also for correlation to other built-in threat detections (”Increase in data usage by an overprivileged or highly privileged app”).

Overview of Assigned Permissions to Exchange Online (Mail.ReadWrite) and User.Read (Entra ID). “In Use” can be only analyzed for certain endpoints of Microsoft 365 services.

Side Note: Microsoft seems to be working on a new data source in Entra ID logs to get insights about Microsoft Graph Activities. There are some reports about the private preview on Twitter. The log schema is already available in Microsoft Learn and gives some interesting impressions which information will be covered. In my opinion, this would also allow to provide detections in Microsoft Sentinel for unused/over-privileged API permissions but detecting abuse and exfiltration of data from/to Graph.

Entra Permissions Management (EPM) for Multi-Cloud Permissions

Over-privileged permissions in cloud infrastructure environments can be analyzed with Entra Permissions Management (EPM). Currently, Google Cloud Platform (GCP), Amazon Web Services (AWS) and Azure are supported. A score of unused or excessive permissions will be calculated with the option to create a custom role assignment based on the used and required permissions.

Example: Microsoft Sentinel Playbook is running with a system-assigned managed identity which has comprehensive permissions as part of the role assignment to “Microsoft Sentinel Contributor”. But only one role action (“incidents/comments/write”) will be used from the role definition set of over 700 actions. Reducing the set of assigned permissions can be achieved by the remediation features in EPM and supports you to follow the approach of least privileges.

I can strongly recommend evaluating EPM in your environment by using the free trial version. There’s also a comprehensive “Trial user guide” which supports you to explore all the features to analyze least privilege in your multi-cloud environment.

Access Review for Entra ID roles and Azure resource assignments

Identity Governance supports access review for service principal role assignments in Entra ID or Azure Resources. This feature has been already introduced in June 2021 and requires “Workload Identity Premium License” in addition to Entra ID Premium P2.

Configuration of Access Review for Service Principals for high-privileged directory roles.

Automated actions can be configured in case the reviewer doesn’t respond to confirm the need of the required permissions.

Reviewer will be notified about the access review and needs to approve or deny the continuing validity of the requirements to use this directory or RBAC role assignment. There seems to be no support for “recommended actions” which gives insights about the current usage. A deep link to the recent activities as part of the Azure (AD) Audit Logs is available from the review page.

Privileged Identity Management (PIM) gives you a total number of directory role assignments. Unfortunately, assignments on Administrative Unit- or Object-Level have not been recognized in my test environment.

Recovery of deleted objects

Entra ID offers an option to recover supported objects within a 30-day time window. Those objects will not be permanently deleted and remains in a suspended state for this time period. App Registrations are one of these supported objects which can be restored when they have been removed recently. Managed Identities are a special type of service principals and are not covered. Some of the configurations can not be recovered from the Portal UI or not included in the recovery process yet. Check the deletion and recovery FAQ for more details.

You’ll find the options to delete an application permanently or recover the object by clicking on the “Deleted application” tab on the “App Registration” blade.

Summary and comparison of workload identity lifecycle management

	Application Identity (with Key or Certificate)	Application Identity (with Federated Credential)	Managed Identity (System-Assigned)	Managed Identity (User-Assigned)
Use Cases	No limitations	Limited, support workload and/or IdP required	Limited, support, workload must be a Azure-Managed resource	Limited, support, workload must be a Azure-Managed resource or federated credential
Security Boundary	Single- or Multi-Tenant	Single- or Multi-Tenant	Single Tenant, limited Multi-Tenant access*	Single-Tenant, limited Multi-Tenant access*
Recovery Options	Soft Deletion	Soft Deletion	N/A	N/A
Lifecycle Management	Managed by admin or automated process	Managed by admin or automated process	Managed by Azure	Standalone Azure resource (managed by admin or automated process)
Recovery Options	Soft Deletion	Soft Deletion	N/A	N/A
Token Lifetime / Cache	1h (Default), 24h (CAE)	less than or equal to 1h	up to 24h	up to 24h
Delegation and Ownership	Application/Enterprise App Owner Entra ID Role (Directory, Object)	Application/Enterprise App Owner, Entra ID Role (Directory, Object)	Enterprise App Owner, Entra ID Role, Azure RBAC Role/Resource Owner	Enterprise App Owner, Entra ID Role, Azure RBAC Role/Resource Owner
Recovery Options	Soft Deletion	Soft Deletion	N/A	N/A

Next: Threat detection with Microsoft Defender XDR and Sentinel

I’ve already mentioned some Microsoft Security but also community tools for monitoring in this article. In the next part of the blog post series we will go into details about using the capabilities of this solutions for detection and response of workload identities.