Forward the downpipes audit trail to Microsoft Sentinel

Microsoft Sentinel collects the downpipes audit trail by pulling it, not by receiving a push. Sentinel’s Logs Ingestion API wants Entra OAuth2 and a Data Collection Rule rather than a static auth header, so a header-based push cannot reach it. Instead you deploy the downpipes Codeless connector, an ARM template shipped in the engine repo under integrations/microsoft-sentinel/, into your own Azure workspace. It polls the engine’s audit feed at /support/audit-feed with a bearer token and pages forward using the feed’s nextAfterSeq cursor, landing events in a custom DownpipesAudit_CL table. No CEF is involved.

Because Sentinel’s poller dials in to your engine, a Cloudflare Access perimeter on your console hostname does block it until you add an exemption for the feed path (a service token or a narrow path bypass). This is the opposite of the push connectors, where the engine dials out and Access never sees the request. For the cursor, chain-continuity checks and the Access options in full, see wiring the audit feed into your SIEM.

What you need

• An Azure Log Analytics workspace with Microsoft Sentinel already enabled on it.
• The Azure CLI, logged in, with the target subscription selected.
• Enough RBAC on the resource group to create a Data Collection Endpoint, a Data Collection Rule, a custom table and the Sentinel connector resources.
• An owner-minted audit-feed bearer credential from the downpipes console.

Set it up

1. In the downpipes console, mint the feed credential: open Integrations, choose the Microsoft Sentinel tile, and mint the audit-feed credential there (owner-only). Copy the bearer value shown once; the engine keeps only a hash of it.
2. Get the connector package from the engine repo under integrations/microsoft-sentinel/ (the ARM template mainTemplate.json and the example parameters files).
3. From that directory, deploy with the Azure CLI, passing your workspace name, the engine hostname (no scheme) and the bearer token. For anything beyond a one-off test, pass the token through a parameters file rather than on the command line:

az deployment group create \
  --resource-group <your-resource-group> \
  --template-file mainTemplate.json \
  --parameters workspaceName="<your-sentinel-workspace>" \
  --parameters apiHost="<engine-hostname-no-scheme>" \
  --parameters bearerToken="<paste-the-minted-bearer-token>"

4. If your engine hostname is fronted by Cloudflare Access, add an exemption for the feed path so the poller gets through: a Cloudflare Access service token (sent as two extra headers) or a narrow Bypass on /support/*. The connector README shows both, and the feed page explains the trade-off.
5. Give the connector a few minutes for its first poll, then confirm events are landing (below).

What lands in Sentinel

Events land in a custom Log Analytics table, DownpipesAudit_CL, with the audit fields as columns (seq, ts mapped to TimeGenerated, actorEmail, actorSubject, actorMethod, sourceIp, action, outcome, target, prevHash, hash). Confirm with a query:

DownpipesAudit_CL
| take 10

You should see rows with the audit fields and a populated TimeGenerated. Back in the console, the SIEM audit feed card’s pull trail records each poll, so you can see Sentinel reaching the engine.

Good to know

• This is pull, so Cloudflare Access matters. Unlike the push connectors, Sentinel dials in to your engine; if Access fronts the hostname, add a service token or a narrow path bypass for /support/*, or the poll is turned away before the bearer is even checked.
• The bearer defaults to 90 days and can be minted for up to 365. Re-minting replaces it at once and breaks the connector until you redeploy or patch it with the new value, so treat re-minting as a planned change. The feed carries operator identity (member emails, source IPs, roles and approver emails); no backup data and no secret values. For the cursor and chain-continuity mechanics in full, see wiring the audit feed into your SIEM.

Last updated 5 July 2026.