M365 Defender Data Connectors

Microsoft 365 Defender data connectors are the integration points that allow Microsoft Sentinel to ingest security data from Microsoft 365 Defender services. Microsoft 365 Defender is a unified pre- and post-breach enterprise defense suite that coordinates protection across:

Each of these services generates alerts and, in some cases, raw event data. The connectors bridge these services to Sentinel, enabling cross-domain correlation, unified incident management, and automated response using playbooks.

All M365 Defender connectors operate via the diagnostic settings mechanism of the underlying Azure resources or via direct API integration. The key architectural point is that data flows from the M365 Defender service to Sentinel through an Azure Event Hubs namespace or directly via the Log Analytics API under the hood. When you enable a connector, Sentinel creates a data collection rule (DCR) or a diagnostic setting that routes specified logs and events to the Sentinel workspace.

For example, the Microsoft Defender for Endpoint connector uses the MicrosoftGraphSecurity API to fetch alerts. Sentinel polls the API every 5 minutes (default) for new alerts and ingests them into the SecurityAlert table with the provider name MicrosoftDefenderForEndpoint. However, if you want streaming raw events (like device logons, process creation), you must enable the Microsoft Defender for Endpoint raw events connector which uses the Advanced Hunting API. This connector streams data into tables like DeviceEvents, DeviceLogonEvents, DeviceProcessEvents, etc. The raw events connector is billed separately based on data volume.

For Microsoft Defender for Office 365, the connector ingests alerts and email events. The Office 365 connector (now part of the M365 Defender umbrella) uses the Office 365 Management Activity API to fetch audit logs and threat detection data. It populates tables like EmailEvents, EmailUrlInfo, EmailAttachmentInfo, and OfficeActivity. The connector can be configured to ingest only specific record types (e.g., Exchange, SharePoint, Teams).

Microsoft Defender for Identity alerts are ingested via the Microsoft 365 Defender connector (unified) or the legacy Azure ATP connector. The current recommended method is to use the Microsoft 365 Defender connector, which pulls alerts from the unified M365 Defender portal. This connector ingests alerts into the SecurityAlert table with provider name MicrosoftDefenderForIdentity.

Microsoft Defender for Cloud Apps feeds alerts and cloud discovery logs via the Microsoft 365 Defender connector as well. Additionally, there is a dedicated Microsoft Defender for Cloud Apps connector that pulls shadow IT discovery data and alerts. The connector uses the Defender for Cloud Apps API and populates SecurityAlert and McasShadowItReporting tables.

Microsoft Purview connectors (for DLP, insider risk) are also part of the M365 Defender ecosystem. They use the Office 365 Management Activity API and the Microsoft 365 Compliance Center to ingest DLP alerts and insider risk alerts into SecurityAlert and OfficeActivity tables.

While most configuration is done via the Azure portal, you can use PowerShell or Azure CLI for automation. Example PowerShell to enable Microsoft Defender for Endpoint alerts connector:

$workspace = Get-AzOperationalInsightsWorkspace -Name "YourWorkspace" -ResourceGroupName "YourRG"
$workspaceId = $workspace.CustomerId

# Enable Microsoft Defender for Endpoint connector (alerts)
Add-AzSentinelDataConnector -ResourceGroupName "YourRG" -WorkspaceName "YourWorkspace" -DataConnectorId "MicrosoftDefenderForEndpoint" -DataConnectorKind "MicrosoftDefenderForEndpoint"

To verify connector status:

Get-AzSentinelDataConnector -ResourceGroupName "YourRG" -WorkspaceName "YourWorkspace"

For raw events, you must enable the Microsoft 365 Defender connector (unified) or configure diagnostic settings in the M365 Defender portal. The unified connector is enabled via:

Add-AzSentinelDataConnector -ResourceGroupName "YourRG" -WorkspaceName "YourWorkspace" -DataConnectorId "MicrosoftThreatProtection" -DataConnectorKind "MicrosoftThreatProtection"

To verify data ingestion, query the SecurityIncident table:

SecurityIncident
| where ProviderName == "Microsoft 365 Defender"
| take 10

You can monitor connector health using the ConnectorHealth table (preview). Query:

ConnectorHealth
| where ConnectorName contains "Microsoft 365 Defender"
| project TimeGenerated, ConnectorName, Status, Description
| order by TimeGenerated desc

If a connector shows Error, common causes:

| Connector | Data Type | Tables | Cost | |-----------|-----------|--------|------| | Microsoft 365 Defender (unified) | Alerts & Incidents | SecurityAlert, SecurityIncident | Free | | Microsoft Defender for Endpoint (raw events) | Raw events | DeviceEvents, DeviceLogonEvents, etc. | Billable | | Microsoft Defender for Office 365 | Email events, alerts | EmailEvents, EmailUrlInfo, SecurityAlert | Billable (email events free? No, billable) | | Microsoft Defender for Identity | Identity alerts | SecurityAlert | Free | | Microsoft Defender for Cloud Apps | Alerts, discovery logs | SecurityAlert, McasShadowItReporting | Free for alerts, billable for discovery |

Note: The exam may ask which tables are populated by which connector. For instance, DeviceEvents comes from MDE raw events, not from the unified connector.

Objective 2.1: Connect Microsoft services to Microsoft Sentinel. This includes:

Expect 2–3 questions on this chapter. Questions often present a scenario (e.g., "You need to ingest email security events and correlate with endpoint alerts") and ask which connectors to enable.

A large financial institution uses Microsoft 365 Defender and Sentinel for security operations. They receive a phishing email alert from MDO. The SOC analyst wants to see which endpoints the user accessed after clicking the link. With the Microsoft 365 Defender unified connector, the alert is in Sentinel as an incident. However, to see endpoint raw events, they need the Microsoft Defender for Endpoint raw events connector enabled. Without it, the analyst has to jump to the MDE portal manually. In production, the raw events connector is configured to ingest DeviceNetworkEvents and DeviceProcessEvents. The SOC uses analytics rules that cross-join EmailEvents (from Office 365 connector) with DeviceNetworkEvents to detect lateral movement. The connector is configured with a 30-day retention for raw events to manage costs. A common misconfiguration is enabling the unified connector but forgetting the raw events connector, leading to incomplete investigations. The solution: use Azure Policy to deploy both connectors together.

A technology company wants to detect data exfiltration by employees. They use Microsoft Purview DLP alerts and Microsoft Defender for Cloud Apps for shadow IT discovery. They enable the Microsoft 365 Defender connector for alerts and the Microsoft Defender for Cloud Apps connector for discovery logs. In production, they ingest McasShadowItReporting to identify unsanctioned cloud apps. They also use the Office 365 connector to monitor OfficeActivity for suspicious file downloads. The connectors are configured with a 90-day retention. Performance consideration: the McasShadowItReporting table can generate large volumes, so they apply a daily cap on the workspace. A common issue is that the connector appears connected but no data flows because the Defender for Cloud Apps license is not assigned to all users. The fix: assign appropriate licenses and verify the connector's data sources in the Defender for Cloud Apps portal.

A managed security service provider (MSSP) manages multiple tenants. They use Sentinel in a central workspace with multiple data connectors per tenant. They enable the Microsoft 365 Defender unified connector for each tenant to get consolidated incidents. They also enable individual component connectors for raw events on a per-tenant basis. The challenge is managing connector health across tenants. They use the ConnectorHealth table and Azure Monitor alerts to notify when a connector disconnects. A common failure: the service principal used for the connector expires, causing all connectors to fail. The solution: use managed identities where possible and set up renewal reminders. The exam may test that connector health is checked via the portal or the ConnectorHealth table.