Azure & Microsoft 365.
Trace the event and its lineage.

Select an object to highlight its contributing routes. An index traces every upstream source; a source traces its configured downstream destinations. Event flow shows collection and delivery; Configuration adds settings, subscriptions and classification. Both are illustrative models, separate from the simulated delivery evidence below.

Platform containers separate Azure / Microsoft from Splunk. Arrowheads show direction; solid arrows carry events and dashed arrows show configuration relationships. Diagnostic settings, subscriptions, CAS collection settings, Event Hubs and service APIs belong to Azure / Microsoft. Splunk input configuration is shown with the add-on inputs and collection host in its own column. The receiving tier accepts forwarded events before index storage. Sourcetypes classify events; they are not transport stages. A Splunk host can itself run on Azure infrastructure.

One row per catalogue event / inventory type. This is configured PoC routing, not evidence of delivery. Event types include diagnostic categories, API examples and periodic inventory snapshots. Shared credential references are illustrative; confirm actual account reuse in your configuration inventory.

Collector: Splunk Add-on for Microsoft Cloud Services

Event Hub → Azure Event Hub input on hf-poc → Splunk forwarding → index azure_poc. This resource-log demo selects azure:monitor:resource; the generic input default is mscs:azure:eventhub.

Collection host: hf-poc (heavy forwarder)
Add-on: Splunk_TA_microsoft-cloudservices
Input type: Azure Event Hub
Input name: azure-resource-logs-poc
Azure App Account: azure-app-poc
Namespace FQDN: eh-logging-poc.servicebus.windows.net
Event Hub: azure-resource-logs
Consumer group: splunk-poc
Transport: AMQP over WebSocket
Index: azure_poc
Sourcetype: azure:monitor:resource
Blob checkpoint store: enabled (illustrative choice)
Storage account: stcheckpointpoc
Container: eventhub-checkpoints

Track one record across a batch. Source fields, configured relationships, Event Hub transport metadata and custom enrichment remain distinct. A configured route is not evidence of delivery; stage status below shows which simulated handoffs have occurred.

Office 365 & Power BI: Audit.General

Power BI audit activity shares this subscription and input. Identify records by Workload=PowerBI and RecordType=20. This simulation includes ViewReport and ShareReport, with tenant, audit Id, workspace, report and dataset identifiers. Source fields vary by operation.

Configure Management Activity in the Splunk Add-on for Microsoft Office 365 with tenant m365-tenant-poc, content type Audit.General and an explicit target index. Its sourcetype is o365:management:activity.

Enable unified auditing and configure the tenant application with ActivityFeed.Read permission and consent. The add-on discovers and retrieves content blobs over HTTPS. First content availability can be delayed, content can arrive out of order, and duplicate audit records are possible. Track tenant + source Id alongside contentId/contentUri and input configuration; these API metadata fields are not automatically part of every indexed record.

Office 365 input configuration · Management Activity API reference

Microsoft Entra ID Metadata

Applications, devices, groups and users are periodic directory inventories retrieved from Microsoft Graph v1.0 over HTTPS by the Splunk Add-on for Microsoft Office 365. The default sourcetype is o365:metadata; this demo selects azure_poc as its index and the documented default polling interval of 86400 seconds.

Four individual inputs are shown for clarity; multiple types can also be selected in one input. Follow Graph paging and validate the actual source value, timestamp extraction and object splitting. Application objects are app registrations; service principals are a separate Graph collection. Group snapshots do not automatically enumerate members, and user snapshots do not constitute sign-in logs.

Lineage: tenant + object type + object id + collection run/time + Graph endpoint + input + index. Repeated object IDs represent successive snapshots, not duplicate audit IDs. Additional fields and queries can require extra Graph permissions. Grant application permissions and admin consent as required by the installed add-on integration guide.

Splunk metadata input reference · Graph applications · Graph devices · Graph groups · Graph users

Audit Logs:AuditLogs.SignIns

The Office 365 add-on Audit Logs input polls https://graph.microsoft.com/v1.0/auditLogs/signIns over HTTPS with content_type=AuditLogs.SignIns. It uses o365:graph:api; the illustrated index is azure_poc.

Configure tenant permissions, approved start date, query window, collection interval, timeout and a latency allowance. Native id and createdDateTime support event lineage. Tenant, endpoint, query range, page and input configuration belong to collection metadata and are not automatically in each source record.

This direct API route can overlap the Entra Event Hub route. Do not assume it covers all four requested diagnostic sign-in categories. Verify coverage and duplicates using tenant plus native sign-in ID; select collection routes deliberately. Splunk recommends Event Hub ingestion for migration of legacy Azure add-on sign-ins, while this Audit Logs input remains documented for matching Office 365 deployments.

Splunk Audit Logs input · Graph sign-ins API

Management Activity:DLP.All

DLP.All is the DLP content stream across workloads. It has its own tenant subscription and Management Activity input, o365-dlp-all-poc, while sharing the Office 365 add-on, Management Activity API, hf-poc and the o365:management:activity sourcetype. This demo targets azure_poc.

Sample SharePoint operations are DlpRuleMatch, DlpRuleUndo and DlpInfo. These show a rule match, an undone policy action and a false-positive designation. Source Id, CreationTime, PolicyDetails.PolicyId and rule IDs support event and policy lineage; contentId/contentUri remain separate API retrieval metadata.

Enable unified auditing and appropriate DLP policies and tenant permissions. ActivityFeed.Read and ActivityFeed.ReadDlp are shown for the DLP input; grant the appropriate application permissions and tenant consent. Sensitive-detail availability depends on access. The PoC uses SensitiveInfoDetectionIsIncluded=false. DLP.All describes the content stream, not a guarantee that every workload or DLP feature emits these example records.

Splunk Management Activity configuration · Microsoft DLP schema

Management Activity: directory & Exchange audits

Each content type has a dedicated tenant subscription and Management Activity input. Both use the Office 365 add-on, HTTPS content retrieval, hf-poc, o365:management:activity and the illustrative azure_poc index. Enable unified auditing and tenant-authorized activity collection.

Lineage follows tenant + audit Id + CreationTime + affected object + contentId/contentUri + input + index. Directory actor/target fields and Exchange cmdlet parameters describe what changed. Content type and blob metadata belong to collection configuration, not automatically to each native record. Exchange admin ResultStatus uses True/False; a feed’s event schema depends on its RecordType. Validate workload auditing settings and overlapping Entra routes.

Splunk Management Activity input · Microsoft audit schema

Cloud Application Security: Alerts & Policies

The Office 365 add-on Cloud Application Security inputs retrieve Defender for Cloud Apps risks and policy configuration over HTTPS, using tenant Cloud Apps API settings. Separate Alerts and Policies inputs share o365:cas:api, hf-poc and the illustrative azure_poc index.

The sample alert links entities[type=policyRule].id to the sample policy _id. Matching identity supports an investigation pivot; it does not prove that the collected policy version was effective when the alert fired. A full policy version history requires separate evidence.

Validate the tenant endpoint, API authorization, paging, field schema and timestamp behavior in the installed add-on. The Alerts endpoint is /api/v1/alerts/. The Policies endpoint is left as a configuration placeholder because the linked Splunk input guide does not specify its path; the policy payload is a simplified teaching sample. Tokens are excluded from exports.

Splunk Cloud Application Security inputs · Microsoft Alerts API · Microsoft policy properties

Microsoft Defender for Cloud: continuous export

Configure export per subscription. On the Defender for Cloud resource menu, select Environment settings. Select the subscription that you want to configure data export for. In the resource menu under Settings, select Continuous export. On the Event hub tab, choose the data types (security alerts by severity, recommendations, security findings, secure score and controls, regulatory compliance), the export frequency (streaming updates, snapshots or both), and the target namespace, hub and an authorization rule with Send rights. If the namespace restricts network access, allow export as a trusted service. The configuration is stored as a Microsoft.Security/automations resource and can be deployed at scale with Azure Policy.

Continuous export sends what the enabled Defender plans produce. Enable plans under Environment settings › subscription › Defender plans; each is a Microsoft.Security/pricings setting. Choose the plan as the sample operation under Security alerts or Security findings, and use the Defender plan not enabled scenario to see that a disabled plan raises nothing to export.

Recommendations, secure score and regulatory compliance come from posture management and do not depend on these plans. Alert names and codes in this demo are illustrative; filter exported alert severities in the continuous export settings.

This demo exports to a dedicated hub, azure-defender-export, consumed by its own MSCS input on hf-poc. Records are Defender for Cloud API objects, not resource logs, so the generic mscs:azure:eventhub sourcetype is shown; verify the sourcetype and field extraction for your add-on version. Lineage uses the object id: alert id and systemAlertId for alerts, assessment and resource IDs for recommendations and findings. Snapshots repeat the same IDs over time.

Microsoft: continuous export

Azure Virtual Desktop: host pool, workspace & session host logon

Host pool and workspace diagnostic settings export to azure-resource-logs and arrive as azure:monitor:resource. Connection, Checkpoint and Error records for one connection share a native CorrelationId; workspace Feed records show feed downloads. Entra sign-ins for Azure Virtual Desktop and the Remote Desktop single sign-on token use the existing Entra stream.

The session host Security log takes a different route: a Splunk Universal Forwarder on the session host reads WinEventLog://Security and forwards directly to the receiving tier as XmlWinEventLog, with field extraction from the Splunk Add-on for Microsoft Windows. There is no diagnostic setting, Event Hub or hf-poc on that route. Logon events 4624 and 4625 (logon type 10) do not carry the AVD CorrelationId, so correlate them by user, session host and time.

Azure Virtual Desktop diagnostics · Event 4624

Real-environment validation

1. Query the source resource’s supported diagnostic categories; enable the required category and feature logging. For storage, select the blob/file/queue/table child resource. Configure the diagnostic setting to the destination Event Hub.
2. Set an appropriate retention window and consumer group; grant the collector’s Azure application Event Hubs Data Receiver access and configure networking for the selected transport.
3. Configure the Microsoft Cloud Services add-on on a collection instance, typically a heavy forwarder, and configure forwarding to Splunk. This path uses the Event Hub input; HEC is not required.
4. Verify record splitting, timestamp extraction and the actual add-on sourcetype. Resource logs use azure:monitor:resource; the Entra sign-in stream uses azure:monitor:aad. The generic input default is mscs:azure:eventhub. If implementing the proposed lineage contract, verify every poc_ field at each handoff and compare the preserved raw bytes.
5. Generate an approved test event. Correlate resource ID, category, source time and available producer identifiers; validate Event Hub arrival, consumer health and a searchable Splunk event. Test replay and duplicates; restore collection before retention expires.

This demo covers resource diagnostic logs. The four requested Entra sign-in categories are now included as a tenant-level stream. Subscription Activity Log, metrics, other Entra categories, VM guest logs and AKS workload logs remain separate scopes. For Event Hub source diagnostics the demo routes to a different destination namespace; do not create a diagnostics feedback loop.

Microsoft: diagnostic streaming · Splunk: Event Hub input