We're back with another mailbag, this time focusing on your common questions regarding Azure AD Identity Protection. Security is always top of mind and Identity Protection helps you strike a balance between the usability required for end users to be productive while protecting access to resources. We’ve got some really great questions from folks looking to improve the effectiveness of their alerts and to increase their overall security posture. We even have a sample script for you! I’ll let Sarah, Rohini and Mark take it away.
Hey y’all, Mark back again for another mailbag. You’ve been asking some really great questions around Azure AD Identity Protection. So good, in fact, I’ve kept putting this off for an embarrassingly long time. Then I called in for some help from some excellent feature PMs Sarah Handler and Rohini Goyal.
Make sure that before you bulk dismiss users, you’ve already remediated them or determined that they’re not at risk. Then we have a GraphAPI call you can make to dismiss the user risk. We’ve put together a little sample script to help you with doing bulk dismissal.
We've provided a sample PowerShell script and examples to enumerate risky users, filter the results, and dismiss the risk for the collection.
We detect anonymizers in a few ways. For Tor, we continually update the list of Tor exit nodes. For VPNs, we use various third-party intelligence to determine whether an anonymizer has been used.
There are two ways to address false positives: giving feedback on false positive detections that occur and reducing the number of false positives that get generated. If while investigating risky sign-ins you find a detection to be a false positive, you should mark “confirm safe” on the risky sign-in. There are two ways to prevent false positives in Identity Protection. The first is to enable sign-in risk policies for your users. When a user is prompted for a sign-in risk policy with MFA and passes the MFA prompt, it gives feedback to the system that the legitimate user signed in and helps to familiarize the sign-in properties for future ones. The second is to mark common locations that you trust as trusted locations in Azure AD.
First, you want to make sure you’re putting in your public egress end points. This helps with our detection algorithms. We’ve recently increased the named locations to 195 named locations with 2,000 IP ranges per location. You can read more in our docs.
But we know that many times networking teams make changes and don’t notify the Azure AD Admins. It’s good to have a process to work through the Sign-In logs and look for IP ranges that are not part of your named locations and add those as well as remove IPs that no longer are your egress point.
Leaked credentials detection does not connect to Troy Hunt’s “Have I been Pwned”. Troy does an excellent job with his service correlating and collecting public dumps. Leaked credentials alerts take into account those public dumps as well as non-public dumps we call out in our docs, more info here. If you want to supplement the Azure AD leaked credentials alerting with other feeds, that is entirely up to you.
Leaked credentials will only detect on leaks going forward. When we find clear text username and passwords pairs, we don’t keep them. We process them through and delete them. We’ve updated our documentation to call this out and provided more info.
We hope you've found this post and this series to be helpful. For any questions you can reach us at AskAzureADBlog@microsoft.com , the Microsoft Forums and on Twitter @AzureAD , @MarkMorow, @Sue_Bohn, and @Alex_A_Simons
-Rohini Goyal, Sarah Handler and Mark Morowczynski
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.