2.2.1. Selecting Data Connectors
💡 First Principle: The right connector is determined by the source, not by preference: where the data originates and what interface it exposes decides how it can reach the workspace. Match the source type to the connector family first, then refine by cost and scale.
Connectors are delivered through Content hub solutions. Installing a solution brings its connector plus related analytics rules, workbooks, hunting queries, and parsers. You then open the connector page and configure it. The families behave differently:
| Source | Connector family | How data arrives | Typical table |
|---|---|---|---|
| Defender XDR, Entra ID, Azure Activity, Microsoft 365 | Service-to-service | Microsoft cloud to workspace directly (or by diagnostic settings) | Product tables, SigninLogs, AzureActivity, OfficeActivity |
| Windows servers and workstations | Agent-based: Windows Security Events via AMA | AMA on each machine, scoped by DCR | SecurityEvent |
| Windows events centralized with WEF | Agent-based: Windows Forwarded Events | AMA on the Windows Event Collector | WindowsEvent |
| Linux machines, network devices, firewalls | Agent-based: Syslog via AMA, CEF via AMA | Linux forwarder running AMA | Syslog, CommonSecurityLog |
| Third-party SaaS APIs | API-based (often Codeless Connector Framework) | Sentinel polls the vendor API | Vendor-specific _CL tables |
| Threat intelligence | TI connectors or upload API | TAXII feed, Microsoft TI, or API | ThreatIntelIndicators, ThreatIntelObjects |
| Anything custom | Logs Ingestion API or AMA custom logs | Your code or the agent posts data through a DCR | Custom _CL table |
For Windows logs, the decision is mostly about which events and how many machines. Security event logs (logon events, process creation if auditing is enabled, privileged operations) are the core detection source. Domain controllers are the highest-value Windows source because authentication and Kerberos events concentrate there. Non-Azure machines (on-premises or other clouds) need Azure Arc so AMA can be deployed and managed on them through Azure.
Prefer a native connector over a generic one whenever both exist. A firewall that has a dedicated CEF solution gets parsers, rules, and workbooks for free; dumping the same data into generic Syslog leaves you to build all of that.
⚠️ Exam Trap: Non-Azure Windows and Linux machines must be Azure Arc-enabled before AMA-based connectors can collect from them. "Install AMA directly on on-premises servers with no Azure registration" is not the supported path.
Reflection Question: Your organization has Defender for Endpoint on every Windows device. Why might you still ingest Windows Security events from domain controllers into Sentinel, and what would you deliberately not collect from every workstation to control cost?