Defender XDR + Microsoft Sentinel
Native Defender XDR connector unified with Microsoft Sentinel for cross-pillar incident correlation and automation-first investigation.
Difficulty
Advanced
Environment
Microsoft 365 Business Premium / Azure
Deployment
Home Lab
Est. Implementation
1 day
Executive Summary
This project unified Microsoft Defender XDR with Microsoft Sentinel to close the visibility gap left by the siloed identity, device and email controls built in earlier projects, giving a single pane of glass for detection, investigation and response.
A Log Analytics workspace was provisioned and Microsoft Sentinel enabled, then the native Defender XDR connector (v3.0.12) was installed from Content Hub to stream incidents and alerts from Defender for Endpoint, Defender for Office 365 and Defender for Identity into one workspace.
Validation traced a real signal end-to-end: a user-reported phishing simulation from the email security project surfaced as a Defender for Office 365 alert, was auto-investigated by Defender XDR, and closed as a Low-severity Sentinel incident in 14 minutes with zero manual analyst actions (MTTA: 0 min).
Business Problem
Microsoft 365 Business Premium generates security signals across Defender for Endpoint, Defender for Office 365, Defender for Identity and Entra ID, but each product surfaces alerts in its own console with no shared incident history.
Without a unified SIEM, attack chains spanning multiple pillars remain invisible, SOC analysts must pivot across separate consoles to correlate signals manually, and there is no centralised, audit-ready incident record for compliance or post-incident review.
Business Risks
- Cross-pillar attack chains going undetected because signals are never correlated
- Analyst time consumed pivoting between separate Defender and Entra consoles
- No centralised audit trail of incidents, classifications and resolution timelines
- Alert fatigue from low-value alerts that are never automatically triaged
Compliance Concerns
- Centralised security incident logging for audit and post-incident review
- SOC governance reporting (MTTA/MTTC) as evidence of operational maturity
Solution Overview
Provisioned a dedicated Log Analytics workspace (sentinal) and enabled Microsoft Sentinel as the cloud-native SIEM on top of it.
Installed the Microsoft Defender XDR solution (v3.0.12) from Sentinel's Content Hub and connected it as a native, agentless, bi-directional connector alongside Defender for Identity and Defender for Office 365 (Preview).
Enabled built-in Defender XDR analytics rules and validated automated investigation and remediation end-to-end using a real cross-project alert, confirming incidents and MTTA/MTTC metrics land correctly in Sentinel.
Architecture
Architecture diagram placeholder
Technology Stack
Microsoft Sentinel
Cloud-native SIEM for log ingestion, analytics rules and incident management
Log Analytics Workspace
Underlying data store (sentinal) for all ingested security logs
Microsoft Defender XDR Connector
Native bi-directional connector (v3.0.12), no agents or API keys required
Defender for Office 365
Email threat signal source (MDO alerts)
Defender for Identity
Identity-based threat signal source
Analytics Rules
Scheduled KQL queries generating incidents from ingested signals
Automated Investigation & Remediation
Resolves low-risk alerts without analyst action
Lab Environment
- Tenant
- Patchthecloud.onmicrosoft.com
- Workspace name
- sentinal
- Connector version
- Microsoft Defender XDR v3.0.12
- License
- Microsoft 365 Business Premium
- Lab date
- January 2026
Implementation
A phased, expandable walkthrough. Screenshots and evidence can be attached to each phase.
Create the Log Analytics workspace and enable Microsoft Sentinel on top of it.
- Create a Log Analytics Workspace (sentinal) in the Azure subscription
- Enable Microsoft Sentinel against the new workspace
- Confirm the Sentinel Overview blade loads with no data sources connected yet
Screenshots for this phase can be added here.
PowerShell
Illustrative example snippets — copy or download each script. Production values are placeholders.
Deploy the Sentinel workspace and export incident/alert reports
# Deploy Log Analytics workspace and enable Microsoft Sentinel
.\New-SentinelWorkspace.ps1 -WorkspaceName "sentinal" -ResourceGroup "rg-security" -Location "eastus"
# Export all incidents with severity, status, MTTA and MTTC via Microsoft Graph API
.\Get-SentinelIncidentReport.ps1 -WorkspaceName "sentinal" -Days 30
# Retrieve all Defender XDR alerts with investigation state and resolution
.\Get-DefenderXDRAlerts.ps1 -ProviderName "Microsoft Defender XDR"Configuration Screenshots
Click any tile to open the lightbox. Real screenshots will replace these placeholders.
Phase 1
Phase 2
Phase 3
Phase 4
Phase 5
Validation
Workspace & Sentinel Enabled
Log Analytics workspace (sentinal) created and Microsoft Sentinel enabled successfully.
Connector Installed
Defender XDR solution v3.0.12 installed from Content Hub and connected — no agents or keys required.
Data Ingestion Confirmed
SecurityIncident and SecurityAlert KQL queries return Defender XDR data.
Analytics Rules Active
Built-in rules enabled plus one custom KQL detection rule for incident count by severity.
Incident Auto-Closed
1 incident (Low severity) auto-investigated and closed with MTTA 0 min and MTTC 14 min.
Cross-Project Traceability
MDO 'reported phish' alert traced back to the Attack Simulation Training project, confirming end-to-end signal flow.
Zero Analyst Interventions
0 manual remediation actions were required across the validated lab period.
Challenges
Permanent workspace naming
The Log Analytics workspace name (sentinal) cannot be renamed after creation, so naming had to be validated carefully before enabling Sentinel.
Content Hub install order
The Defender XDR solution must be installed from Content Hub before it can be activated in Data Connectors — attempting the reverse order does not work.
Lessons Learned
- Workspace naming is permanent — always validate spelling before enabling Sentinel on a Log Analytics workspace.
- Content Hub vs Data Connectors — install the solution from Content Hub first, then activate the connector; the reverse order fails.
- A 0-minute MTTA is a success metric, not a data gap — it should be communicated as evidence of automation maturity.
- An empty incidents list over 30 days is a valid lab outcome — document it explicitly so it doesn't read as an unconfigured environment.
- Cross-project signal traceability (an alert from one project surfacing as a Sentinel incident from another) is a strong portfolio differentiator.
Business Impact
0 min
Mean Time to Acknowledge
14 min
Mean Time to Close
0
Analyst Interventions
1 / 1 (100%)
Incidents Auto-Closed
Skills Demonstrated
Related Certifications
Certifications this project maps to are highlighted.
Related Blog Articles
Placeholder cards — future TechCertGuide integration.
GitHub Repository
lokeshm-it/Defender-XDR-Microsoft-Sentinel
PublicNative Microsoft Defender XDR integration with Microsoft Sentinel — unified SIEM ingestion, analytics rules and automation-first incident response.
Download Center
Project Case Study
PDF · Available soon
Architecture Diagram
PDF · Available soon
PowerShell Scripts
ZIP · Available soon
Technical Documentation
PDF · Available soon