User keeps getting locked out of account and removed from private Channels

Question

We manage the accounts for a large organisation and have gone completely serverless. We currently have one single user who keeps getting her sign in blocked which wouldn't be too much of a problem, but we need to keep unblocking her and adding her to about 50+ Teams channels every time this is happening which is about every 4 hours. She had shown up in the AAD Risky Users, so we looked at her sign-ins and since they were all from her registered IP and location, we decided to dismiss the risk and unblock her account after resetting password. However, the problem keeps reoccurring even after having removed her from Risky Users.

Checked the sign-in logs again for the user and can see that every time a login is attempted there are anywhere from 2-5 login attempts made within the same second. Usually they will all be successful but after she tries logging in a few more times she begins to get failures again and an account block is put in place. What could be the cause for this and what are the resolutions? The whole organisation does not use 2FA and nearly everything online assumes that the multiple sign-in attempts are from foreign, hostile entities with suggestions to enable location based conditional rules. However, this would not help in our case.

Answer 1

Hi @TJ ,

Which specific login properties are triggering the risky sign-in? Properties can include IP, ASN, location, device, browser, and tenant IP subnet. https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks

Are all of the risks flagged as location risks when the user is not actually in a risky location, or is it a true flag but one that you would like to dismiss?

You can use the "What If" tool to troubleshoot Conditional Access to troubleshoot which policies are being applied. https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/what-if-tool

If the user is being blocked due to her location, you have several options depending on your scenario and goals:

1) Could you clarify why location-based conditional rules would not help in your case? If you want to make an exception just for that user and not for the entire country, you can add the user as an "exception" to your conditional access policy.

2) If you want to mark that location in general as a "trusted location", you do that under "Named Locations."

Note that if they do an initial login in one location, and then login from another location, the login could be getting flagged in Azure AD as "risky activity."

I would also check if the "moved to a new location" flag is getting set under conditional access locations in Azure, and then clear that flag.

3) A good way to grant access to specific users traveling to specific countries or temporarily located in those countries is to create a universal "exclude" group in your Conditional Access policies, and then add those users to that group when they are traveling or located in those countries.

Then if you enforce MFA for untrusted locations and have those users added as an exemption to your "block international countries", any attempts to access those accounts outside of your trusted locations will still be prompted for MFA.

So in summary, you can have a general policy to block access from "All locations" or all international locations, and then exclude the countries where you want to allow access. You would then create a separate policy to enforce MFA for all locations and exclude the ones marked as "trusted." Normally this is used for travel so that when your users go on vacation since you can add them to your "universal exclude" group and remove them from that group when they return. But it sounds like you could apply similar logic if you have a user who is triggering the location flag frequently.

Let me know if this helps and if you have further questions. If you can share more details about the risks being triggered, I'll be able to offer more suggestions.

-
If the information helped you, please Accept the answer. This will help us and other community members as well.