Defender XDR Architecture for Enterprise: MDE, MDO, MDI and Sentinel

What XDR Means in the Microsoft Stack

Extended Detection and Response (XDR) is a security architecture that correlates telemetry across multiple control planes into a unified detection and response layer. In Microsoft's implementation, four products form the XDR plane:

• Defender for Endpoint (MDE) — endpoint telemetry, EDR, ASR, antivirus
• Defender for Office 365 (MDO) — email, Teams, SharePoint threat signals
• Defender for Identity (MDI) — on-premises Active Directory identity signals such as Kerberos, LDAP, and lateral movement activity
• Microsoft Sentinel — SIEM/SOAR aggregating all of the above plus third-party sources

These four feed into the Microsoft Defender XDR portal (security.microsoft.com), which correlates incidents across all surfaces. A single Sentinel analytics rule firing on an identity anomaly can be enriched with endpoint telemetry and email context in one unified incident view.

This is materially different from running four separate security products with separate dashboards. Done correctly, the correlation dramatically reduces mean time to detect and mean time to respond.

I deployed this architecture at Ericsson. Here is what actually matters.

Defender for Endpoint: Onboarding Methods

MDE onboarding is deceptively simple in the documentation. In practice, the method you choose has significant implications for scale, reliability, and maintenance.

Option 1 — Intune MDM (preferred for cloud-managed estates)

# Verify MDE onboarding status via Intune Graph
$deviceId = "your-device-object-id"
Get-MgDeviceManagementManagedDevice -ManagedDeviceId $deviceId |
    Select-Object DeviceName, ManagedDeviceOwnerType,
        @{N="MdeSensorStatus"; E={ $_.ConfigurationManagerClientHealthState }}

Intune deployment uses a Configuration Profile (Endpoint Detection and Response policy) to push the onboarding blob. The advantage: no scripts to manage, compliance reporting in Intune, and visibility into onboarding failures through device management.

Option 2 — Group Policy (for domain-joined, on-premises-heavy estates)

The onboarding blob is deployed via a GPO Computer Configuration policy. This was the method at Ericsson for legacy domain-joined endpoints before the Intune rollout was complete.

# Verify GPO-based onboarding locally on a device
Get-Service -Name Sense | Select-Object Status, StartType
# Should show: Running, Automatic

Option 3 — Script (for one-offs and staging)

The WindowsDefenderATPOnboardingScript.cmd from the MDE portal works for individual machines. Do not use this at scale — it generates separate onboarding events per device rather than policy-driven telemetry.

Onboarding validation at scale:

# Pull MDE onboarding status for all Intune-managed devices
Get-MgDeviceManagementManagedDevice -All |
    Where-Object { $_.OperatingSystem -eq "Windows" } |
    Select-Object DeviceName, LastSyncDateTime,
        @{N="IsOnboarded"; E={ $_.DeviceRegistrationState -eq "registered" }} |
    Where-Object { -not $_.IsOnboarded } |
    Export-Csv ".\not-onboarded.csv" -NoTypeInformation

EDR block mode — enable this only after confirming the existing AV is removed and MDE is in active mode. Block mode allows MDE to remediate threats even when a third-party AV is the primary solution, but it creates conflicts if both are active simultaneously.

ASR rules — always start in audit mode. Run for 30 days, review false positives, then move to block. The rules that cause the most false positives in enterprise environments:

• Block Office applications from creating executable content — conflicts with some macro-based workflows
• Block process creations originating from PSExec and WMI commands — breaks legitimate admin tooling
• Use advanced protection against ransomware — aggressive, test thoroughly

Defender for Office 365: Presets vs. Manual Policy

The short answer: use presets. The long answer explains why manual policies are a maintenance trap.

Preset security policies (Standard and Strict) are managed by Microsoft. When the threat landscape changes — new phishing techniques, new attachment delivery methods — Microsoft updates the presets. Your configuration follows automatically.

Manual policies require you to track those changes and update your config. In practice, they don't get updated. The policy you wrote in 2022 is still running in 2025 with 2022-era configurations.

# Verify which users are covered by preset policies
Get-EXOMailbox -ResultSize Unlimited | Select-Object UserPrincipalName |
    ForEach-Object {
        $upn = $_.UserPrincipalName
        $policy = Get-ATPProtectionPolicyRule | Where-Object {
            $_.SentTo -contains $upn -or
            $_.SentToMemberOf -contains (Get-MgUserMemberOf -UserId $upn -All |
                Select-Object -ExpandProperty AdditionalProperties).values
        }
        [PSCustomObject]@{ UPN = $upn; PolicyName = $policy.Name ?? "Default" }
    }

Priority accounts in MDO deserve special attention. These are accounts (executives, finance, HR) that receive a disproportionate volume of targeted phishing. Apply the Strict preset to these accounts and enable the priority account protection features in the Defender portal.

Defender for Identity: Domain Controller Sensor Deployment

MDI is frequently the last piece deployed and the most overlooked. It provides identity-centric telemetry that no other product in the stack can see: Kerberos traffic, LDAP queries, lateral movement, privilege escalation patterns.

Deployment pre-requisites:

• MDI workspace created in the Defender portal
• MDI service account created in AD with minimum required permissions
• TCP port 443 outbound from domain controllers to atp.azure.com

# Test MDI connectivity from a DC
Test-NetConnection -ComputerName "yourtenantname.atp.azure.com" -Port 443
# Expected: TcpTestSucceeded = True

Sensor installation on each DC:

The MDI sensor is installed directly on domain controllers — it is not an agentless deployment. The installer pulls the domain controller's configuration and starts forwarding NTLM hashes (one-way, for detection purposes only) and authentication events.

# Verify MDI sensor status on a domain controller
Get-Service -Name "AATPSensor" | Select-Object Status, StartType
# Check version
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\ATP Sensor").Version

High-value MDI detections at Ericsson:

• Suspicious Kerberos ticket requests (potential Golden Ticket attack)
• Lateral movement using Pass-the-Hash
• LDAP reconnaissance (large LDAP queries against sensitive OUs)
• Privilege escalation via AdminSDHolder manipulation

These detections surface in the Defender XDR portal as alerts correlated with the endpoint and email signals from MDE and MDO.

Connecting to Microsoft Sentinel

The XDR portal handles correlation within the Microsoft stack. Sentinel extends this to third-party sources, longer retention, and custom analytics.

Data connectors required for baseline XDR coverage:

Microsoft Defender XDR    → Single connector, pulls all four products
Microsoft Entra ID        → Sign-in logs, audit logs, Identity Protection
Azure Activity            → Azure management plane
Office 365                → Exchange, Teams, SharePoint activity logs

Priority analytics rules (Sentinel):

// Detect impossible travel (sign-in from two distant locations within 1 hour)
let threshold_km = 500;
SigninLogs
| where TimeGenerated > ago(1h)
| summarize
    Locations = make_set(Location),
    IPs = make_set(IPAddress),
    Count = count()
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
| project UserPrincipalName, Locations, IPs, Count

// MFA fatigue: multiple MFA prompts in short window
SigninLogs
| where AuthenticationRequirement == "multiFactorAuthentication"
| where ResultType in ("50074", "50076", "50079")  // MFA required, interrupted
| summarize MFAPrompts = count() by UserPrincipalName, bin(TimeGenerated, 30m)
| where MFAPrompts >= 5

Automation playbooks:

The highest-value automation at Ericsson was a playbook that:

1. Triggered on a high-confidence Sentinel incident (e.g., confirmed credential compromise)
2. Disabled the Entra ID account automatically
3. Revoked all active sessions
4. Posted to a Teams security channel with context
5. Created a ServiceNow incident for the SOC

This reduced response time from hours to seconds for the highest-severity incidents.

RBAC and Role Scopes Across the Stack

XDR RBAC in the Microsoft Defender portal is separate from Entra ID roles. Define it explicitly — the default inheritance from Global Admin is not appropriate for operations teams.

Role model for a security operations team:

| Role | Scope | Permissions | |---|---|---| | Security Reader | All devices | Read-only across all portals | | Security Analyst | Assigned device groups | Investigate, respond to alerts | | Security Engineer | All devices | Manage policies, onboard devices | | SOC Manager | All | Full access except role management |

# Create a Defender device group for a subsidiary
New-MgSecurityDeviceGroup -DisplayName "Subsidiary-EMEA" `
    -RuleType "manual" `
    -DeviceGroupMembers @("device-id-1","device-id-2")

At Ericsson, we used device groups to scope RBAC by geography. Each regional SOC analyst could see and respond to alerts for devices in their region without access to the global estate.

Key Design Decisions in a Microsoft XDR Programme

The architecture is not just a tooling question. The quality of the programme depends on a few explicit decisions:

• Which portal is authoritative for triage? If analysts pivot between Defender XDR and Sentinel without a defined workflow, incident ownership becomes slow.
• What is the minimum viable connector set? Incomplete ingestion creates false confidence because the incident queue looks clean while whole attack paths remain invisible.
• Where does automation stop? Automatic disablement, isolation, and session revocation should be tied to high-confidence detections only.
• How is identity treated inside the response model? If Entra ID risk, Conditional Access, PIM, and MDI are not part of the same design conversation, the response model remains endpoint-centric and incomplete.

These are governance choices as much as technical ones. Without them, the platform generates telemetry but not dependable operational outcomes.

Common Reasons XDR Deployments Underperform

Most weak Defender XDR deployments fail in the same ways:

• Sensors are onboarded, but policies are not mature. Telemetry without ASR, tamper protection, device control, or strong email controls produces alerting without prevention.
• Sentinel is connected, but analytics are generic. Default rules are a starting point, not a finished SOC content set.
• MDI is deployed late or not fully scoped. That leaves privilege escalation and lateral movement visibility weaker than expected.
• RBAC is inherited from tenant admin habits. Analysts either get too much access or too little to act effectively.

The result is usually an expensive security stack with weak detection engineering and unclear ownership between security operations, identity, and endpoint teams.

What to Validate Before Declaring the Platform Live

Before calling the XDR programme operational, validate:

• device onboarding coverage and sensor health by geography and business unit
• MDO preset scope, priority-account coverage, and mailbox hygiene assumptions
• MDI sensor health on every in-scope domain controller
• Sentinel data connector health, retention, and analytics tuning
• playbook logic, approvals, and rollback for high-confidence automated actions

If those checks are incomplete, the right conclusion is not "mostly done". It is that the platform is still in build phase.

Recommended First 90 Days

For most enterprise programmes, the first 90 days should prioritise platform discipline over dashboard ambition:

1. Stabilise onboarding and sensor health.
2. Confirm prevention baselines in MDE and MDO.
3. Tune a small number of high-value Sentinel rules and playbooks.
4. Set RBAC and incident ownership before expanding the content set.

Teams that skip those basics usually end up with more telemetry than they can trust and more alerts than they can action.

Deploying the Defender XDR stack without a defined RBAC model and analytics baseline produces data without insight. Book a discovery call to design your XDR architecture.

Carlos AnnesSenior Microsoft 365 / Hybrid Architect10+ years designing and securing enterprise Microsoft infrastructure.