Frequently asked questions Identity Protection in Azure Active Directory

Dismiss user risk known issues

Dismiss user risk in classic Identity Protection sets the actor in the user’s risk history in Identity Protection to Azure AD.

Dismiss user risk in Identity Protection sets the actor in the user’s risk history in Identity Protection to <Admin’s name with a hyperlink pointing to user’s blade>.

There's a current known issue causing latency in the user risk dismissal flow. If you have a "User risk policy", this policy will stop applying to dismissed users within minutes of clicking on "Dismiss user risk". However, there are known delays with the UX refreshing the "Risk state" of dismissed users. As a workaround, refresh the page on the browser level to see the latest user "Risk state".

Frequently asked questions

Why is a user at risk?

If you're an Azure AD Identity Protection customer, go to the risky users view and select an at-risk user. In the drawer at the bottom, tab ‘Risk history’ will show all the events that led to a user risk change. To see all risky sign-ins for the user, select ‘User’s risky sign-ins’. To see all risk detections for this user, select ‘User’s risk detections’.

Why was my sign-in blocked but Identity Protection didn't generate a risk detection?

Sign-ins can be blocked for several reasons. It's important to note that Identity Protection only generates risk detections when correct credentials are used in the authentication request. If a user uses incorrect credentials, it will not be flagged by Identity Protection since there isn't of risk of credential compromise unless a bad actor uses the correct credentials. Some reasons a user can be blocked from signing that won't generate an Identity Protection detection include:

  • The IP can be blocked due to malicious activity from the IP address. The IP blocked message doesn't differentiate whether the credentials were correct or not. If the IP is blocked and correct credentials aren't used, it will not generate an Identity Protection detection
  • Smart Lockout can block the account from signing-in after multiple failed attempts
  • A Conditional Access policy can be enforced that uses conditions other than risk level to block an authentication request

How can I get a report of detections of a specific type?

Go to the risk detections view and filter by ‘Detection type’. You can then download this report in .CSV or .JSON format using the Download button at the top. For more information, see the article How To: Investigate risk.

Why can’t I set my own risk levels for each risk detection?

Risk levels in Identity Protection are based on the precision of the detection and powered by our supervised machine learning. To customize what experience users are presented, administrator can include/exclude certain users/groups from the User Risk and Sign-In Risk Policies.

Why does the location of a sign-in not match where the user truly signed in from?

IP geolocation mapping is an industry-wide challenge. If you feel that the location listed in the sign-ins report doesn't match the actual location, reach out to Microsoft support.

How can I close specific risk detections like I did in the old UI?

You can give feedback on risk detections by confirming the linked sign-in as compromised or safe. The feedback given on the sign-in trickles down to all the detections made on that sign-in. If you want to close detections that aren't linked to a sign-in, you can provide that feedback on the user level. For more information, see the article How to: Give risk feedback in Azure AD Identity Protection.

How far can I go back in time to understand what’s going on with my user?

  • The risky users view shows a user’s risk standing based on all past sign-ins.
  • The risky sign-ins view shows at-risk signs in the last 30 days.
  • The risk detections view shows risk detections made in the last 90 days.

How can I learn more about a specific detection?

All risk detections are documented in the article What is risk. You can hover over the (i) symbol next to the detection on the Azure portal to learn more about a detection.

How do the feedback mechanisms in Identity Protection work?

Confirm compromised (on a sign-in) – Informs Azure AD Identity Protection that the sign-in wasn't performed by the identity owner and indicates a compromise.

  • Upon receiving this feedback, we move the sign-in and user risk state to Confirmed compromised and risk level to High.

  • In addition, we provide the information to our machine learning systems for future improvements in risk assessment.

    Note

    If the user is already remediated, don't select Confirm compromised because it moves the sign-in and user risk state to Confirmed compromised and risk level to High.

Confirm safe (on a sign-in) – Informs Azure AD Identity Protection that the sign-in was performed by the identity owner and doesn't indicate a compromise.

  • Upon receiving this feedback, we move the sign-in (not the user) risk state to Confirmed safe and the risk level to None.

  • In addition, we provide the information to our machine learning systems for future improvements in risk assessment.

    Note

    Today, selecting confirm safe on a sign-in doesn't by itself prevent future sign-ins with the same properties from being flagged as risky. The best way to train the system to learn a user's properties is to use the risky sign-in policy with MFA. When a risky sign-in is prompted for MFA and the user successfully responds to the request, the sign-in can succeed, and help to train the system on the legitimate user's behavior.

    If you believe the user isn't compromised, use Dismiss user risk on the user level instead of using Confirmed safe on the sign-in level. A Dismiss user risk on the user level closes the user risk and all past risky sign-ins and risk detections.

Why am I seeing a user with a low (or above) risk score, even if no risky sign-ins or risk detections are shown in Identity Protection?

Given the user risk is cumulative in nature and doesn't expire, a user may have a user risk of low or above even if there are no recent risky sign-ins or risk detections shown in Identity Protection. This situation could happen if the only malicious activity on a user took place beyond the timeframe for which we store the details of risky sign-ins and risk detections. We don't expire user risk because bad actors have been known to stay in customers' environment over 140 days behind a compromised identity before ramping up their attack. Customers can review the user's risk timeline to understand why a user is at risk by going to: Azure portal > Azure Active Directory > Risky users report > select an at-risk user > details drawer > Risk history tab

Why does a sign-in have a “sign-in risk (aggregate)” score of High when the detections associated with it are of low or medium risk?

The high aggregate risk score could be based on other features of the sign-in, or the fact that more than one detection fired for that sign-in. And conversely, a sign-in may have a sign-in risk (aggregate) of Medium even if the detections associated with the sign-in are of High risk.

What is the difference between the "Activity from anonymous IP address" and "Anonymous IP address" detections?

The "Anonymous IP address" detection's source is Azure AD Identity Protection, while the "Activity from anonymous IP address" detection is integrated from Microsoft Defender for Cloud Apps). While they have similar names and you might see overlap in these signals, they have distinct back-end detections.