Azure Sentinel Connectors: What Actually Works in Production

The first week after a Sentinel deployment almost always looks the same. Dashboards are empty, analytics rules are firing on nothing, and the ticket says "connectors configured." Configured is doing a lot of work in that sentence. The difference between a connector that is configured and one that is actually ingesting clean, queryable data is where most detection programs stall before they start.

This note covers the connector landscape as of mid-2026, the AMA migration that still trips teams up, and the KQL you need to verify your data plane is healthy before you write a single detection rule.

The Connector Taxonomy Is Not Flat

Microsoft groups connectors into four rough buckets, and treating them as equivalent gets you into trouble fast.

First-party Microsoft connectors (Azure AD, Defender XDR, Entra ID, Office 365, Defender for Cloud) connect via the built-in data plane. You toggle them on in the Content Hub, authorize the workspace, and data flows within minutes. The catch is that many of these produce their data in the SecurityAlert or SecurityIncident tables, not the raw telemetry tables. If you want SigninLogs or AuditLogs you still need the Entra ID connector enabled separately, and it routes to different tables with different billing implications.

Azure Monitor Agent (AMA) connectors are now the standard path for anything that runs on a VM: Windows Security Events, Linux Syslog, and most on-prem log sources. AMA uses Data Collection Rules (DCRs) to filter and route logs before they hit the workspace, which is a meaningful cost lever if you use it.

CEF/Syslog connectors cover network gear, firewalls, and third-party appliances. These still route through a Linux forwarder VM (ideally dedicated, not shared with other workloads). The forwarder runs the AMA and a custom DCR maps the incoming syslog stream into CommonSecurityLog.

Custom/REST connectors cover anything else: SaaS APIs, proprietary log formats, things you ingest via Logic Apps or custom data ingestion endpoints (the Logs Ingestion API replaced the old HTTP Data Collector API in 2023).

The MMA Deprecation Is Not Hypothetical

The legacy Microsoft Monitoring Agent (MMA, also called the OMS agent) reached end-of-support in August 2024. If you still have workspaces receiving data via MMA, that data is flowing through an unsupported agent with no security patches. We have seen environments where MMA and AMA are running side by side on the same host, ingesting duplicate events into the same table. Your cost doubles and your detections start alerting on everything twice.

Check your exposure:

Heartbeat
| where TimeGenerated > ago(7d)
| summarize LastHeartbeat = max(TimeGenerated), AgentVersion = any(Version)
    by Computer, Category, OSType
| where Category == "Direct Agent"
| project Computer, OSType, AgentVersion, LastHeartbeat
| order by LastHeartbeat asc

The Category == "Direct Agent" filter surfaces MMA-sourced heartbeats. Anything in that result set needs an AMA migration and the old agent uninstalled. Running both is not a safe interim state.

DCRs Are the Feature Most Teams Skip

Data Collection Rules are the configuration objects that tell AMA what to collect and where to send it. Most teams configure a DCR once during the initial connector setup and never revisit it. That is leaving money on the table and sometimes leaving gaps in coverage.

A DCR has two levers that matter for Sentinel:

Data sources define what events to collect. For Windows Security Events, you can select the Common, Minimal, or All preset, or write an XPath filter to collect specific event IDs. The All preset on a busy Windows host can run 2-5 GB/day per machine. Filtering to your detection-relevant event IDs before the data leaves the host is how you stay under budget.

Destinations define which workspace receives the data. A single DCR can fan out to multiple workspaces, which matters for multi-tenant architectures where you want events in both a central SOC workspace and a per-team workspace.

Here is a minimal DCR in Bicep that scopes Windows Security Events to a targeted XPath filter covering logon, process creation, and privilege use:

resource dcr 'Microsoft.Insights/dataCollectionRules@2022-06-01' = {
  name: 'dcr-sentinel-windows-targeted'
  location: location
  properties: {
    dataSources: {
      windowsEventLogs: [
        {
          name: 'windowsSecurityEvents'
          streams: ['Microsoft-SecurityEvent']
          xPathQueries: [
            'Security!*[System[(EventID=4624 or EventID=4625 or EventID=4648)]]'
            'Security!*[System[(EventID=4688)]]'
            'Security!*[System[(EventID=4672 or EventID=4673 or EventID=4674)]]'
          ]
        }
      ]
    }
    destinations: {
      logAnalytics: [
        {
          workspaceResourceId: workspaceId
          name: 'sentinel-workspace'
        }
      ]
    }
    dataFlows: [
      {
        streams: ['Microsoft-SecurityEvent']
        destinations: ['sentinel-workspace']
      }
    ]
  }
}

This targets the three event clusters that cover 80% of detection use cases for lateral movement and privilege escalation while dropping the noise from Kerberos ticket churn and policy audits that most environments generate in bulk.

CEF Forwarder Configuration Is Where Things Break Quietly

The CEF connector path is: appliance -> syslog -> Linux forwarder -> AMA -> Sentinel. Each handoff can fail silently.

The forwarder VM needs AMA installed, the ama-tls-certificate-management service healthy, and the DCR for CEF attached to the machine's managed identity. We have seen firewalls configured to send CEF over port 514 UDP while the forwarder is listening on 514 TCP. Both sides report "connected." Nothing arrives.

Verify end-to-end with a test message, then query:

CommonSecurityLog
| where TimeGenerated > ago(1h)
| summarize EventCount = count(), LastEvent = max(TimeGenerated)
    by DeviceVendor, DeviceProduct, CollectorHostName
| order by EventCount desc

If CollectorHostName is empty or the count flatlines during a known-active period on your firewall, the forwarder is the first place to look. Check /var/log/syslog on the forwarder for AMA errors before touching any Sentinel settings.

Table-Level Cost Hygiene Before You Go Live

Sentinel billing is workspace ingestion billing. Every byte you send to a Log Analytics table in a Sentinel workspace is billable. The most common cost shock comes from three sources:

• AMA collecting Windows Event logs at All instead of a filtered XPath
• CEF forwarders receiving verbose access logs from load balancers (thousands of events per minute, negligible detection value)
• Entra ID's AADNonInteractiveUserSignInLogs table, which can run 10-20x the volume of interactive sign-ins in large tenants

Before you commit to a pricing tier, run a 48-hour ingestion baseline with the workspace in pay-as-you-go mode and query Usage to see per-table volume:

Usage
| where TimeGenerated > ago(2d)
| summarize TotalGB = round(sum(Quantity) / 1024, 2)
    by DataType
| order by TotalGB desc
| take 20

Then make the commitment tier decision with real numbers, not vendor estimates. The 100 GB/day commitment tier (currently around $196/day as of Q2 2026) breaks even against pay-as-you-go at roughly 85 GB/day factoring in the Microsoft Sentinel workspace benefit.

Connector Health Is a First-Class Detection Surface

A disconnected connector is an attacker opportunity. If your firewall CEF feed drops for six hours and no one notices, that is six hours of blind spot. Build connector health into your detection posture from day one.

let expectedSources = datatable(DeviceVendor: string, MaxGapMinutes: int)
[
    "Palo Alto Networks", 15,
    "Cisco", 15,
    "Check Point", 30,
];
CommonSecurityLog
| where TimeGenerated > ago(4h)
| summarize LastEvent = max(TimeGenerated) by DeviceVendor
| join kind=rightouter expectedSources on DeviceVendor
| extend GapMinutes = datetime_diff('minute', now(), LastEvent)
| where GapMinutes > MaxGapMinutes or isnull(LastEvent)
| project DeviceVendor, LastEvent, GapMinutes, MaxGapMinutes

This runs as a scheduled analytics rule at 30-minute frequency. When a source goes quiet beyond its expected cadence, you get an incident before you have a gap in coverage. Wire the alert to a Logic App that pages the on-call engineer and posts to the SOC channel.

Next Steps

If you are designing a Sentinel connector architecture for a new deployment or auditing an existing one that has drifted, our detection engineering practice covers the full pipeline from connector configuration through detection rule lifecycle, and we are available at /contact to scope an engagement.