Which Log Source Completes principal.user.userid Matching?
Short answer
B Ingest Microsoft Entra ID (Azure AD) logs so principal.user.userid resolves consistently across EDR and Windows Event log entries.
Question
Key Takeaways
The question tests identity context completeness for UDM field matching; the trap is picking another Windows behavioral telemetry source (Sysmon, PowerShell, Procmon) that adds events but never resolves the user identity behind them.
Google Security Operations detections written in YARA-L that filter on principal.user.userid need identity-complete telemetry from every source they evaluate. Ingesting Microsoft Entra ID (Azure AD) logs supplies the user identity context that EDR and Windows Event logs alone cannot provide, so the field matches across all possible log entries.
Common mistake: Learners most often choose A, C, or D because Sysmon, PowerShell, and Procmon are familiar Windows telemetry sources. These add behavioral event volume but produce no identity records, so principal.user.userid still fails to match every entry.
Expert Analysis
Why the Answer Is Correct
Microsoft Entra ID (Azure AD) is the authoritative cloud identity provider for Windows endpoints, and its audit/sign-in logs carry the user identifiers that SecOps normalizes into principal.user.userid. Ingesting this source lets curated detections and YARA-L rules resolve the same user across EDR telemetry and Windows Event logs, which frequently record short names, domain-qualified names, or SID-based representations. As Hamza_hmz123 linked, the Chronicle parser documentation for Azure AD audit ingestion is the intended path. This satisfies the requirement to match "all possible log entries" rather than merely adding more behavioral events.
Why the Other Options Are Wrong
Windows Sysmon (A) and Windows Procmon (D) are process and registry telemetry utilities that generate behavioral event records keyed to processes, not to resolved identity entities, so they cannot fill an identity gap on principal.user.userid. Windows PowerShell (C) captures script and command-line activity, which is valuable for detection but likewise supplies no canonical user identity mapping. As b925054 put it, these are "Event log sources, not Entity (identity context) sources" — they increase behavioral coverage while leaving the identity matching problem unsolved. None of A, C, or D can make the UDM field match entries that currently lack a normalized user identifier.
Community Comment Notes
All three substantive comments converge on B, with Hamza_hmz123 citing the Azure AD audit default-parser documentation and TitanZauron explaining that consistent detection coverage requires "User Identity Aliasing and Enrichment" through the Entity Graph. b925054 explicitly separates event telemetry from entity context, arguing that A, C, and D "will provide more behavioral telemetry but will not solve the identity mapping problem." The vote pattern and the reasoning both support the verdict that identity ingestion, not additional endpoint event sources, is what the question is really asking for.
Official Reference
https://docs.cloud.google.com/chronicle/docs/ingestion/default-parsers/azure-ad-audit
This link opens the official vendor documentation in a new tab.
Exam Strategy
Read the UDM field named in the stem before scanning the options: if the field is an entity field (principal.*, principal.user.userid), the fix is an identity/context data source, not another behavioral event source. On SecOps questions, treat identity, asset, and alert sources as distinct categories from endpoint event telemetry.
Frequently Asked Questions
Why don't Sysmon, PowerShell, or Procmon logs fix principal.user.userid matching?
Why is Microsoft Entra ID the right identity log for Windows endpoints?
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
sAMAccountName,DOMAIN\username, User Principal Name[email protected], or Security Identifiers / SIDs)[1][3]. If YARA-L rules or Curated Detections strictly evaluateprincipal.user.userid, logs presenting an unmapped format or SID will fail to trigger detections[2][4]. 2. User Entity Context & Automatic UDM Enrichment: Ingesting identity logs from Microsoft Entra ID (formerly Azure AD) feeds User Entity data into the Entity Graph[5][6]. Google SecOps uses this identity context to perform automatic user aliasing and enrichment[2]. It maps all valid aliases, email addresses, and SIDs of a account to the standardizedprincipal.user.useridUDM field across all incoming EDR and Windows Event streams[2][3]. 3. Rule Fidelity: Once Entra ID context is ingested, any YARA-L rule or Curated Detection checking$event.principal.user.useridwill match successfully regardless of which endpoint log format captured the activity