Microsoft Sentinel topics

Sentinel RBAC in the Unified portal: who has activated Unified RBAC, and how did it go?

AnthonyPorter — Tue, 21 Apr 2026 06:04:28 GMT

Following the RSAC 2026 announcements last month, I have been working through the full permission picture for the Unified portal and wanted to open a discussion here given how much has shifted in a short period.

A quick framing of where things stand. The baseline is still that Azure RBAC carries across for Sentinel SIEM access when you onboard, no changes required. But there are now two significant additions in public preview: Unified RBAC for Sentinel SIEM itself (extending the Defender Unified RBAC model to cover Sentinel directly), and a new Defender-native GDAP model for non-CSP organisations managing delegated access across tenants.

The GDAP piece in particular is worth discussing carefully, because I want to be precise about what has and has not changed. The existing limitation from Microsoft's onboarding documentation, that GDAP with Azure Lighthouse is not supported for Sentinel data in the Defender portal, has not changed. What is new is a separate, Defender-portal-native GDAP mechanism announced at RSAC, which is a different thing. These are not the same capability. If you were using Entra B2B as the interim path based on earlier guidance, that guidance was correct and that path remains the generally available option today.

A few things I would genuinely like to hear from practitioners:

For those who have activated Unified RBAC for a Sentinel workspace in the Defender portal: what did the migration from Azure RBAC roles look like in practice? Did the import function bring roles across cleanly, or did you find gaps particularly around custom roles?
For environments using Playbook Operator, Automation Contributor, or Workbook Contributor role assignments: how are you handling the fact those three roles are not yet in Unified RBAC and still require Azure portal management? Is the dual-management posture creating operational friction?
For MSSPs evaluating the new Defender-native GDAP model against their existing Entra B2B setup: what factors are driving the decision either way at your scale?

Writing this up as Part 3 of the migration series and the community experience here is directly useful for making sure the practitioner angle is grounded.

Stuck looking up a watchlist value

MrD — Wed, 01 Apr 2026 14:25:42 GMT

Hiya,

I get stuck working with watchlists sometimes.

In this example, I'm wanting to focus on account activity from a list of UPNs.

If I split the elements up, I get the individual results, but can't seem to pull it all together.

=====================================================

In its entirety, the query returns zero results:

let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey;

let OpName = dynamic(['Reset password (self-service)','Reset User Password','Change user password','User reset password','User started password reset','Enable Account','Change password (self-service)','Update PasswordProfile','Self-service password reset flow activity progress']);

AuditLogs

| where OperationName has_any (OpName)

| extend upn = TargetResources.[0].userPrincipalName

| where upn in (ServiceAccounts) //<=This is where I think I'm wrong

| project upn

=====================================================

This line on its own, returns the user on the list:

let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey;

=====================================================

This section on its own, returns all the activity

AuditLogs

| where OperationName has_any (OpName)

| extend upn = TargetResources.[0].userPrincipalName

| where upn contains "username" //This is the name on the watchlistlist - so I know the activity exists)

====================================================

I'm doing something wrong when I'm trying to use the watchlist cache (I think)

Any help\guidance or wisdom would be greatly appreciated!

Many thanks

Security Copilot Integration with Microsoft Sentinel - Why Automation matters now

Marcel_Graewer — Tue, 31 Mar 2026 13:09:01 GMT

Security Operations Centers face a relentless challenge - the volume of security alerts far exceeds the capacity of human analysts. On average, a mid-sized SOC receives thousands of alerts per day, and analysts spend up to 80% of their time on initial triage. That means determining whether an alert is a true positive, understanding its scope, and deciding on next steps. With Microsoft Security Copilot now deeply integrated into Microsoft Sentinel, there is finally a practical path to automating the most time-consuming parts of this workflow.

So I decided to walk you through how to combine Security Copilot with Sentinel to build an automated incident triage pipeline - complete with KQL queries, automation rule patterns, and practical scenarios drawn from common enterprise deployments.

Traditional triage workflows rely on analysts manually reviewing each incident - reading alert details, correlating entities across data sources, checking threat intelligence, and making a severity assessment. This is slow, inconsistent, and does not scale.

Security Copilot changes this equation by providing:

Natural language incident summarization - turning complex, multi-alert incidents into analyst-readable narratives
Automated entity enrichment - pulling threat intelligence, user risk scores, and device compliance state without manual lookups
Guided response recommendations - suggesting containment and remediation steps based on the incident type and organizational context

The key insight is that Copilot does not replace analysts - it handles the repetitive first-pass triage so analysts can focus on decision-making and complex investigations.

Architecture - How the Pieces Fit Together

The automated triage pipeline consists of four layers:

Detection Layer - Sentinel analytics rules generate incidents from log data
Enrichment Layer - Automation rules trigger Logic Apps that call Security Copilot
Triage Layer - Copilot analyzes the incident, enriches entities, and produces a triage summary
Routing Layer - Based on Copilot's assessment, incidents are routed, re-prioritized, or auto-closed

(Forgive my AI-painted illustration here, but I find it a nice way to display dependencies.)

+-----------------------------------------------------------+ | Microsoft Sentinel | | | | Analytics Rules --> Incidents --> Automation Rules | | | | | v | | Logic App / Playbook | | | | | v | | Security Copilot API | | +-----------------+ | | | Summarize | | | | Enrich Entities | | | | Assess Risk | | | | Recommend Action| | | +--------+--------+ | | | | | v | | +-----------------------------+ | | | Update Incident | | | | - Add triage summary tag | | | | - Adjust severity | | | | - Assign to analyst/team | | | | - Auto-close false positive| | | +-----------------------------+ | +-----------------------------------------------------------+

Step 1 - Identify High-Volume Triage Candidates

Not every incident type benefits equally from automated triage. Start with alert types that are high in volume but often turn out to be false positives or low severity. Use this KQL query to identify your top candidates:

SecurityIncident | where TimeGenerated > ago(30d) | summarize TotalIncidents = count(), AutoClosed = countif(Classification == "FalsePositive" or Classification == "BenignPositive"), AvgTimeToTriageMinutes = avg(datetime_diff('minute', FirstActivityTime, CreatedTime)) by Title | extend FalsePositiveRate = round(AutoClosed * 100.0 / TotalIncidents, 1) | where TotalIncidents > 10 | order by TotalIncidents desc | take 20

This query surfaces the incident types where automation will deliver the highest ROI. Based on publicly available data and community reports, the following categories consistently appear at the top:

Impossible travel alerts (high volume, around 60% false positive rate)
Suspicious sign-in activity from unfamiliar locations
Mass file download and share events
Mailbox forwarding rule creation

Step 2 - Build the Copilot-Powered Triage Playbook

Create a Logic App playbook that triggers on incident creation and leverages the Security Copilot connector. The core flow looks like this:

Trigger: Microsoft Sentinel Incident - When an incident is created

Action 1 - Get incident entities:

let incidentEntities = SecurityIncident | where IncidentNumber == <IncidentNumber> | mv-expand AlertIds | join kind=inner (SecurityAlert | extend AlertId = SystemAlertId) on $left.AlertIds == $right.AlertId | mv-expand Entities | extend EntityData = parse_json(Entities) | project EntityType = tostring(EntityData.Type), EntityValue = coalesce( tostring(EntityData.HostName), tostring(EntityData.Address), tostring(EntityData.Name), tostring(EntityData.DnsDomain) ); incidentEntities

Note: The <IncidentNumber> placeholder above is a Logic App dynamic content variable. When building your playbook, select the incident number from the trigger output rather than hardcoding a value.

Action 2 - Copilot prompt session:

Send a structured prompt to Security Copilot that requests:

Analyze this Microsoft Sentinel incident and provide a triage assessment: Incident Title: {IncidentTitle} Severity: {Severity} Description: {Description} Entities involved: {EntityList} Alert count: {AlertCount} Please provide: 1. A concise summary of what happened (2-3 sentences) 2. Entity risk assessment for each IP, user, and host 3. Whether this appears to be a true positive, benign positive, or false positive 4. Recommended next steps 5. Suggested severity adjustment (if any)

Action 3 - Parse and route:

Use the Copilot response to update the incident. The Logic App parses the structured output and:

Adds the triage summary as an incident comment
Tags the incident with copilot-triaged
Adjusts severity if Copilot recommends it
Routes to the appropriate analyst tier based on the assessment

Step 3 - Enrich with Contextual KQL Lookups

Security Copilot's assessment improves dramatically when you feed it contextual data. Before sending the prompt, enrich the incident with organization-specific signals:

// Check if the user has a history of similar alerts (repeat offender vs. first time) let userAlertHistory = SecurityAlert | where TimeGenerated > ago(90d) | mv-expand Entities | extend EntityData = parse_json(Entities) | where EntityData.Type == "account" | where tostring(EntityData.Name) == "<UserPrincipalName>" | summarize PriorAlertCount = count(), DistinctAlertTypes = dcount(AlertName), LastAlertTime = max(TimeGenerated) | extend IsRepeatOffender = PriorAlertCount > 5; userAlertHistory

// Check user risk level from Entra ID Protection AADUserRiskEvents | where TimeGenerated > ago(7d) | where UserPrincipalName == "<UserPrincipalName>" | summarize arg_max(TimeGenerated, RiskLevel), RecentRiskEvents = count() | project RiskLevel, RecentRiskEvents

Including this context in the Copilot prompt transforms generic assessments into organization-aware triage decisions. A "suspicious sign-in" for a user who travels internationally every week is very different from the same alert for a user who has never left their home country.

Step 4 - Implement Feedback Loops

Automated triage is only as good as its accuracy over time. Build a feedback mechanism by tracking Copilot's assessments against analyst final classifications:

SecurityIncident | where Tags has "copilot-triaged" | where TimeGenerated > ago(30d) | where Classification != "" | mv-expand Comments | extend CopilotAssessment = extract("Assessment: (True Positive|False Positive|Benign Positive)", 1, tostring(Comments)) | where isnotempty(CopilotAssessment) | summarize Total = dcount(IncidentNumber), Correct = dcountif(IncidentNumber, (CopilotAssessment == "False Positive" and Classification == "FalsePositive") or (CopilotAssessment == "True Positive" and Classification == "TruePositive") or (CopilotAssessment == "Benign Positive" and Classification == "BenignPositive") ) by bin(TimeGenerated, 7d) | extend AccuracyPercent = round(Correct * 100.0 / Total, 1) | order by TimeGenerated asc

For this query to work reliably, the automation playbook must write the assessment in a consistent format within the incident comments. Use a structured prefix such as Assessment: True Positive so the regex extraction remains stable.

According to Microsoft's published benchmarks and community feedback, Copilot-assisted triage typically achieves 85-92% agreement with senior analyst classifications after prompt tuning - significantly reducing the manual triage burden.

A Note on Licensing and Compute Units

Security Copilot is licensed through Security Compute Units (SCUs), which are provisioned in Azure. Each prompt session consumes SCUs based on the complexity of the request. For automated triage at scale, plan your SCU capacity carefully - high-volume playbooks can accumulate significant usage. Start with a conservative allocation, monitor consumption through the Security Copilot usage dashboard, and scale up as you validate ROI. Microsoft provides detailed guidance on SCU sizing in the official Security Copilot documentation.

Example Scenario - Impossible Travel at Scale

Consider a typical enterprise that generates over 200 impossible travel alerts per week. The SOC team spends roughly 15 hours weekly just triaging these. Here is how automated triage addresses this:

Detection - Sentinel's built-in impossible travel analytics rule flags the incidents
Enrichment - The playbook pulls each user's typical travel patterns from sign-in logs over the past 90 days, VPN usage, and whether the "impossible" location matches any known corporate office or VPN egress point
Copilot Analysis - Security Copilot receives the enriched context and classifies each incident
Expected Result - Based on common deployment patterns, around 70-75% of impossible travel incidents are auto-closed as benign (VPN, known travel patterns), roughly 20% are downgraded to informational with a triage note, and only about 5% are escalated to analysts as genuine suspicious activity

This type of automation can reclaim over 10 hours per week - time that analysts can redirect to proactive threat hunting.

Getting Started - Practical Recommendations

For teams ready to implement automated triage with Security Copilot and Sentinel, here is a recommended approach:

Start small. Pick one high-volume, high-false-positive incident type. Do not try to automate everything at once.
Run in shadow mode first. Have the playbook add triage comments but do not auto-close or re-route. Let analysts compare Copilot's assessment with their own for two to four weeks.
Tune your prompts. Generic prompts produce generic results. Include organization-specific context - naming conventions, known infrastructure, typical user behavior patterns.
Monitor accuracy continuously. Use the feedback loop KQL above. If accuracy drops below 80%, pause automation and investigate.
Maintain human oversight. Even at 90%+ accuracy, keep a human review step for high-severity incidents. Automation handles volume - analysts handle judgment.

The combination of Security Copilot and Microsoft Sentinel represents a genuine step forward for SOC efficiency. By automating the initial triage pass - summarizing incidents, enriching entities, and providing classification recommendations - analysts are freed to focus on what humans do best: making nuanced security decisions under uncertainty.

Feel free to like or/and connect :)

Webinar Cancellation

emilyfalla — Mon, 30 Mar 2026 21:40:40 GMT

Hi everyone!

The webinar originally scheduled for April 14th on "Using distributed content to manage your multi-tenant SecOps" has unfortunately been cancelled for now. We apologize for the inconvenience and hope to reschedule it in the future.

Please find other available webinars at: http://aka.ms/securitycommunity

All the best,

The Microsoft Security Community Team

Your Sentinel AMA Logs & Queries Are Public by Default — AMPLS Architectures to Fix That

veesamprabhukiran — Wed, 25 Mar 2026 23:19:39 GMT

When you deploy Microsoft Sentinel, security log ingestion travels over public Azure Data Collection Endpoints by default. The connection is encrypted, and the data arrives correctly — but the endpoint is publicly reachable, and so is the workspace itself, queryable from any browser on any network.

For many organisations, that trade-off is fine. For others — regulated industries, healthcare, financial services, critical infrastructure — it is the exact problem they need to solve.

Azure Monitor Private Link Scope (AMPLS) is how you solve it.

What AMPLS Actually Does

AMPLS is a single Azure resource that wraps your monitoring pipeline and controls two settings:

Where logs are allowed to go (ingestion mode: Open or PrivateOnly)
Where analysts are allowed to query from (query mode: Open or PrivateOnly)

Change those two settings and you fundamentally change the security posture — not as a policy recommendation, but as a hard platform enforcement. Set ingestion to PrivateOnly and the public endpoint stops working. It does not fall back gracefully. It returns an error. That is the point.

It is not a firewall rule someone can bypass or a policy someone can override. Control is baked in at the infrastructure level.

Three Patterns — One Spectrum

There is no universally correct answer. The right architecture depends on your organisation's risk appetite, existing network infrastructure, and how much operational complexity your team can realistically manage. These three patterns cover the full range:

Architecture 1 — Open / Public (Basic)
No AMPLS. Logs travel to public Data Collection Endpoints over the internet. The workspace is open to queries from anywhere. This is the default — operational in minutes with zero network setup.
Cloud service connectors (Microsoft 365, Defender, third-party) work immediately because they are server-side/API/Graph pulls and are unaffected by AMPLS. Azure Monitor Agents and Azure Arc agents handle ingestion from cloud or on-prem machines via public network.

Simplicity: 9/10 | Security: 6/10
Good for: Dev environments, teams getting started, low-sensitivity workloads

Architecture 2 — Hybrid: Private Ingestion, Open Queries (Recommended for most)
AMPLS is in place. Ingestion is locked to PrivateOnly — logs from virtual machines travel through a Private Endpoint inside your own network, never touching a public route. On-premises or hybrid machines connect through Azure Arc over VPN or a dedicated circuit and feed into the same private pipeline.
Query access stays open, so analysts can work from anywhere without needing a VPN/Jumpbox to reach the Sentinel portal — the investigation workflow stays flexible, but the log ingestion path is fully ring-fenced. You can also split ingestion mode per DCE if you need some sources public and some private.
This is the architecture most organisations land on as their steady state.

Simplicity: 6/10 | Security: 8/10
Good for: Organisations with mixed cloud and on-premises estates that need private ingestion without restricting analyst access

Architecture 3 — Fully Private (Maximum Control)
Infrastructure is essentially identical to Architecture 2 — AMPLS, Private Endpoints, Private DNS zones, VPN or dedicated circuit, Azure Arc for on-premises machines. The single difference: query mode is also set to PrivateOnly.
Analysts can only reach Sentinel from inside the private network. VPN or Jumpbox required to access the portal. Both the pipe that carries logs in and the channel analysts use to read them are fully contained within the defined boundary.
This is the right choice when your organisation needs to demonstrate — not just claim — that security data never moves outside a defined network perimeter.

Simplicity: 2/10 | Security: 10/10
Good for: Organisations with strict data boundary requirements (regulated industries, audit, compliance mandates)

Quick Reference — Which Pattern Fits?

Scenario	Architecture
Getting started / low-sensitivity workloads	Arch 1 — No network setup, public endpoints accepted
Private log ingestion, analysts work anywhere	Arch 2 — AMPLS PrivateOnly ingestion, query mode open
Both ingestion and queries must be fully private	Arch 3 — Same as Arch 2 + query mode set to PrivateOnly

One thing all three share: Microsoft 365, Entra ID, and Defender connectors work in every pattern — they are server-side pulls by Sentinel and are not affected by your network posture.

Please feel free to reach out if you have any questions regarding the information provided.

Sentinel datalake: private link/private endpoint

munterweger — Mon, 23 Mar 2026 11:40:25 GMT

Has anyone already configured Sentinel Datalake with a private link/private endpoint setup? I can't find any instructions for this specific case.

Can I use the wizard in the Defender XDR portal, or does it require specific configuration steps?

Or does it require configuring a private link/private endpoint setup on the Datalake component after activation via the wizard?

RSAC 2026: What the Sentinel Playbook Generator actually means for SOC automation

Marcel_Graewer — Sun, 22 Mar 2026 12:22:31 GMT

RSAC 2026 brought a wave of Sentinel announcements, but the one I keep coming back to is the playbook generator. Not because it's the flashiest, but because it touches something that's been a real operational pain point for years: the gap between what SOC teams need to automate and what they can realistically build and maintain.

I want to unpack what this actually changes from an operational perspective, because I think the implications go further than "you can now vibe-code a playbook."

The problem it solves

If you've built and maintained Logic Apps playbooks in Sentinel at any scale, you know the friction. You need a connector for every integration. If there isn't one, you're writing custom HTTP actions with authentication handling, pagination, error handling - all inside a visual designer that wasn't built for complex branching logic. Debugging is painful. Version control is an afterthought. And when something breaks at 2am, the person on call needs to understand both the Logic Apps runtime AND the security workflow to fix it.

The result in most environments I've seen: teams build a handful of playbooks for the obvious use cases (isolate host, disable account, post to Teams) and then stop. The long tail of automation - the enrichment workflows, the cross-tool correlation, the conditional response chains - stays manual because building it is too expensive relative to the time saved.

What's actually different now

The playbook generator produces Python. Not Logic Apps JSON, not ARM templates - actual Python code with documentation and a visual flowchart. You describe the workflow in natural language, the system proposes a plan, asks clarifying questions, and then generates the code once you approve.

The Integration Profile concept is where this gets interesting. Instead of relying on predefined connectors, you define a base URL, auth method, and credentials for any service - and the generator creates dynamic API calls against it. This means you can automate against ServiceNow, Jira, Slack, your internal CMDB, or any REST API without waiting for Microsoft or a partner to ship a connector.

The embedded VS Code experience with plan mode and act mode is a deliberate design choice. Plan mode lets you iterate on the workflow before any code is generated. Act mode produces the implementation. You can then validate against real alerts and refine through conversation or direct code edits. This is a meaningful improvement over the "deploy and pray" cycle most of us have with Logic Apps.

Where I see the real impact

For environments running Sentinel at scale, the playbook generator could unlock the automation long tail I mentioned above. The workflows that were never worth the Logic Apps development effort might now be worth a 15-minute conversation with the generator. Think: enrichment chains that pull context from three different tools before deciding on a response path, or conditional escalation workflows that factor in asset criticality, time of day, and analyst availability.

There's also an interesting angle for teams that operate across Microsoft and non-Microsoft tooling. If your SOC uses Sentinel for SIEM but has Palo Alto, CrowdStrike, or other vendors in the stack, the Integration Profile approach means you can build cross-vendor response playbooks without middleware.

The questions I'd genuinely like to hear about

A few things that aren't clear from the documentation and that I think matter for production use:

Security Copilot dependency: The prerequisites require a Security Copilot workspace with EU or US capacity. Someone in the blog comments already flagged this as a potential blocker for organizations that have Sentinel but not Security Copilot. Is this a hard requirement going forward, or will there be a path for Sentinel-only customers?
Code lifecycle management: The generated Python runs... where exactly? What's the execution runtime? How do you version control, test, and promote these playbooks across dev/staging/prod? Logic Apps had ARM templates and CI/CD patterns. What's the equivalent here?
Integration Profile security: You're storing credentials for potentially every tool in your security stack inside these profiles. What's the credential storage model? Is this backed by Key Vault? How do you rotate credentials without breaking running playbooks?
Debugging in production: When a generated playbook fails at 2am, what does the troubleshooting experience look like? Do you get structured logs, execution traces, retry telemetry? Or are you reading Python stack traces?
Coexistence with Logic Apps: Most environments won't rip and replace overnight. What's the intended coexistence model between generated Python playbooks and existing Logic Apps automation rules?

I'm genuinely optimistic about this direction. Moving from a low-code visual designer to an AI-assisted coding model with transparent, editable output feels like the right architectural bet for where SOC automation needs to go. But the operational details around lifecycle, security, and debugging will determine whether this becomes a production staple or stays a demo-only feature.

Would be interested to hear from anyone who's been in the preview - what's the reality like compared to the pitch?

Ingest Microsoft XDR Advanced Hunting Data into Microsoft Sentinel

muraly005 — Wed, 18 Mar 2026 23:38:49 GMT

I had difficulty finding a guide that can query Microsoft Defender vulnerability management Advanced Hunting tables in Microsoft Sentinel for alerting and automation. As a result, I put together this guide to demonstrate how to ingest Microsoft XDR Advanced Hunting query results into Microsoft Sentinel using Azure Logic Apps and System‑Assigned Managed Identity.

The solution allows you to:

Run Advanced Hunting queries on a schedule
Collect high‑risk vulnerability data (or other hunting results)
Send the results to a Sentinel workspace as custom logs
Create alerts and automation rules based on this data

This approach avoids credential storage and follows least privilege and managed identity best practices.

Prerequisites

Before you begin, ensure you have:

Microsoft Defender XDR access
Microsoft Sentinel deployed
Azure Logic Apps permission
Application Administrator or higher in Microsoft Entra ID
PowerShell with Az modules installed
Contributor access to the Sentinel workspace

Architecture at a Glance

Logic App (Managed Identity)

↓

Microsoft XDR Advanced Hunting API

↓

Logic App

↓

Log Analytics Data Collector API

↓

Microsoft Sentinel (Custom Log)

Step 1: Create a Logic App

In the Azure Portal, go to Logic Apps
Create a new Consumption Logic App
Choose the appropriate:

Subscription
Resource Group
Region

Step 2: Enable System‑Assigned Managed Identity

Open the Logic App
Navigate to Settings → Identity
Enable System‑assigned managed identity
Click Save
Note the Object ID

This identity will later be granted permission to run Advanced Hunting queries.

Step 3: Locate the Logic App in Entra ID

Go to Microsoft Entra ID → Enterprise Applications
Change filter to All Applications

Search for your Logic App name
Select the app to confirm it exists

Step 4: Grant Advanced Hunting Permissions (PowerShell)

Advanced Hunting permissions cannot be assigned via the portal and must be done using PowerShell.

Required Permission

AdvancedQuery.Read.All

PowerShell Script

# Your tenant ID (in the Azure portal, under Azure Active Directory > Overview). $TenantID=”Your TenantID” Connect-AzAccount -TenantId $TenantID # Get the ID of the managed identity for the app. $spID = “Your Managed Identity” # Get the service principal for Microsoft Graph by providing the AppID of WindowsDefender ATP $GraphServicePrincipal = Get-AzADServicePrincipal -Filter "AppId eq 'fc780465-2017-40d4-a0c5-307022471b92'" | Select-Object Id # Extract the Advanced query ID. $AppRole = $GraphServicePrincipal.AppRole | ` Where-Object {$_.Value -contains "AdvancedQuery.Read.All"} # If AppRoleID comes up with blank value, it can be replaced with 93489bf5-0fbc-4f2d-b901-33f2fe08ff05 # Now add the permission to the app to read the advanced queries New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId $AppRole.Id # Or New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId 93489bf5-0fbc-4f2d-b901-33f2fe08ff05

After successful execution, verify the permission under Enterprise Applications → Permissions.

Step 5: Build the Logic App Workflow

Open Logic App Designer and create the following flow:

Trigger

Recurrence (e.g., every 24 hours

Run Advanced Hunting Query

Connector: Microsoft Defender ATP
Authentication: System‑Assigned Managed Identity
Action: Run Advanced Hunting Query

Sample KQL Query (High‑Risk Vulnerabilities)

Send Data to Log Analytics (Sentinel)

On Send Data, create a new connection and provide the workspace information where the Sentinel log exists. Obtaining the Workspace Key is not straightforward, we need to retrieve using the PowerShell command.

Get-AzOperationalInsightsWorkspaceSharedKey ` -ResourceGroupName "<ResourceGroupName>" ` -Name "<WorkspaceName>"

Configuration Details

Workspace ID
Primary key
Log Type (example): XDRVulnerability_CL
Request body: Results array from Advanced Hunting

Step 6: Run the Logic app to return results

In the logic app designer select run,

If the run is successful data will be sent to sentinel workspace.

Step 7: Validate Data in Microsoft Sentinel

In Sentinel, run the query:

XDRVulnerability_CL | where TimeGenerated > ago(24h)

If data appears, ingestion is successful.

Step 8: Create Alerts & Automation Rules

Use Sentinel to:

Create analytics rules for:

CVSS > 9
Exploit available
New vulnerabilities in last 24 hours

Trigger:

Email notifications
Incident creation
SOAR playbooks

Conclusion

By combining Logic Apps, Managed Identities, Microsoft XDR, and Microsoft Sentinel, you can create a powerful, secure, and scalable pipeline for ingesting hunting intelligence and triggering proactive detections.

Clarification on UEBA Behaviors Layer Support for Zscaler and Fortinet Logs

RohitN026 — Tue, 24 Feb 2026 16:54:36 GMT

I would like to confirm whether the new UEBA Behaviors Layer in Microsoft Sentinel currently supports generating behavior insights for Zscaler and Fortinet log sources.

Based on the documentation, the preview version of the Behaviors Layer only supports specific vendors under CommonSecurityLog (CyberArk Vault and Palo Alto Threats), AWS CloudTrail services, and GCP Audit Logs. Since Zscaler and Fortinet are not listed among the supported vendors, I want to verify:

Does the UEBA Behaviors Layer generate behavior records for Zscaler and Fortinet logs, or are these vendors currently unsupported for behavior generation? As logs from Zscaler and Fortinet will also be get ingested in CommonSecurityLog table only.

McasShadowItReporting / Cloud Discovery in Azure Sentinel

Felix87 — Tue, 17 Feb 2026 09:48:47 GMT

Hi!

I´m trying to Query the McasShadowItReporting Table, for Cloud App DISCOVERYs

The Table is empty at the moment, the connector is warning me that the Workspace is onboarded to Unified Security Operations Platform
So I cant activate it here

I cant mange it via https://security.microsoft.com/, too

The Documentation ( https://learn.microsoft.com/en-us/defender-cloud-apps/siem-sentinel#integrating-with-microsoft-sentinel )

Leads me to the SIEM Integration, which is configured for (for a while)

I wonder if something is misconfigured here and why there is no log ingress / how I can query them

CrowdStrike API Data Connector (via Codeless Connector Framework) (Preview)

logger2115 — Fri, 13 Feb 2026 17:04:32 GMT

API scopes created. Added to Connector however only streams observed are from Alerts and Hosts.

Detections is not logging? Anyone experiencing this issue? Github has post about it apears to be escalated for feature request.

CrowdStrikeDetections. not ingested

Anyone have this setup and working?

Salesforce Service Cloud (via Codeless Connector Framework)

logger2115 — Fri, 13 Feb 2026 16:53:06 GMT

We have 3 environments, does this connector support multiple tenants or is it limited to onle one FQDN?

Dedicated cluster for Sentinels in different tenants

de3no2 — Thu, 12 Feb 2026 08:47:30 GMT

Hello

I see that there is a possibility to use a dedicated cluster for a workspace in the same Azure region. What about workspaces that reside in different tenants but are in the same Azure region? Is that possible?

We are utilizing multiple tenants, and we want to keep this operational model. However, there is a central SOC, and we wonder if there is a possibility to utilize a dedicated cluster for cost optimization.

How Should a Fresher Learn Microsoft Sentinel Properly?

Arjun34 — Wed, 11 Feb 2026 02:38:02 GMT

Hello everyone,

I am a fresher interested in learning Microsoft Sentinel and preparing for SOC roles.

Since Sentinel is a cloud-native enterprise tool and usually used inside organizations, I am unsure how individuals without company access are expected to gain real hands-on experience.

I would like to hear from professionals who actively use Sentinel:

- How do freshers typically learn and practice Sentinel?

- What learning resources or environments are commonly used by beginners?

- What level of hands-on experience is realistically expected at entry level?

I am looking for guidance based on real industry practice.

Thank you for your time.

How do I import Purview Unified Audit Log data related to the use of the Audit Log into Sentinel?

BM-HV — Thu, 22 Jan 2026 09:29:43 GMT

Dear Community, I would like to implement the following scenario on an environment with Microsoft 365 E5 licenses:

Scenario: I want to import audit activities into an Azure Log Analytics workspace linked to Sentinel to generate alerts/incidents as soon as a search is performed in the Microsoft 365 Purview Unified Audit Log (primarily for IRM purposes).

Challenge: Neither the "Microsoft 365" connector, nor the "Defender XDR" or "Purview" (which appear to be exclusively Azure Purview) connectors are importing the necessary data.

Question: Which connector do I have to use in order to obtain Purview Unified Audit Log activities about the use of the Purview Unified Audit Log so that I can identify...

...which user conducted when an audit log search and with what kind of search query.

Thank you!

Issue connecting Azure Sentinel GitHub app to Sentinel Instance when IP allow list is enabled

JingleDingle — Fri, 16 Jan 2026 04:33:45 GMT

Hi everyone,

I’m running into an issue connecting the Azure Sentinel GitHub app to my Sentinel workspace in order to create our CI/CD pipelines for our detection rules, and I’m hoping someone can point me in the right direction.

Symptoms:

When configuring the GitHub connection in Sentinel, the repository dropdown does not populate.

There are no explicit errors, but the connection clearly isn’t completing.

If I disable my organization’s IP allow list, everything works as expected and the repos appear immediately.

I’ve seen that some GitHub Apps automatically add the IP ranges they require to an organization’s allow list. However, from what I can tell, the Azure Sentinel GitHub app does not seem to have this capability, and requires manual allow listing instead.

What I’ve tried / researched:

Reviewed Microsoft documentation for Sentinel ↔ GitHub integrations

Looked through Azure IP range and Service Tag documentation

I’ve seen recommendations to allow list the IP ranges published at //api.github.com/meta, as many GitHub apps rely on these ranges

I’ve already tried allow listing multiple ranges from the GitHub meta endpoint, but the issue persists

My questions:

Does anyone know which IP ranges are used by the Azure Sentinel GitHub app specifically?

Is there an official or recommended approach for using this integration in environments with strict IP allow lists?

Has anyone successfully configured this integration without fully disabling IP restrictions?

Any insight, references, or firsthand experience would be greatly appreciated. Thanks in advance!

How to Prevent Workspace Details from Appearing in LAQueryLogs During Cross-Workspace Queries

ParthPatel50 — Mon, 05 Jan 2026 14:09:29 GMT

I’ve onboarded multiple workspaces using Azure Lighthouse, and I’m running cross-workspace KQL queries using the workspace() function.
However, I’ve noticed that LAQueryLogs records the query in every referenced workspace, and the RequestContext field includes details about all other workspaces involved in the query.
Is there any way to run cross-workspace queries without having all workspace details logged in LAQueryLogs for each referenced workspace?

I'm stuck!

MrD — Mon, 08 Dec 2025 14:06:14 GMT

Logically, I'm not sure how\if I can do this.

I want to monitor for EntraID Group additions - I can get this to work for a single entry using this:

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Add member to group"
| where TargetResources[0].type == "User"
| extend GroupName = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue)))
| where GroupName == "NameOfGroup" <-- This returns the single entry
| extend User = tostring(TargetResources[0].userPrincipalName)
| summarize ['Count of Users Added']=dcount(User), ['List of Users Added']=make_set(User) by GroupName
| sort by GroupName asc

However, I have a list of 20 Priv groups that I need to monitor. I can do this using:

let PrivGroups = dynamic[('name1','name2','name3'});

and then call that like this:

blahblah

| where TargetResources[0].type == "User"
| extend GroupName = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue)))
| where GroupName has_any (PrivGroup)

But that's a bit dirty to update - I wanted to call a watchlist. I've tried defining with:

let PrivGroup = (_GetWatchlist('TestList'));

and tried calling like:

blahblah

I've tried dropping the let and attempted to lookup the watchlist directly:

| where GroupName has_any (_GetWatchlist('TestList'))

The query runs but doesn't return any results (Obvs I know the result exists) - How do I lookup that extracted value on a Watchlist.

Any ideas or pointers why I'm wrong would be appreciated!

Many thanks

Webinar Rescheduled: AI-Powered Entity Analysis in Sentinel's MCP Server

emilyfalla — Fri, 05 Dec 2025 00:50:30 GMT

Hi folks!

The webinar: AI-Powered Entity Analysis in Sentinel's MCP Server which was previously scheduled for: January 13th, 2026, has been rescheduled to: January 27th, 2026, at 9:00 AM PT.

Please delete the old invite from your calendar and find the new one at aka.ms/securitycommunity.

We apologize for the inconvenience and hope to see you there!

Understand New Sentinel Pricing Model with Sentinel Data Lake Tier

Aaida_Aboobakkar — Wed, 26 Nov 2025 12:43:46 GMT

Introduction on Sentinel and its New Pricing Model

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform that collects, analyzes, and correlates security data from across your environment to detect threats and automate response. Traditionally, Sentinel stored all ingested data in the Analytics tier (Log Analytics workspace), which is powerful but expensive for high-volume logs. To reduce cost and enable customers to retain all security data without compromise, Microsoft introduced a new dual-tier pricing model consisting of the Analytics tier and the Data Lake tier. The Analytics tier continues to support fast, real-time querying and analytics for core security scenarios, while the new Data Lake tier provides very low-cost storage for long-term retention and high-volume datasets. Customers can now choose where each data type lands—analytics for high-value detections and investigations, and data lake for large or archival types—allowing organizations to significantly lower cost while still retaining all their security data for analytics, compliance, and hunting.

Please flow diagram depicts new sentinel pricing model:

Now let's understand this new pricing model with below scenarios:

Scenario 1A (PAY GO)
Scenario 1B (Usage Commitment)
Scenario 2 (Data Lake Tier Only)

Scenario 1A (PAY GO)

Requirement

Suppose you need to ingest 10 GB of data per day, and you must retain that data for 2 years. However, you will only frequently use, query, and analyze the data for the first 6 months.

Solution

To optimize cost, you can ingest the data into the Analytics tier and retain it there for the first 6 months, where active querying and investigation happen. After that period, the remaining 18 months of retention can be shifted to the Data Lake tier, which provides low-cost storage for compliance and auditing needs. But you will be charged separately for data lake tier querying and analytics which depicted as Compute (D) in pricing flow diagram.

Pricing Flow / Notes

The first 10 GB/day ingested into the Analytics tier is free for 31 days under the Analytics logs plan.
All data ingested into the Analytics tier is automatically mirrored to the Data Lake tier at no additional ingestion or retention cost.
For the first 6 months, you pay only for Analytics tier ingestion and retention, excluding any free capacity.
For the next 18 months, you pay only for Data Lake tier retention, which is significantly cheaper.

Azure Pricing Calculator Equivalent

Assuming no data is queried or analyzed during the 18-month Data Lake tier retention period:

Although the Analytics tier retention is set to 6 months, the first 3 months of retention fall under the free retention limit, so retention charges apply only for the remaining 3 months of the analytics retention window. Azure pricing calculator will adjust accordingly.

Scenario 1B (Usage Commitment)

Now, suppose you are ingesting 100 GB per day. If you follow the same pay-as-you-go pricing model described above, your estimated cost would be approximately $15,204 per month.

However, you can reduce this cost by choosing a Commitment Tier, where Analytics tier ingestion is billed at a discounted rate. Note that the discount applies only to Analytics tier ingestion—it does not apply to Analytics tier retention costs or to any Data Lake tier–related charges.

Please refer to the pricing flow and the equivalent pricing calculator results shown below.

Monthly cost savings:
$15,204 – $11,184 = $4,020 per month

Now the question is: What happens if your usage reaches 150 GB per day?
Will the additional 50 GB be billed at the Pay-As-You-Go rate?

No. The entire 150 GB/day will still be billed at the discounted rate associated with the 100 GB/day commitment tier bucket.

Azure Pricing Calculator Equivalent (100 GB/ Day)

Azure Pricing Calculator Equivalent (150 GB/ Day)

Scenario 2 (Data Lake Tier Only)

Requirement

Suppose you need to store certain audit or compliance logs amounting to 10 GB per day. These logs are not used for querying, analytics, or investigations on a regular basis, but must be retained for 2 years as per your organization’s compliance or forensic policies.

Solution

Since these logs are not actively analyzed, you should avoid ingesting them into the Analytics tier, which is more expensive and optimized for active querying.
Instead, send them directly to the Data Lake tier, where they can be retained cost-effectively for future audit, compliance, or forensic needs.

Pricing Flow

Because the data is ingested directly into the Data Lake tier, you pay both ingestion and retention costs there for the entire 2-year period.
If, at any point in the future, you need to perform advanced analytics, querying, or search, you will incur additional compute charges, based on actual usage.
Even with occasional compute charges, the cost remains significantly lower than storing the same data in the Analytics tier.

Realized Savings

Scenario	Cost per Month
Scenario 1: 10 GB/day in Analytics tier	$1,520.40
Scenario 2: 10 GB/day directly into Data Lake tier	$202.20 (without compute) $257.20 (with sample compute price)

Scenario

Cost per Month

Scenario 1: 10 GB/day in Analytics tier

$1,520.40

Scenario 2: 10 GB/day directly into Data Lake tier

$202.20 (without compute)

$257.20 (with sample compute price)

Savings with no compute activity:
$1,520.40 – $202.20 = $1,318.20 per month
Savings with some compute activity (sample value):
$1,520.40 – $257.20 = $1,263.20 per month

Azure calculator equivalent without compute

Azure calculator equivalent with Sample Compute

Conclusion

The combination of the Analytics tier and the Data Lake tier in Microsoft Sentinel enables organizations to optimize cost based on how their security data is used. High-value logs that require frequent querying, real-time analytics, and investigation can be stored in the Analytics tier, which provides powerful search performance and built-in detection capabilities. At the same time, large-volume or infrequently accessed logs—such as audit, compliance, or long-term retention data—can be directed to the Data Lake tier, which offers dramatically lower storage and ingestion costs. Because all Analytics tier data is automatically mirrored to the Data Lake tier at no extra cost, customers can use the Analytics tier only for the period they actively query data, and rely on the Data Lake tier for the remaining retention. This tiered model allows different scenarios—active investigation, archival storage, compliance retention, or large-scale telemetry ingestion—to be handled at the most cost-effective layer, ultimately delivering substantial savings without sacrificing visibility, retention, or future analytical capabilities.