Skip to content

[Azure]: Collect inTune audit logs #15448

New issue
New issue
Closed
1 of 1 issue completed
Closed
[Azure]: Collect inTune audit logs#15448
1 of 1 issue completed
Labels
Integration:azureAzure LogsTeam:obs-ds-hosted-servicesObservability Hosted Services team [elastic/obs-ds-hosted-services]needs:triage

Description

@aarju
aarju
opened on Sep 24, 2025

Integration Name

Azure Logs [azure]

Dataset Name

azure.intune

Integration Version

n/a

Agent Version

n/a

OS Version and Architecture

n/a

User Goal

We would like to have an integration that collects and parses the inTune audit logs from Azure. These audit logs show all admin and device activity within inTune. I don't know if this should be a separate integration, or if this could be included in an existing Azure or Entra integration.

Here is a redacted screenshot showing example audit logs in the inTune portal. If you want an export of these audit logs reach out to me internally and I can provide a copy.

Image

Existing Features

We don't currently have an integration that collects and parses these logs.

What did you see?

n/a

Anything else?

No response

Activity

  1. aarju
    added
    needs:triage
    on Sep 24, 2025
  2. andrewkroh
    added
    Integration:azureAzure Logs
    Team:obs-ds-hosted-servicesObservability Hosted Services team [elastic/obs-ds-hosted-services]
    on Sep 24, 2025

  3. jamiehynds commented on Jul 7, 2026

    @jamiehynds
    jamiehynds
    on Jul 7, 2026

    @aarju we recently shipped a new Intune integration that covers audit logs.

    Happy to leave this issue open to collect feedback once your team has it enabled, or we can spin up new issues to track anything specific that comes up - whichever's easier for you.

  4. aarju commented on Jul 8, 2026

    @aarju
    aarju
    on Jul 8, 2026
    Author

    Thanks @jamiehynds, I opened an issue to track deploying it internally so we can start getting you feedback.

  5. aarju commented on Jul 17, 2026

    @aarju
    aarju
    on Jul 17, 2026
    Author

    @jamiehynds we started collecting the data into our cluster now. See the below comment for some of the issues encountered during the process.

  6. aarju commented on Jul 17, 2026

    @aarju
    aarju
    on Jul 17, 2026
    Author

    We've completed onboarding the microsoft_intune 0.1.0 package into our cluster. Thanks for shipping this so quickly — it got us moving. Here's the consolidated feedback from the implementation. These all apply to the microsoft_intune package (owned by elastic/security-service-integrations), not the azure integration, so tagging @jamiehynds in case this issue's original labels/team assignment need updating.

    1. Event Hub input design — hub is consumed once per data stream

    Symptom: Deploying the package as designed requires a separate Event Hub connection and consumer group for each data stream (audit, managed_device). Since Intune's diagnostic settings funnel all log categories to a single Event Hub, every event is read, transferred, and processed once per data stream — each producing its own consumer group contention — with most of it discarded after ingest.

    Root cause: Both data stream manifests (data_stream/audit/manifest.yml, data_stream/managed_device/manifest.yml) declare input: azure-eventhub with their own required connection_string and consumer_group parameters. There's no category routing in the ingest pipelines, so the only way to split streams is to consume the hub multiple times.

    Suggested fix: Consider the approach the azure integration's v2 events data stream uses: consume the hub once and route categories server-side via ingest pipeline conditionals or reroute processors. This avoids multiplying consumer groups and Event Hub egress with each new data stream. We worked around it for our deployment by consuming the hub once with server-side routing, landing non-AuditLogs/Devices categories into logs-azure.eventhub-* until the package grows matching data streams — but the native integration design should handle this cleanly.

    2. Bug: date parsing fails on ISO8601 timestamps in the managed_device pipeline

    Symptom: Ingest errors on every managed_device event:

    [Processor date with tag date_properties_CreatedDate in pipeline logs-microsoft_intune.managed_device-0.1.0 failed with message: Text '2024-03-28T13:21:42.7099261' could not be parsed at index 10]
[Processor date with tag date_properties_InGracePeriodUntil in pipeline logs-microsoft_intune.managed_device-0.1.0 failed with message: Text '9999-12-31T23:59:59.9999999' could not be parsed at index 10]
[Processor date with tag date_properties_LastContact in pipeline logs-microsoft_intune.managed_device-0.1.0 failed with message: Text '2026-07-15T15:58:33.647972' could not be parsed at index 10]

    Root cause: The date processors for CreatedDate, InGracePeriodUntil, and LastContact in data_stream/managed_device/elasticsearch/ingest_pipeline/default.yml use the format yyyy-MM-dd HH:mm:ss.SSSSSSS (space separator). Intune sends ISO8601 with a T separator — the "index 10" in the error is exactly the T position. The 9999-12-31T23:59:59.9999999 value is also a "never" sentinel that Intune uses for InGracePeriodUntil and will be present on most enrolled devices.

    Suggested fix:

    • Change the format from yyyy-MM-dd HH:mm:ss.SSSSSSS to yyyy-MM-dd'T'HH:mm:ss.SSSSSSS (or add both formats) for all three date processors.
    • For InGracePeriodUntil, also handle the 9999-12-31T23:59:59.9999999 sentinel (either skip parsing it and leave it as-is, or coerce it to a known "no expiry" value).

    3. Bug: shipped dashboards use the logs-* data view instead of integration-scoped views

    Symptom: Both dashboards shipped with the package query across all of logs-*. In our deployment this caused dashboard panels to pull data from unrelated indices in the same space, producing misleading results. Any Kibana Space that has other log data alongside Intune will be affected.

    Root cause: Both dashboard JSON files (kibana/dashboard/microsoft_intune-adaf931d-*.json, kibana/dashboard/microsoft_intune-e39a0b69-*.json) hardcode the logs-* index pattern instead of scoping to the integration's own datasets.

    Suggested fix: Scope dashboards to logs-microsoft_intune.audit-* and logs-microsoft_intune.managed_device-* respectively, which is the pattern used by other integrations with dedicated data streams.

    4. targets.modified_properties mapping is not useful for analysis on audit events

    Symptom: The targets.modified_properties field on audit events is mapped as a flat keyword group (name/old/new triple) but doesn't render in a way that's useful for aggregation or timeline analysis — it's hard to correlate which name goes with which old/new pair, and Discover/Lens can't aggregate over the pairs meaningfully.

    Root cause: The field is mapped as a group in data_stream/audit/fields/fields.yml with three sibling keywords (name, old, new). The ingest pipeline populates it via three separate foreach renames that process ModifiedProperties arrays. Without a nested type or explicit pairing, Elasticsearch can't guarantee alignment between the sub-arrays.

    Suggested fix: Either map modified_properties as a nested type so that name/old/new sub-fields stay correlated per entry, or denormalize it into an array of objects at ingest time. Happy to provide sample raw event data to inform the design if useful — feel free to reach out.

    Happy to provide raw event samples, pipeline test cases, or additional context for any of these. Thanks again for the fast turnaround on the integration.

  7. jamiehynds commented on Jul 21, 2026

    @jamiehynds
    jamiehynds
    on Jul 21, 2026

    Thanks for testing and sharing the feedback @aarju

    @piyush-elastic could someone please review the points above and implement the relevant fixes. 2-4 should be straight forward, but for #1 we need to determine if we can implement this approach (which makes sense) without impacting existing users. It's in tech preview so we can make some changes, but would have to inform users of any configuration changes they'd have to make on their end as part of an integration upgrade/breaking change notification.

  8. jamiehynds
    closed this as completedon Jul 27, 2026

  9. piyush-elastic commented on Jul 29, 2026

    @piyush-elastic
    piyush-elastic
    on Jul 29, 2026
    Contributor

    @aarju ;Thanks for the feedback.

    We will implement the following changes:

    Event Hub: Use a single Event Hub and a reroute pipeline to route events to the managed_device and audit data streams based on the event category.
    Timestamps: Add support for the yyyy-MM-dd'T'HH:mm:ss.SSSSSSS timestamp format in addition to the existing supported format.
    modified_properties: Map this field as a nested type so that the name, old, and new values remain associated for accurate analysis.

    Regarding dashboards, integrations use the default logs-* data view. We apply a data_stream.dataset filter at the dashboard level for the managed_device and audit data streams, ensuring that only Intune data for the selected data stream is displayed.
    If you want to explore the data in Discover or build custom dashboards, you can simply apply a data_stream.dataset filter for the specific data stream you want to analyze.

  10. jgregmac commented on Aug 7, 2026

    @jgregmac
    jgregmac
    on Aug 7, 2026

    I was about to file a bug report for item 2 in @jamiehynds report. Item 1 was another annoyance that we ran into, which would be great to have addressed in the same manner as implemented in the eventhubs v2 code.

    @piyush-elastic , can you provide a bug number so that we can track this issue?

  11. jamiehynds commented on Aug 24, 2026

    @jamiehynds
    jamiehynds
    on Aug 24, 2026

    Thanks for sharing @jgregmac. @piyush-elastic was there an issue created for these updates to InTune, if not, I'll go ahead and create one.

  12. joshFive commented on Aug 28, 2026

    @joshFive
    joshFive
    on Aug 28, 2026

    Microsoft Intune timestamp bug is patched in v.0.1.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Integration:azureAzure LogsTeam:obs-ds-hosted-servicesObservability Hosted Services team [elastic/obs-ds-hosted-services]needs:triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions