What this connection does

Microsoft Sentinel receives new, redacted EmDash audit events through the Azure Monitor Logs Ingestion API. The destination is outbound-only: EmDash does not read alerts from Sentinel and does not replay historical audit events automatically.

Prerequisites

  • A user with integrations:manage to configure and operate the destination. integrations:read can view status and delivery health.
  • An Azure Data Collection Rule (DCR) with a custom stream/table that matches your ingestion schema.
  • The DCR immutable ID, stream name, and ingestion endpoint.
  • An Entra application with a directory ID, client ID, and client secret. Grant the application the Monitoring Metrics Publisher role on the DCR (or the equivalent role required by your Azure setup).
  • An optional Data Collection Endpoint (DCE) when your workspace uses private-link or a dedicated DCE. Otherwise use the DCR ingestion endpoint.
  • Permission to create or update the destination in EmDash and to validate the Azure resource configuration.

Prepare Azure

  1. In Azure, create or identify the Log Analytics custom table/stream that will receive EmDash audit events.
  2. Create or identify a DCR for the stream and record its immutable ID exactly as shown by Azure. The immutable ID is not the same as the display name.
  3. Record the DCR ingestion endpoint and stream name. If using a DCE, record its endpoint as well.
  4. Register an Entra application for ingestion, create a client secret, and assign the application the Monitoring Metrics Publisher role on the DCR.
  5. Confirm the application can obtain a token for https://monitor.azure.com/.default and that the stream’s schema accepts the fields sent by your DCR.

Configure Microsoft Sentinel in EmDash

  1. Open Settings → Integrations and select Microsoft Sentinel.
  2. Enter the Ingestion endpoint, DCR immutable ID, and Stream name (for example, a custom EmDashAudit_CL stream that you created).
  3. Enter the Entra Directory ID and Client ID, then paste the Client secret. A stored secret is write-only; re-enter it only when creating or rotating it.
  4. If your Azure design uses a Data Collection Endpoint, enter its DCE endpoint. Leave it blank when the DCR ingestion endpoint is the correct target.
  5. Select Save, then Test connection. EmDash obtains the OAuth client-credentials token server-side and validates the Logs Ingestion request.
  6. After a successful test, select Enable. Confirm that the destination shows enabled state and monitor pending, delivered, retry, and dead-letter health.

Create the DCR stream from an audit export

Open Audit Trail, choose the desired category/outcome/action filters, and select Export JSON. The downloaded array uses the same flattened field names delivered to Sentinel:

[
  {
    "TimeGenerated": "<event occurred_at in RFC3339 UTC>",
    "EventId": "<audit-event-id>",
    "TenantId": "<tenant-id>",
    "Category": "admin",
    "Action": "Updated tenant setting",
    "Outcome": "success",
    "Actor": "<actor-id>",
    "Resource": "<resource-id>",
    "CorrelationId": "<correlation-id>",
    "Metadata": "{}"
  }
]

The timestamp is read from the event; EmDash does not insert a current or synthetic date. The export preserves the selected filters, and [] means that no rows matched them. Clear filters or enable Show system events if you need automated events in the export. Metadata is redacted and secrets, tokens, message bodies, attachments, and raw provider payloads are excluded.

Permissions and data boundaries

The client secret is encrypted and stored server-side; it is never returned to the browser or included in audit events. EmDash sends redacted, tenant-scoped audit data only. It does not send message bodies, attachments, access tokens, or raw provider responses, and does not query Sentinel for detections.

Troubleshooting

  • OAuth unauthorized: verify directory ID, client ID, client secret, tenant consent, and the DCR role assignment.
  • DCR or stream not found: use the immutable DCR ID and exact stream name, including case and custom-table suffix.
  • TLS or endpoint error: use the documented HTTPS ingestion/DCE endpoint and check private-link DNS and network policy.
  • Test succeeds but delivery retries: inspect the destination’s sanitized health, Azure response status, and stream schema; transient provider failures retry with backoff.
  • Cannot enable: save a valid secret and complete a successful test first.
  • Secret rotation: enter the new client secret, save, test, then enable again if the destination was paused.

See Roles and permissions for the management boundary and support for help. Share only sanitized error codes and timestamps, never the client secret or OAuth token.