Lesson 7 — Microsoft Sentinel Data Connectors
Welcome to Module 2 of the Microsoft Sentinel Academy: Sentinel Operations.
The Foundation module explained what Sentinel is, how it connects to Defender XDR, how Log Analytics works, how incidents are structured and how analytics rules turn KQL into detection.
Now we move into the operational layer. Every Sentinel deployment depends on reliable telemetry, and that starts with data connectors.
What you will learn
This lesson explains how Sentinel receives security data and why connector planning matters before detections are built.
Learning objectives
After completing this lesson, you should understand how connectors bring telemetry into Sentinel.
- Explain what a Microsoft Sentinel data connector does.
- Understand how connectors populate tables in Log Analytics.
- Recognise the difference between Microsoft-native and third-party connectors.
- Understand why connector health matters.
- Know why connector planning affects analytics rules, incidents and hunting.
The problem this solves
Microsoft Sentinel cannot detect, investigate or report on data it never receives.
Data connectors solve that problem by bringing security telemetry into the Log Analytics workspace that Sentinel uses.
What is a data connector?
A data connector is the configuration that allows Microsoft Sentinel to receive logs and security signals from a source system. That source might be Microsoft Defender XDR, Microsoft Entra ID, Azure Activity, a firewall, a Linux server, a Syslog collector or a third-party security platform.
Do not think of connectors as a checkbox exercise. A connector is a decision about what evidence your SOC will have available during an investigation.
Connector flow
Connectors send data into Log Analytics tables. Sentinel then uses those tables for rules, incidents, workbooks, hunting and automation.
Microsoft-native connectors
Microsoft-native connectors are usually the first connectors enabled in a Microsoft security environment.
- Microsoft Defender XDR
- Microsoft Entra ID
- Azure Activity
- Microsoft Defender for Cloud
- Microsoft Defender for Endpoint
- Microsoft Defender for Office 365
Third-party connectors
Third-party connectors extend Sentinel beyond the Microsoft ecosystem.
- Firewalls and network security platforms
- VPN solutions
- Syslog sources
- Linux servers
- Cloud platforms
- Custom application logs
Connector health
A connector is only useful if data is flowing reliably.
Analysts and administrators should regularly check connector health, ingestion gaps, authentication problems and configuration warnings.
Tables matter
Each connector sends data to one or more tables. Those tables become the starting point for KQL queries.
If you do not know which table a connector populates, it becomes much harder to build analytics rules, workbooks and hunting queries.
Connector planning questions
| Question | Why it matters |
|---|---|
| What security question does this connector help answer? | Connectors should support investigation outcomes, not just collect logs. |
| Which tables will be populated? | Tables determine the KQL queries analysts can write. |
| How much data will be ingested? | Data volume affects Sentinel cost and retention planning. |
| How reliable is the source? | Unreliable data creates blind spots in detections and investigations. |
| Who owns the connector? | Operational ownership matters when data stops flowing. |
Real-world example
A Sentinel incident shows a suspicious sign-in from a foreign IP address. That is useful, but the SOC needs more context.
If VPN logs, firewall logs and Defender XDR data are connected, the analyst can determine whether the user connected remotely, whether the device behaved suspiciously and whether the IP was seen elsewhere.
Common mistake
A common mistake is enabling many connectors without understanding why the data is needed.
High-volume, low-value telemetry can increase cost and noise without improving investigations.
Agent Foskett investigation tip
Every connector should help the SOC answer a real investigation question. If a connector adds cost but does not improve detection, triage or response, review whether it belongs in the design.
What to document
Every production connector should have basic operational documentation.
- Data source owner
- Tables populated
- Expected ingestion volume
- Health monitoring approach
- Detection and workbook dependencies
Agent Foskett takeaway
Sentinel investigations are only as strong as the data available.
Data connectors decide what evidence reaches the SOC.
Good connector planning leads to better detections, cleaner incidents and faster investigations.
Related Agent Foskett learning
Continue learning
Microsoft Sentinel Data Connectors
Microsoft Sentinel data connectors bring Microsoft, Azure, Syslog, firewall, endpoint and third-party telemetry into Log Analytics so SOC analysts can build analytics rules, incidents, hunting queries, workbooks and automation.
Microsoft Sentinel Lesson 7
This Agent Foskett Microsoft Sentinel Academy lesson explains data connectors, connector health, tables, ingestion, Microsoft-native connectors, third-party connectors and Sentinel operations.
