Forum Discussion
IdentityInfo with analytics KQL query
This is the query I currently have:
Log_source
| where TimeGenerated >= ago(10m)
| join kind=leftouter (
IdentityInfo
| where TimeGenerated >= ago(14d)
| distinct SAMAccountName, AccountObjectId
)
on $left.sourceProcessUsername == $right.SAMAccountNameThis works as intended when run as a separate query, as it properly adds the AccountObjectId for each row. However when configuring it as an analytics rule, setting the lookup data to 14 days limits the query frequency to once an hour:
Maybe this is just the way Sentinel works, but I feel like I'm missing something and there is a more efficient way of solving this.
Marek
MicrosoftThe Sentinel rule settings override your query lookback (where TimeGenerated).
It is not documented but I suspect that putting your SAM lookup table into a let table first will prevent the rule from overriding.
So run your rule every 10 min if that is your preferred frequency with a reasonable lookback like 10-15 minutes. Create a lookup table first.
let SamLookup = IdentityInfo
| where TimeGenerated > ago(14d)
| summarize arg_max(TimeGenerated, *) by SAMAccountName;
Log_source
| project-rename SAMAccountName=sourceProcessUsername
| join SamLookup on SAMAccountName
I did some testing but unfortunatly putting the lookup in a let function is still being overridden by the rule settings. I've also tried creating the lookup table as an external function, but the lookback is still overridden.
- AndrewBlumhardt
Thanks for the info, good to know.
Can you create this as an XDR detection rule instead? I don't think the same restriction apply and this is the future direction for all detection rules.Hi Andrew,
Sorry for the late response. For now, I've configured the rule to run only once an hour, allowing me to extend the lookup to two weeks. It's not ideal, but for now it'll have to do. Thanks!
Hey Andrew,
Thanks for the suggestion! I will be testing it for the next few days to see if it works, but from what I can tell this might have solved the problem.
Marek