Signals from across Microsoft’s services and ecosystems inform Entra ID Protection to detect risk. The risk detections can alert administrators or, better still, combine with other Entra and Defender XDR capabilities to perform remediation and prevention. The most obvious example of this may be preventing a risky sign in. Contrary to popular understanding, not all of Entra ID Protection’s detections are limited to the Entra ID P2 license: the nonpremium risks listed here don’t require P2.

Note: Microsoft Entra ID Protection was previously known as Azure AD Identity Protection.

I’ve conducted hundreds of Microsoft 365 and Entra ID tenant assessments over the years, and recommended ID Protection in just about all of them. Trends of common mistakes start to become apparent in configuration, response, and admins misunderstanding the capabilities themselves.

This is part of a series on common Microsoft 365 security mistakes. View the previous blogs here:

Table of Contents

Requiring password reset on passwordless users

A common Entra ID Protection policy is to require high risk users reset their password. This is coupled with password writeback for hybrid users, and a new preview allows on-prem password changes to reset the risk score too.

Although the reasons for specific risk level (low, medium, high) are a bit abstract, it means an increasing probability the account is compromised. Since removed, the documentation used to advise a high user risk was associated with the Leaked credentials risk so we can assume it’s still one of the reasons. Hence the idea of forcing a password change after satisfying MFA. Admins usually enforce this with a Conditional Access rule.

If you have a passwordless this scenario could catch you out:

  • User is passwordless from day one, using a temporary access pass to register a FIDO2 security key
  • User becomes high risk (in addition to Entra ID Protection doing it, Microsoft Defender XDR can flag users as high risk if they are marked as compromised)
  • User authenticates with their FIDO2 security key
  • User is required to reset their password

When this high risk user signs in, they won’t know their password (if you’ve been a good passwordless admin and not given them it), so will fail the reset and not be able to proceed.

As an alternative, you could create an Entra ID group of your passwordless users and exclude them from any reset password policies. You may want to have a block policy instead which will be a little clearer to the end user when they hit the failed sign-in.

‘Confirm sign-in safe’ doesn’t inform future detections

Here’s a mistake I made until recently. Let’s run through the scenario.

  • You sign into an Azure VM with a static public IP
  • Entra ID Protection flags it as medium risk (unfamiliar sign-in properties)
  • A Conditional Access policy blocks the medium risk sign-in
  • An admin marks the risky sign-in as confirmed safe sign-in in Entra ID Protection

Can you now sign in under the same circumstances?

If you, intuitively, thought “yes”, the next screenshot might drag you back to reality.

I expected the system to “learn” that marking a risky sign-in as confirmed safe would inform future risk assessments. If it was marked risky due to the sign-in properties, then an admin confirmed thise properies as safe, why wouldn’t it inform future risk determinations?

Jef Kazimer (who you need to follow ASAP for fantastic community contributions!) kindly pointed out to me that the documentation confirms it:

If you have a scenario like the above, your only option is some kind of exclusion (or adding the IP as trusted in this example). Not ideal, but I’m hopeful the wording of “today” in the above means we can expect improvements in the future.

Policies don’t need to be one-size fits all

This is a mistake I see throughout Microsoft 365 and Entra ID regarding security controls. You’ll see it coming up in many of the Common Microsoft 365 Security Mistakes Series blogs. If you can limit something to a group, you can refine it and have different rules for different scenarios. Sounds obvious, but it’s often overlooked in practice.

Rather than using the User risk policy or Sign-in risk policy pages in the Identity Protection page, if you use Conditional Access to manage authentication restrictions based on Entra ID Protection risk, you can have a harder policy for privileged users than standard users. Here’s some illustrations.

  • For standard users, block acess if the user is high risk.
  • For executive team users, block access if the user is medium risk or greater.
  • For users with privileged role access such as Global Administrator, block access if the user is low risk or greater.

With each lower risk threshold, you increase the amount of overhead: the risk and response to authentications that you want to allow. But this is the trade-off you may want to make based on risk appetite and so on.

If you take anything away from this point, it’s not that I want you to go really aggressive and only tolerate low or lower risk authentication; it’s that I want you to not make excuses for not at least starting with Entra ID Protection. Using scopes, you can start small with quick wins and build up your use as your confidence grows.

Excluding guests from user risk policies

Earlier, I covered the mistake of taking a one-size fits all approach to Entra ID Protection; better scope policies depending on user, risk appetite, and so on. A mistake you want to avoid on the opposite side of the coin is blanket exclusion of guests for Entra ID Protection.

A common reason for excluding guests from Entra ID Protection policies is that you can’t control their account credentials, which are “homed” in the source tenant, and therefore you cannot enforce password resets or dismiss a user-level risk to allow authentication (sign-in risk, meanwhile, is based on the tenant they’re authenticating against, i.e. yours). If a policy tries to force a password reset, it’s just replaced by a block.

The logic goes: I don’t want my guests to get locked out and affect our productivity, therefore we can’t enforce user-based risk policies.

I get it. But let’s remind ourselves that in most guest access scenarios, you have far less oversight and control over the security of that user, their device, and therefore the session. It’s possible, but rare, that customers check for the device compliance of a guest. Overwhelmingly, we just let them in with no attestation about device security. So, my logic goes: if anything, we should be more aggressive with Entra ID Protection policies for guests.

This won’t be one you can go gung-ho into, but something to consider.

Watch out for audit retention gotchas

The retention period of Entra ID logs varies by license level, but risky users never expire.

This means at the free level, you’ll only see seven days of risk-sign ins. Entra ID P1 bumps this up to 30 days, and Entra ID P2 goes to 90 days. Unfortunately, this cannot back-date if you upgrade licenses. For example, if you have an incident then decide to buy P1/P2 to get more data, that won’t help.

Where this can also sting is if you’ve never investigated Entra ID Protection, then decide to pick it up. Entries in the Risky users page are not affected by the retention periods, but the data you need to investigate may be. For example, the Risk last updated field can be beyond your log retention and you may not be able to follow up with a comprehensive investigation into other Entra ID logs such as Risky sign-ins or Risk detections.

To avoid that problem, keep on top of risk investigations and/or export your data to another solution such as Log Analytics or Sentinel. Defender XDR’s maximum retention period of 180d may help, but not with advanced hunting.

Bonus: watch your check boxes!

This one’s pretty small, so consider it a bonus heads up. When targetting risk using Conditional Access, the risk levels do not mean “greater than or equal to”. So, if you only tick Low as a condition, you are not targetting Medium or High.

Conclusion

Entra ID Protection is a very useful tool in your defense strategy. There have been lots of incidents I’ve seen that could have been completely prevented were it configured appropriately, or at least monitored. I even struggled to keep this article down to five mistakes, as there are others that may bite you! In addition to avoiding the traps in this article, start giving Entra ID Protection a deep dive, so that you understand what it’s capable of and its nuances.

Tags:
Last updated on February 7, 2024