Intune diagnostic settings: send audit and device logs to Sentinel, Splunk or any SIEM

Intune keeps its audit trail, enrollment results and compliance data inside the admin center, where your security team can't line them up with sign-ins and alerts. Diagnostic settings solve that by streaming the data into Azure Monitor. In this post I'll show which Intune logs you can export, how to route them to Microsoft Sentinel through Log Analytics and to Splunk or another SIEM through Event Hubs, and how to prove the data is arriving.

How it works#

A diagnostic setting is a tenant-level route from Intune to one or more Azure destinations. Each category you pick is copied to every destination you select.

Each destination serves a different consumer:

• Log Analytics workspace: KQL queries, workbooks and alerts. Microsoft Sentinel runs on a Log Analytics workspace, so sending Intune data to the Sentinel workspace is all Sentinel needs.
• Event Hubs namespace: streaming to Splunk, QRadar, Sumo Logic or your own consumer through the Event Hubs API. Intune batches events in roughly five-minute intervals and sends each batch as one message, or several when it's too large; Microsoft's sizing example uses 256 KB per message.
• Storage account: a low-cost archive. Microsoft recommends a general-purpose account rather than a blob-only one.

Prerequisites#

• An Azure subscription that the configuring account can sign in to. Intune doesn't store the routed data; you pay for the Azure resources (Log Analytics ingestion and retention, Event Hubs, storage), and Sentinel adds its own charges on top. Microsoft sizes an audit event at roughly 2 KB.
• The Intune Administrator role in Microsoft Entra ID (listed as Intune Service Administrator in Microsoft's article).
• Rights on each destination: Microsoft lists Log Analytics Contributor on the workspace and ListKeys on a storage account. For Event Hubs, Azure Monitor documents that the shared access policy needs Manage, Send and Listen rights, and that you need the ListKey permission on that policy.

Step-by-step#

1. Create the diagnostic setting#

1. In the Microsoft Intune admin center, go to Reports › Diagnostics settings. The first time, turn the feature on; afterwards, add a new setting.
2. Give it a descriptive name, for example Intune to Sentinel and Splunk.
3. Select the categories: AuditLogs, OperationalLogs, DeviceComplianceOrg and IntuneDevices.
4. Choose the destinations: the Sentinel workspace under Send to Log Analytics, the namespace and shared access policy under Stream to an event hub, and a storage account if you need an archive.
5. Save. If your subscription isn't offered, open the account menu at the top right and use Switch directory, then check your Azure role on the subscription.

2. Use the data in Microsoft Sentinel#

No extra connector is needed: once rows land in the workspace, you can use the tables in hunting queries, workbooks and analytics rules. This query is a good start for a rule that flags one account issuing many destructive actions in an hour:

IntuneAuditLogs
| where TimeGenerated > ago(1h)
| where OperationName contains "wipe" or OperationName contains "retire" or OperationName contains "delete"
| summarize Actions = count(), Operations = make_set(OperationName) by Identity
| where Actions >= 5

The audit columns are TimeGenerated, OperationName, Identity, ResultType, ResultDescription, Category, CorrelationId and Properties, a JSON string with the details. Inspect a few rows with parse_json(Properties) before you build on specific keys; Microsoft warns that these schemas can change.

3. Connect Splunk to Event Hubs#

Splunk's own route is the Splunk Add-on for Microsoft Cloud Services, configured on the instance that collects data (usually a heavy forwarder):

1. Register an application in Microsoft Entra ID for the add-on and add it in the add-on as an Azure App Account.
2. Give that application the Azure Event Hubs Data Receiver role on the namespace.
3. In the add-on, select Inputs › Create New Input › Azure Event Hub, then enter the namespace, event hub name, consumer group, transport type and target index.

On Splunk Cloud Platform the add-on runs on an Inputs Data Manager (IDM), which only connects out on port 443 by default, and Splunk documents that this input doesn't support plain AMQP there, so keep the default AMQP over WebSocket transport. On your own forwarder, port 443 is always needed (token requests and management calls use HTTPS); plain AMQP also needs ports 5671 and 5672. If the namespace has network restrictions, turn on Allow trusted Microsoft services to bypass this firewall so Azure Monitor can still write to it, and allow your collector's addresses. QRadar, Sumo Logic and custom readers use the same event hubs. Give each consumer its own consumer group; the Basic tier only has the default one.

Verify the data is flowing#

1. Make a harmless change, such as editing a test policy's description. Audit and operational events are sent immediately and usually show up within about 30 minutes.
2. Check every table in one query. isfuzzy=true stops the query failing on tables that haven't been created yet:
   KQL

   union isfuzzy=true withsource=TableName IntuneAuditLogs, IntuneOperationalLogs, IntuneDeviceComplianceOrg, IntuneDevices
   | where TimeGenerated > ago(3d)
   | summarize Rows = count(), Newest = max(TimeGenerated) by TableName

3. For Event Hubs, watch the incoming messages metric on the namespace, then search the Splunk index you chose for new events.
4. For storage, look for one container per category (names start with insights-logs-).

Good looks like audit and operational rows within the hour, compliance and device rows within two days, and new events in your SIEM index.

Tips and gotchas#

• Table not found. A query against a table that has never received data fails with Failed to resolve table or column expression named 'IntuneDevices'. Tables are created by the first delivery. IntuneDevices and IntuneDeviceComplianceOrg can take up to 48 hours, so wait before you troubleshoot.
• No fixed export time. The daily exports can land at any time in each 24-hour window, so don't schedule reports around a fixed time.
• Duplicates are documented. Microsoft says the pipeline can duplicate up to 100% of the data in a 24-hour period. Deduplicate in queries, for example with summarize arg_max(TimeGenerated, *) by a stable key, and in the SIEM.
• Watch volume. This query shows how much each Intune table ingests:
  KQL

  Usage
  | where TimeGenerated > ago(30d)
  | where DataType startswith "Intune"
  | summarize IngestedMB = sum(Quantity) by DataType

• Retention. Don't rely on the Retention (days) value for storage that Intune's article still describes: Azure Monitor has retired diagnostic-settings storage retention, so that value no longer deletes anything. Use an Azure Storage lifecycle management policy on the account instead; Log Analytics retention is set per table in the workspace.
• Protect the data. The device and compliance tables identify users and devices, so restrict who can read the workspace.

Related reading: KQL queries for Intune admins, wipe, retire and Fresh Start explained and Multi Admin Approval.

References#

• Microsoft Learn: Send Intune log data to Azure Storage, Event Hubs, or Log Analytics
• Microsoft Learn: IntuneAuditLogs table reference
• Microsoft Learn: Migrate from diagnostic settings storage retention to Azure Storage lifecycle management
• Splunk: Configure Azure Event Hub inputs for the Splunk Add-on for Microsoft Cloud Services