The schema for Entra ID / Azure AD logs is complex. When I am constructing queries in Log Search, I often find myself hunting for the JSON key that I need. Even if you export audit logs from Microsoft Entra ID Admin Center, the export file won’t contain the full JSON schema for the keys. My best bet is usually to find a log for similar event and look for the keys there, which is inefficient.
I’m wondering how others are handling this. If you are using Entra ID and you are building log queries for custom dashboards, detection rules, etc., is there a log schema reference that you are using? Or do you have other tricks?
Unfortunately, we are in the same boat. However, we have six custom dashboards built with over 100 widgets combined and used a similar approach. We usually capture a test event and analyze its json structure and log source to generate a detection rule or monitoring widget against it.
Thanks! This is definitely useful but doesn’t fully address the issue we are discussing. The Rapid7 schema is easy to understand, sure, but in the case of an Entra Cloud Service Admin Activity log, there can be a LOT of key/value pairs under the “source_json” key (which under your schema is defined as "The data that was received or collected by our collector or endpoint agent, formatted as JSON".
For instance, I’m looking at an ADD_USER_TO_GROUP log which has 48 key/value pairs under source_json, and I don’t have a reference for those. If I’m trying to reference one of those I have to poke around until I find the correct one.
Yes I agree, I only noticed after sharing its a high level schema. My approach for finding KVPs is as you mentioned, finding a relevant log with a loose search like where(add user,loose) and using the quick menu options by clicking on the key name and then add key or groupby to fetch the full nested path to what you are looking for.