Ship logs to Microsoft Sentinel

Use this guide to stream your Audit Logs to Microsoft Sentinel via the Azure Monitor Logs Ingestion API. Firezone authenticates to your tenant as a Microsoft Entra application using workload identity federation. No client secret is stored, by Firezone or by you.

Step 1: Start creating the Log Sink in Firezone

In the admin portal, go to SettingsLog Sinks, click Add, and select Microsoft Sentinel. The form walks you through the two-stage Azure setup below, so keep it open while you work.

Enter your Microsoft Entra tenant ID in the form, then have a tenant administrator click Grant admin consent. This adds the Firezone Sentinel Log Ingestion application to your tenant so you can assign it a role in the next step. The application requests no API permissions and cannot read your directory or data. It only becomes a service principal that you grant the Monitoring Metrics Publisher role to, on a single data collection rule. Its access is limited to publishing logs to that one rule.

Step 3: Create the ingestion resources

Create a data collection endpoint, a custom table, and a data collection rule, then grant the Firezone application the Monitoring Metrics Publisher role on the rule. The portal provides the same steps with Firezone's application ID filled in, so prefer copying scripts from there. Choose your tool:

  1. You need a Log Analytics workspace: use the one Microsoft Sentinel is enabled on. If you don't have one yet, search for Log Analytics workspaces in the Azure portal and create one, then search for Microsoft Sentinel, choose Create, and add it to that workspace.
  2. Search for Data collection endpoints in the Azure portal and create one in the same region as your workspace. Firezone delivers logs to this endpoint.
  3. Open your workspace and go to Settings → Tables. Choose Create → New custom log (DCR-based). Name the table FirezoneLogs, choose Create a new data collection rule and give it a name such as firezone-logs, and select the data collection endpoint from the previous step. On the Schema and transformation step, upload the sample file offered in the Firezone form and keep the default transformation, then create the table. The table's columns are TimeGenerated, Message, Stream, and Firezone.
  4. Search for Data collection rules, open the rule you just created, and go to Access control (IAM). Choose Add → Add role assignment, select the Monitoring Metrics Publisher role, then under Members choose User, group, or service principal and select the Firezone Sentinel Log Ingestion application created by the admin consent above, then review and assign. The assignment can take up to 30 minutes to take effect.
  5. Fill in the fields in the Firezone form. Each field's hint says where to find its value in the Azure portal. If you followed these steps, the stream name is Custom-FirezoneLogs_CL.

Step 4: Configure the sink

Back in the Firezone form, fill in:

FieldDescription
NameA name to identify this log sink.
Tenant IDYour Microsoft Entra tenant ID, also called the directory ID.
Ingestion EndpointThe Logs Ingestion URI shown on your data collection endpoint's Overview page, for example https://my-dce-abcd.eastus-1.ingest.monitor.azure.com.
DCR Immutable IDThe Immutable Id shown on the data collection rule's Overview page, also shown in its JSON View, for example dcr-0123456789abcdef0123456789abcdef.
Stream NameThe DCR's input stream, listed in its JSON View under streamDeclarations. Defaults to Custom-FirezoneLogs_CL.

A few validations to be aware of: the ingestion endpoint must be HTTPS and its host must end in .ingest.monitor.azure.com. This guarantees the token Firezone mints for your tenant is never sent to a non-Azure host. The DCR immutable ID must match dcr-<32 hex characters> and the stream name must start with Custom-.

Then choose which Log streams to deliver, all four of which are enabled by default, and optionally check Deliver existing logs to backfill logs recorded before the sink was created.

Deliver existing logs can only be selected when you create the sink. It can't be turned on later for an existing sink.

Click Create. Deliveries begin within about a minute, though the role assignment from Step 3 can take up to 30 minutes to propagate. Firezone retries automatically in the meantime.

Delivery format

For each delivery, Firezone obtains a short-lived bearer token for your tenant, then POSTs a JSON array to <Ingestion Endpoint>/dataCollectionRules/<DCR Immutable ID>/streams/<Stream Name>?api-version=2023-01-01. Each record maps onto the custom table's four columns. Query the full event from the Firezone dynamic column in KQL, for example FirezoneLogs_CL | where Stream == "change".

{
  "TimeGenerated": "2026-07-14T09:26:31.114Z",
  "Message": "firezone change c0654d20aa1b4a0000000002",
  "Stream": "change",
  "Firezone": {
    "type": "change",
    "log_id": "c0654d20aa1b4a0000000002",
    "timestamp": "2026-07-14T09:26:31.114213Z",
    "object": "policies",
    "operation": "update",
    "before": { "id": "0a83588e-…", "description": "Engineering → GitLab" },
    "after": {
      "id": "0a83588e-…",
      "description": "Engineering → GitLab (MFA required)"
    },
    "subject": {
      "actor_id": "e2f6a9c4-…",
      "actor_name": "Jamie Admin",
      "actor_email": "jamie@company.com",
      "actor_type": "account_admin_user",
      "auth_provider_id": "9d0c2f4e-…",
      "ip": "203.0.113.44",
      "ip_region": "US",
      "ip_city": "San Francisco",
      "ip_lat": 37.7749,
      "ip_lon": -122.4194,
      "user_agent": "Mozilla/5.0 …"
    }
  }
}

How Firezone responds to HTTP status codes

ResponseBehavior
2xxThe batch is accepted and delivery advances. Azure acknowledges successful deliveries with 204.
403Retried, because role assignments can take up to 30 minutes to propagate. Disabled after 24 hours of persistent failure.
400 for DCR/stream mismatchesRetried as a configuration issue you can fix in place, for example a wrong stream name or DCR. Disabled after 24 hours if unresolved.
400 with Azure's malformed-request error codesThe batch is bisected to isolate the rejected record. Delivery pauses at it and Firezone engineers are notified automatically. No entries are skipped.
413The batch is split in half and retried to isolate an oversized record.
429, 5xxRetried every minute. Disabled after 24 hours of persistent failure.
401 or an AADSTS token errorTreated as a configuration error, usually missing admin consent or a wrong tenant ID: the sink is disabled immediately.

Duplicates and redelivery

Firezone guarantees at-least-once delivery, retrying any batch that isn't acknowledged rather than risk losing data, so Sentinel can occasionally receive the same record twice. When it does, deduplicate on Firezone.log_id in KQL: flow start and end events are already suffixed with -s and -e, which makes the log_id a unique key across all streams.

Recovering a failed sink

A sink showing Warning is retrying automatically, and during initial setup this is often just the role assignment propagating. A sink showing Error has stopped delivering and needs attention: fix the cause, commonly revoked admin consent, a deleted role assignment, or a wrong tenant ID, then open the sink, click Edit, and click Save to re-enable it. Delivery picks up right where it left off, from the last acknowledged entry, and Deliver Now triggers a delivery immediately if you don't want to wait for the next cycle.

Deleting the sink deletes its delivery state but not your Azure resources or ingested data, so re-creating it starts fresh while reusing the same DCE, DCR, and table: the new sink delivers logs recorded from its creation onward, plus a full backfill if Deliver existing logs is selected, which re-sends records Sentinel may already have.

Need help? See all support options.

Found a problem with this page? Open an issue
Last updated: July 20, 2026