Forum Discussion
App excluded in "Successful logon from IP and failure from a different IP" analytics rule
The description of the subject rule states "logs onto an Azure App from one IP and within 10 mins failed to logon to the same App via a different IP" which implies that any registered app will trigge...
I think it is just a way to reduce noise from applications that fail regularly, those ones were probably causing a lot of false positive in the authors Sentinel instance, you could remove them and have a look at the results. Depending on the size of your tenant that query seems like it could take ages to run, later in the query it does a summarize to reduce noise further.
// Only take hits where there is 5 or less distinct AppDisplayNames on the success side as this limits highly active applications where failures occur more regularly
That query is a really good idea but I think it could use a tidy up to make the data more sound, for instance it is bringing back error 50058 (which just means the user hasn't signed in yet, chances are they probably signed in a few seconds later successfully) and 50126 (wrong password) as 'failures'. If a user successfully signs into one app then 2 minutes later gets a wrong password from the same IP address to a different app then they have probably just typed their password in wrong.
// Only take hits where there is 5 or less distinct AppDisplayNames on the success side as this limits highly active applications where failures occur more regularly
That query is a really good idea but I think it could use a tidy up to make the data more sound, for instance it is bringing back error 50058 (which just means the user hasn't signed in yet, chances are they probably signed in a few seconds later successfully) and 50126 (wrong password) as 'failures'. If a user successfully signs into one app then 2 minutes later gets a wrong password from the same IP address to a different app then they have probably just typed their password in wrong.