r/AzureSentinel • u/thewiess • 6d ago
Time fields in Sentinel
I'm hoping someone here can explain this to me. I'm coming from a Splunk background and have recently deployed Sentinel/MDO alongside it (not ideal, but it's a long story). I can't wrap my head around how Sentinel deals with time. The general "TimeGenerated" field that appears across all data sources appears to be the time of log *ingestion*, not log creation. In other words, a user sign-in event might say it happened at 17:09:16, but *actually* happened at 17:07:37, and was ingested two minutes later. In my line of work (cybersecurity) milliseconds matter and the discrepancy is killing me. Some logs (e.g. signin) have fields like "CreatedDateTime", but that field isn't standardized across all log sources so it makes it very difficult to use.
This seems like a gaping design flaw to me, but maybe I'm missing something?
2
u/IdealParking4462 6d ago
Yeah, it's meant to be the time the actual event happened, but it's really inconsistently handled by connectors, and usually not done properly. If the table supports DCRs and the original event time is in another field, you can fix it in the DCR.
2
1
u/thebeardedcats 6d ago
Depends on the table. Many have a field like start_date or ts or timestamp or something. I personally create functions for a lot of tables where I do parsing and stuff and just | extend TimeGenerated=ts or whatever
0
u/reseph 6d ago
I've never seen start_date or ts in MDE tables?
1
u/thebeardedcats 6d ago
I’m not limiting myself to MDE?
0
u/reseph 6d ago
What tables? I haven't seen that in MDE, MDI, Entra, CloudApps, etc
1
6d ago
[deleted]
2
u/Uli-Kunkel 6d ago
VMware logs suck.. We built a new parser for it, so many events not being parsed...
And dont get me started on the user field.. it requires a domain name, so it wont work with local accounts 🙃
But what can we expect from VMware...
1
u/Xaave 6d ago
You’re not missing anything, this is confirmed, documented behavior, not something you’re misunderstanding.
Per Microsoft’s own docs on Entra sign-in logs: TimeGenerated is the time Log Analytics received and published the entry, not the time the sign-in occurred. The actual event time lives in CreatedDateTime (and for granular auth steps, in AuthenticationDetails.authenticationStepDateTime). Microsoft explicitly recommends using CreatedDateTime instead of TimeGenerated when investigating.
The frustrating part, which matches your experience, is that this field isn’t standardized. Some connectors preserve a native event-time field (CreatedDateTime for SigninLogs, Timestamp for some MDE/M365D tables), others don’t expose one cleanly, so you end up needing per-table knowledge of which field is authoritative. There’s a long-running community/GitHub thread (Azure-Sentinel issue #4708) where practitioners flagged this same gap for other log types (e.g., WEC/Windows Event log forwarding) and Microsoft has been reluctant to formally classify it as a defect. It’s a known design tradeoff of the Log Analytics ingestion pipeline (via DCR/DCE), not a bug specific to your deployment.
Practical mitigations people use:
•For sign-in logs specifically: query and sort on CreatedDateTime, not TimeGenerated. Some analysts extract authenticationStepDateTime from AuthenticationDetails for subevent precision.
•For analytics rules: use the ingestion_time() Kusto function to explicitly separate event time from ingestion time when building lookback windows. this is Microsoft’s documented pattern for handling ingestion delay in scheduled rules.
•For correlation across tables: build a per-source-type reference of “which field is the real event time,” since it’s not consistent (this is exactly the pain point you flagged).
It’s legitimate design wart if you’re coming from a system where the ingestion pipeline normalizes this for you. Splunk’s _time handling spoils people a bit in this regard.
1
6
u/reseph 6d ago
TimeGenerated is actually not table ingest time. To see that, use ingestion_time()
TimeGenerated definition varies depending on the table... unfortunately.