Hey folks,
Just wrapped up a pretty deep dive into mapping our Active Directory logins and group changes over to Chronicle's user entity model. We're using it to enrich our SecOps alerts, but I found the documentation a bit... abstract. If you're coming from a marketing ops background like me, you're used to clean, structured user objects. Chronicle's model is powerful, but you have to feed it right.
Here’s the core mapping we landed on that's working well for our Windows Event IDs (4624, 4625 for logons, 4728-4732 for group membership). The key is populating those `user.*` fields in your UDM events:
* **User Identifiers:** We map `user.email` from the UPN when available, and `user.windows_sid` is a must-have for the entity resolution to link events.
* **Asset Context:** The `principal.hostname` field from the AD event becomes `user.asset.hostname` in the UDM. This gives you that crucial "user *from* which machine" context.
* **Group Membership:** This was the trickiest. We parse the group SIDs from the event and store them as repeated `user.groupid` fields. Chronicle uses these for peer group analysis.
The biggest "aha" was realizing that without a consistent `user.windows_sid` across our logs, Chronicle was creating duplicate, fragmented user entities. Our first pass looked messy until we fixed the SID extraction. Now, the user timeline view is pulling together auth events, endpoint alerts, and web proxy data beautifully.
Has anyone else tackled this? I'm particularly curious about:
- How you've handled nested AD groups at scale.
- Whether you're injecting user department or title from AD as custom `user.attributes` (we're considering it for risk scoring).
Cheers,
Henry
Cheers, Henry
Nice to see this laid out, I've been trying to wrap my head around the same thing for a smaller setup. That mapping for the `user.groupid` fields especially, that's really helpful.
One quick question, you mentioned the windows_sid is a must-have. Did you run into any issues with service accounts or system events where that SID isn't a regular user SID? Wondering how Chronicle handles those.
Still learning
That's a good point. From what I've seen, Chronicle does still resolve those SIDs, but the entity type might be labeled as a service or system account in the graph. It doesn't break the mapping, but the context is different.
You might want to check how those resolved entities appear in your instance's entity graph to see if the alerts treat them the way you expect.