Update: Changing the Account Name Entity Mapping in Microsoft Sentinel
The upcoming update introduces more consistent and predictable entity data across analytics, incidents, and automation by standardizing how the Account Name property is populated when using UPN‑based mappings in analytic rules. Going forward, Account Name property will consistently contain only the UPN prefix, with new dedicated fields added for the full UPN and UPN suffix. While this improves consistency and enables more granular automation, customers who rely on specific Account Name values in automation rules or Logic App playbooks may need to take action. Timeline Effective date: July 1, 2026. The change will apply automatically - no opt-in is required. Scope of impact Analytics Rules which include mapping of User Principal Name (UPN) to the Account Name entity field, where the resulting alerts are processed by Automation Rules or Logic App Playbooks that reference the AccountName property. What’s changing Currently When an Analytic Rule includes mapping of a full UPN (for example: 'user@domain.com') to the Account Name field, the resulting input value for the Automation Rule or/and Logic App Playbook is inconsistent. In some cases, it contains only the UPN prefix: 'user', and in other cases the full UPN ('user@domain.com'). After July 1, 2026 Account Name property will consistently contain only the UPN prefix The following new fields will be added to the entity object: AccountName (UPN prefix) UPNSuffix UserPrincipalName (full UPN) This change provides an enhanced filtering and automation logic based on these new fields. Example Before Analytics Rule maps: 'user@domain.com' Automation Rule receives: Account Name: 'user' or 'user@domain.com' (inconsistent) After Analytics Rule maps: 'user@domain.com' Automation Rule receives: Account Name: 'user' UPNSuffix: 'domain.com' Logic App Playbook and SecurityAlert table receives: AccountName: 'user' UPNSuffix: 'domain.com' UserPrincipalName: 'user@domain.com' Feature / Location Before After SecurityAlert table Logic App Playbook Entity Why does it matter? If your automation logic relies on exact string comparisons against the full UPN stored in Account Name, those conditions may no longer match after the update. This most commonly affects: Automation Rules using "Equals" condition on Account Name Logic App Playbooks comparing entity field 'accountName' to a full UPN value Call to action Avoid strict equality checks against Account Name Use flexible operators such as: Contains Starts with Leverage the new UPNSuffix field for clearer intent Example update Before - Account name will show as 'user' or 'user@domain.com' After - Account Name will show as 'user' Recommended changes: Account Name Contains/Startswith 'user' UPNSuffix Equals/Startswith/Contains 'domain.com' This approach ensures compatibility both before and after the change takes effect. Where to update Review any filters, conditions, or branching logic that depend on Account Name values. Automation Rules: Use the 'Account name' field Logic App Playbooks: Update conditions referencing the entity: 'accountName' For example: Automation Rule before the change: Automation Rule after the change: Summary A consistency improvement to Account Name mapping is coming on July 1, 2026 The change affects Automation Rules and Logic App Playbooks that rely on UPN to Account Name mappings New UPN related fields provide better structure and control Customers should follow the recommendations above before the effective change dateCall to Action: Migrate Your Classic Alert‑trigger Automations to Automation Rules Before March 2026
Reminder: Following the Retirement Announcement published in March 2023, classic alert‑trigger automation in Microsoft Sentinel, where playbooks are triggered directly from analytic rules will be deprecated in March 2026. To ensure your alert‑driven automations continue to run without interruption, please migrate to automation rules. How to Identify the Impacted Rules To help you quickly identify if any analytic rules should be updated, we created a Logic App solution that identifies all the analytic rules which use classic automation. The solution is available in two deployment options: Subscription-level version – scans all workspaces in the subscription Workspace-level version – scans a single workspace (useful when subscription Owner permissions are not available) Both options create an output of a list of analytic rules which need to be updated as described in the next section. The solution is published as part of Sentinel's GitHub community solutions with deployment instructions and further details: sentinel-classic-automation-detection After deploying and running the tool, open the Logic App run history. The final action contains the list of the analytic rules which require migration. How to Migrate the identified Analytic Rules from Classic Alert‑trigger Automations Once you have identified the analytic rules using classic automation, follow the official Microsoft Learn guidance to migrate them to automation rules: migrate-playbooks-to-automation-rules In short: Identify classic automation in your analytic rules Create automation rules to replace the classic automation To complete the migration, remove the Alert Automation Classic Actions identified in step #1 by clicking on the three dots and 'Remove' Summary Classic automation will retire in March 2026 Use the detection tool to identify any remaining classic alert-trigger playbooks Follow the official Microsoft documentation to complete the required changes Act now to ensure your SOC automations continue to run smoothly
Enhancing Security Monitoring: Integrating GitLab Cloud Edition with Microsoft Sentinel
Maximize your security operations by combining GitLab Cloud Edition with Microsoft Sentinel. This blog covers how to fill the void of a missing native connector for GitLab in Sentinel. Utilize GitLab's API endpoints, Azure Monitor Data Collection Rules, and Data Collection Endpoints, as well as Azure Logic Apps and Key Vault, to simplify log collection and improve immediate threat identification. Our detailed guide will help you integrate smoothly and strengthen your security defences.Microsoft Sentinel & Cyberint Threat Intel Integration Guide
Explore comprehensive guide on "Microsoft Sentinel & Cyberint Threat Intel Integration Guide," to learn how to integrate Cyberint's advanced threat intelligence with Microsoft Sentinel. This detailed resource will walk you through the integration process, enabling you to leverage enriched threat data for improved detection and response. Elevate your security posture and ensure robust protection against emerging threats. Read the guide to streamline your threat management and enhance your security capabilities.What’s New: Exciting new Microsoft Sentinel Connectors Announcement - Ignite 2024
Microsoft Sentinel continues to be a leading cloud-native security information and event management (SIEM) solution, empowering organizations to detect, investigate, and respond to threats across their digital ecosystem at scale. Microsoft Sentinel offers robust out of the box (OOTB) content, allowing seamless connections with a wide array of data sources from both Microsoft and third-party providers. This enables comprehensive collection and analysis of security signals across multicloud, multiplatform environments, enhancing your overall security posture. In this Ignite 2024 blog post, we are thrilled to present the latest integrations contributed by our esteemed Partners. These new integrations further expand the capabilities of Microsoft Sentinel, enabling you to connect your existing security solutions and leverage Microsoft Sentinel’s powerful analytics and automation capabilities to fortify your defenses against evolving cyber threats. Featured ISV 1Password for Microsoft Sentinel The integration between 1Password Extended Access Management and Microsoft Sentinel provides businesses with real-time visibility and alerts for login attempts and account changes. It enables quick detection of security threats and streamlines reporting by monitoring both managed and unmanaged apps from a single, centralized platform, ensuring faster response times and enhanced security. Cisco Secure Email Threat Defense Sentinel Application This application collects threat information from Cisco Secure Email Threat Defense and ingests it into Microsoft Sentinel for visualization and analysis. It enhances email security by detecting and blocking advanced threats, providing comprehensive visibility and fast remediation. Cribl Stream Solution for Microsoft Sentinel Cribl Stream accelerates SIEM migrations by ingesting, transforming, and enriching third party data into Microsoft Sentinel. It simplifies data onboarding, optimizes data in various formats, and helps maintain compliance, enhancing security operations and threat detection. FortiNDR Cloud FortiNDR Cloud integrates Fortinet’s network detection and response capabilities with Microsoft Sentinel, providing advanced threat detection and automated response. Fortinet FortiNDR Cloud enhances network security by helping to identify and mitigate threats in real-time. Pure Storage Solution for Microsoft Sentinel This solution integrates Pure Storage’s data storage capabilities with Sentinel, providing enhanced data protection and performance. It helps optimize storage infrastructure and improve data security. New and Notable CyberArk Audit for Microsoft Sentinel This solution extracts audit trail data from CyberArk and integrates it with Microsoft Sentinel, providing a comprehensive view of system and user activities. It enhances incident response with automated workflows and real-time threat detection. Cybersixgill Actionable Alerts for Microsoft Sentinel Cybersixgill provides contextual and actionable alerts based on data from the deep and dark web. It helps SOC analysts detect phishing, data leaks, and vulnerabilities, enhancing incident response and threat remediation. Cyware For Microsoft Sentinel Cyware integrates with Microsoft Sentinel to automate incident response and enhance threat hunting. It uses Logic Apps and hunting queries to streamline security operations and provides contextual threat intelligence. Ermes Browser Security for Microsoft Sentinel Ermes Browser Security ingests security and audit events into Microsoft Sentinel, providing enhanced visibility and reporting. It helps monitor and respond to web threats, improving the organization’s security posture. Gigamon Data Connector for Microsoft Sentinel This solution integrates Gigamon GigaVUE Cloud Suite, including Application Metadata Intelligence, with Microsoft Sentinel, providing comprehensive network traffic visibility and insights. It helps detect anomalies and optimize network performance, enhancing overall security. Illumio Sentinel Integration Illumio integrates its micro-segmentation capabilities with Microsoft Sentinel, providing real-time visibility and control over network traffic. It helps prevent lateral movement of threats and enhances overall network security. Infoblox App for Microsoft Sentinel The Infoblox solution enhances SecOps capabilities by seamlessly integrating Infoblox's AI-driven analytics, providing actionable insights, dashboards, and playbooks derived from DNS intelligence. These insights empower SecOps teams to achieve rapid incident response and remediation, all within the familiar Microsoft Sentinel user interface. LUMINAR Threat Intelligence for Microsoft Sentinel LUMINAR integrates threat intelligence and leaked credentials data into Microsoft Sentinel, helping organizations maintain visibility of their threat landscape. It provides timely, actionable insights to help detect and respond to threats before they impact the organization. Prancer PenSuite AI Prancer PenSuite AI now supercharges Microsoft Sentinel by injecting pentesting and real-time AppSec data into SOC operations. With powerful red teaming simulations, it empowers teams to detect vulnerabilities earlier, respond faster, and stay ahead of evolving threats. Phosphorus Connector for Microsoft Sentinel Phosphorus Cybersecurity’s Intelligent Active Discovery provides in-depth context for xIoT assets, that enhances threat detection and allows for targeted responses, enabling organizations to isolate or secure specific devices based on their criticality. Silverfort for Microsoft Sentinel Silverfort integrates its Unified Identity Protection Platform with Microsoft Sentinel, securing authentication and access to sensitive systems, both on-premises and in the cloud without requiring agents or proxies. Transmit Security Data Connector for Sentinel Transmit Security integrates its identity and access management capabilities with Sentinel, providing real-time monitoring and threat detection for user activities. It helps secure identities and prevent unauthorized access. In addition to commercially supported integrations, Microsoft Sentinel Content Hub also connects you to hundreds of community-based solutions as well as thousands of practitioner contributions. For more details and instructions on how to set up these integrations see Microsoft Sentinel data connectors | Microsoft Learn. To our partners: Thank you for your unwavering partnership and invaluable contributions on this journey to deliver the most comprehensive, timely insights and security value to our mutual customers. Security is indeed a team sport, and we are grateful to be working together to enhance the security landscape. Your dedication and innovation are instrumental in our collective success. We hope you find these new partner solutions useful, and we look forward to hearing your feedback and suggestions. Stay tuned for more updates and announcements on Microsoft Sentinel and its partner ecosystem. Learn More Microsoft’s commitment to Security Microsoft’s Secure Future Initiative Unified SecOps | SIEM and XDR Solutions Unified Platform documentation | Microsoft Defender XDR What else is new with Microsoft Sentinel? Microsoft Sentinel product home Schema Mapping Microsoft Sentinel Partner Solution Contributions Update – Ignite 2023 Additional resources: Sentinel Ignite 2024 Blog Latest Microsoft Tech Community Sentinel blog announcements Microsoft Sentinel solution for SAP Microsoft Sentinel solution for Power Platform Microsoft Sentinel pricing Microsoft Sentinel customer stories Microsoft Sentinel documentationMicrosoft Sentinel Automation Tips & Tricks – Part 2: Playbooks
This blog is part of a multi-series Part 1: Automation rules Part 2: Playbooks – this blog Part 3: Send email notification options Part 4: Dynamic content and expressions – coming soon Playbooks A playbook is a collection of response and remediation actions and logic that can be run from Microsoft Sentinel as a routine. A playbook can help automate and orchestrate your threat response, integrate with other internal and external systems, and be set to run automatically in response to specific alerts or incidents triggered by an analytics rule or an automation rule. It can also be run on-demand manually from the incidents page in response to alerts. Here are some tips & tricks that can be helpful when creating playbooks: Run playbooks on incidents manually Running playbooks on incidents using automation rules provides a fantastic management point. But sometimes, we need to run a playbook with incident trigger manually. With a new API endpoint, that is possible, and now you can run playbooks on the incident from the incident overview page, and you can even mark favorite ones to be on the top of the list. More details about running playbooks on demand you can find on this blog: What's new: run playbooks on incidents on demand - Microsoft Tech Community Run playbooks from workbooks With the option to run playbooks with incident trigger on-demand using a new API endpoint, we also got the possibility to use ARM action in workbooks to run incident trigger playbooks from workbooks on-demand. To get details on how to use this functionality in workbooks, please check this blog: Run Microsoft Sentinel playbooks from workbooks on-demand - Microsoft Tech Community Nested playbooks - Run new playbooks as an action in the playbook Using the same API endpoint in running incident trigger playbooks from workbooks, we can run the playbook as an action in the existing playbook. To make it work, the first playbook must have the Logic App Contributor role assigned to the service principal or managed identity used to authorize HTTP action. HTTP Method: POST API path: https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/incidents/{incidentId}/runPlaybook?api-version=2019-01-01-preview Body: { "LogicAppsResourceId":"/subscriptions/{subscriptionId}/resourceGroups/{PlaybookResourceGroup}/providers/Microsoft.Logic/workflows/{PlaybookName}", "TenantId":"{TenantID}" } Create ARM template from the existing playbook Many organizations are using development instances of Microsoft Sentinel, where they test analytic rules, playbooks, etc., before deploying them into production instance. Creating playbook template manually can be time consuming job. That is why Sreedhar Ande had created ARM template generator, that is automating most of the things needed to create playbook template. The same tool can be used to create playbook to contribute to Microsoft Sentinel official GitHub repository. On this blog, you can find info how to deploy and used this tool: Export Microsoft Sentinel Playbooks or Azure Logic Apps with Ease - Microsoft Tech Community How to authorize Logic App connector and what identity to use Playbooks are using power of Logic App to automate SOC actions on incidents. Every Logic App action is using API in the background, which needs to be authorized. To authorize Logic App connector, it is possible to use 3 different identities: Managed Identity Service principal (Azure AD application registration) User identity In this blog you can find more details about each type of identity and when to use each: API connections and permissions for Microsoft Sentinel Playbooks In this article you can find more details about authenticating playbooks in Microsoft Sentinel: Authenticate playbooks to Microsoft Sentinel | Microsoft Docs Assign API permissions to managed identity using PowerShell System-assigned managed identity is the preferred method of authorizing Logic App connectors because organizations don’t need to manage keys, and only that Logic App can use permissions. No other Logic App can use it, as with service principal or user identity. Assigning Azure RBAC controls or Azure AD roles are straightforward and can be done quickly from the GUI, like with service principal or user identity. But sometimes, we need to assign specific API permissions to get the least privileged access. This can be done using Powershell. When we deploy the playbook, we need to ensure the system-assigned managed identity is enabled and copy the GUID of managed identity as we need it. We open PowerShell, and we need to run these commands: Set-ExecutionPolicy unrestricted Install-Module AzureAD Import-Module AzureAD After we are sure the Azure AD module is installed, we can connect to Azure AD. Connect-AzureAD And then, we run a PowerShell script that will assign specific API permissions. For example, we will use the playbook Block-AADUser. First, we need GUID from managed identity, application ID, and permissions. Managed Identity GUID you can find after deploying the playbook under “Identity”. Application ID can be found on the Azure AD admin portal under Enterprise applications. Under filter, choose All applications. We will search for the application regarding the API we are using: Microsoft Graph, Microsoft Defender for Endpoint, etc. The most common application IDs will be: Azure AD (Microsoft Graph) - 00000003-0000-0000-c000-000000000000 Microsoft Defender for Endpoint - fc780465-2017-40d4-a0c5-307022471b92 Microsoft 365 Defender - 8ee8fdad-f234-4243-8f3b-15c294843740 Permissions will depend on the action we need to perform, whether we need to get the user, update the user, get the machine, isolate the machine, etc. Depending on API documentation, you can find specific API permissions needed to be assigned to perform the action. In this specific playbook, we need to assign these API permissions: User.Read.All User.ReadWrite.All Directory.Read.All Directory.ReadWrite.All PowerShell code would look like this: PowerShell code would look like this: $MIGuid = "<Enter your managed identity guid here>" $MI = Get-AzureADServicePrincipal -ObjectId $MIGuid $GraphAppId = "00000003-0000-0000-c000-000000000000" $PermissionName1 = "User.Read.All" $PermissionName2 = "User.ReadWrite.All" $PermissionName3 = "Directory.Read.All" $PermissionName4 = "Directory.ReadWrite.All" $GraphServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$GraphAppId'" $AppRole1 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName1 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole1.Id $AppRole2 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName2 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole2.Id $AppRole3 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName3 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole3.Id $AppRole4 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName4 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole4.Id We need to run it and have API permissions assigned to the managed identity! Continue with playbook when action fails Sometimes failure of an action in playbook is expected and we don’t want that whole playbook run fails as well. This is possible to configure in playbooks by configuring “run after” option. Use case would be using “Get a watchlist by alias” to check is watchlist available or not, before using action to create a new watchlist. Action is returning status code 200 and 400, depending on is watchlist available or not. By configuring condition action to be triggered even if “Get a watchlist by alias” fails, you are able to check status code and if it’s 400 (watchlist not available), continue creating new watchlist. < Part 1: Automation rules Part 3: Send email notification options >
