Introduction
I’ve been meaning to write about this for quite some time, but for some reason, it kept slipping my mind. Last year, a customer reached out to me with a perplexing issue: one of their users couldn't sign in due to sign-in error code 500121. Despite our efforts - deleting the user's authentication methods, asking them to re-register for MFA, and even issuing Temporary Access Passes (TAPs) - the problem persisted.
If you’re grappling with the same error, this post is for you. Let’s dive into the problem and how we resolved it.
Table of contents
Identifying the Issue
When attempting to sign in, the user inadvertently clicked ‘Not me’ during the number-matching prompt in Microsoft Authenticator. This could have been a slip of the finger or confusion about the sign-in location. Following this, the user would have seen:
In the MS Authenticator app: "Your account will be blocked preventing further sign in and your organization's IT Support staff will be notified of possible fraud." with options to Cancel or Report.
A subsequent message saying "Request denied" on the login page, accompanied by the error code 500121.
The sign-in logs provided further context:
Sign-in error code: 500121
Failure reason: Authentication failed during strong authentication request.
Additional details: The user didn't complete the MFA prompt. They may have timed out, opted not to authenticate, or encountered an issue with their MFA setup.
Diagnosing the Problem
We tried several troubleshooting steps:
Removing existing authentication methods.
Requiring the user to re-register for multifactor authentication.
Issuing a Temporary Access Pass (TAP).
None of these worked. Even when using the TAP, the user was met with a new error: “Temporary Access Pass sign-in was blocked due to User Credential Policy.”
This error typically occurs when the TAP has expired or has already been used if it’s configured as a one-time pass. However, I knew this wasn’t the case. The real issue lay deeper within the configuration.
The Root Cause: Multifactor Authentication – Blocked Users
Upon closer inspection, it turned out that the customer’s tenant had the Fraud Alert feature enabled with automatic blocking, alongside the Report Suspicious Activity setting.
What Happened?
When the user tapped ‘Not me’, the system interpreted this as a potential fraud attempt. This triggered an automatic block and flagged the user as high-risk. The blocked status prevented any further MFA attempts, including the use of a TAP.
Understanding Fraud Alerts and Report Suspicious Activity
Fraud Alerts: Users can report fraudulent MFA attempts through the Authenticator app or phone calls. If automatic blocking is enabled, MFA attempts for the reported account are blocked for 90 days or until manually unblocked by an administrator.
Report Suspicious Activity: This feature integrates with Microsoft Entra ID Protection, providing enhanced reporting and risk-driven remediation.
With both settings active, the user was placed on the blocklist and marked as high-risk after their accidental tap on ‘Not me’.
Resolution
To resolve the issue:
Verify the legitimacy of the sign-in attempt. After confirming it wasn’t a fraudulent sign-in but rather an accidental click, we moved forward with unblocking the user.
Unblock the user in Microsoft Entra ID:
Navigate to Security > Multifactor Authentication > Block/Unblock Users.
Locate the user and unblock them by providing a reason for the unblock.
You may also want to check Identity protection and clear the user and their sign-in from risky users and risky sign-ins (Entra ID > Security > Identity Protection > Risky users + Risky sign-ins), especially if you utilise user risk in your conditional access policies.
Once unblocked, the user was able to sign in using the TAP and re-register their MFA method without any further issues.
Important Considerations
The combination of keeping Report Suspicious Activity and Fraud Alert enabled at the same time gives defense-in-depth layers of security, with immediate user-initiated blocking of suspicious MFA requests and advanced risk-based remediation and reporting through Microsoft Entra ID Protection. Immediate action against threats can be instigated, meaning that users can self-protect their accounts and the administrators ultimately have very detailed insight into suspicious activities. Running both features in parallel allows a smooth transition to the newer system while maintaining robust protection until Fraud Alert is deprecated in March 2025.
Geographic Location in Notifications
In Entra ID > Security > Authentication Methods > Policies, there’s an option to enable “Show geographic location in push and passwordless notifications”.
While helpful, this feature can sometimes display inaccurate locations, such as showing a nearby city rather than the exact one. Organisations have different approaches to this:
Disabling the option to avoid confusing users.
Enabling it and training users to identify legitimate requests.
Though it might not pinpoint your exact location, it provides helpful context, especially if the prompt comes from an entirely different country.
Conclusion
Dealing with sign-in error code 500121 can be frustrating, but understanding the root cause often reveals a straightforward solution. Accidental clicks on ‘Not me’ in Microsoft Authenticator can trigger automatic blocks under Fraud Alert and Report Suspicious Activity settings. Unblocking the user and addressing the configuration ensures a smooth resolution.
Whether it’s training users on recognising legitimate prompts or revisiting your tenant’s security settings, proactive measures can prevent similar issues in the future.
댓글