I’m excited to announce the public preview of Azure AD My Sign-Ins—a new feature that allows enterprise users to review their sign-in history to check for any unusual activity. As we discussed in a previous blog post, our team defends against hundreds of millions of password-based attacks every day.
The My Sign-Ins page empowers users to see:
If anyone is trying to guess their password.
If an attacker successfully signed in to the account from a strange location.
What apps the attacker tried to access.
Robyn Hicock, who managed this feature, wrote a guest blog post where she dives into the details on this update. You’ll find her blog post below.
As always, we’d love to hear any feedback or suggestions you may have. Please let us know what you think in the comments below or on the Azure AD feedback forum.
Just click the My Sign-Ins tile to display the location details of how an account was accessed.
Here’s an example where I successfully signed in to Office 365 on Windows 10 from Washington:
Most users should recognize their activity as being normal. However, if a user notices a Successful sign-in from strange location, browser, or operating system, an attacker may have gained access to the account. In this case, the user should change their password immediately and then go to the Security info page to update their security settings.
There is a chance of a false positive since the approximate location and map is based on the IP Address (we call this “IP Address Geolocation”). Mobile networks are especially hard to geolocate since they sometimes route traffic through distant locations. For example, if a user signs in on their phone from Washington, the location might show the sign-in coming from California. This is why it helps to check more details about the sign-in, such as the operating system, browser, and app to confirm if it’s actually bad activity.
An Unsuccessful sign-in, which shows no session activity, means that primary authentication (username/password) failed. This could mean that the user mistyped their password or an attacker was trying to guess the password. If it’s because an attacker was trying to guess the password (but was unsuccessful), then there’s no need for the user to change their password. However, this is a great reason for the user to register for Azure Multi-Factor Authentication (MFA), so even if the hacker eventually guesses the password, it won’t be enough to access the account. Based on our studies, accounts protected by MFA are 99.9 percent less likely to be compromised.
An Unsuccessful sign-in, which shows Session activity of “Additional verification failed, invalid code,” means that primary authentication (username/password) succeeded, but MFA failed. If it was an attacker, they correctly guessed the password but were unable to pass the MFA challenge—such as round tripping a code to a phone number or by using the Microsoft Authenticator app. In this case, the user should still change their password (since the attacker got it right) and go to the Security info page to update their security settings.
You can use the Search bar at the top to filter sign-ins by state, country, browser, operating system, app, or account. For example, below I filtered sign-ins in to the My Groups app:
In the future, we’ll add This wasn’t me and This was me buttons. We’ll also highlight unusual activities detected with Identity Protection. This user feedback will help improve the accuracy of our risk detection systems. We do all of this already with the Recent Activity page for consumer Microsoft Accounts.
We’d love to hear your feedback and suggestions on the My Sign-Ins Public Preview before it becomes generally available. Please let us know what you think in the comments below or on the Azure AD feedback forum.