I experienced an interesting issue the other day. A user was being repeatedly prompted to register his authentication details, and ending up in a redirect loop between the “proofup” page and the login one. Here’s the most interesting part – requiring the user to re-register for MFA allowed him to bypass the loop… until the next time he had to login!
The other interesting observation was that the login page presented a slightly differently worded message:
Your organization needs more information to keep your account secure. Before making changes to your security info you must complete multifactor authentication.
That second sentence is not something I’ve encountered previously, although if I’m being honest I didn’t even pay that much attention to it initially. After exhausting the standard troubleshooting steps, I had to start paying more attention to details, at which point a quick search online revealed only a single match for said phrase. Unsurprisingly, the match is a thread over at the community forums describing a similar issue of the loopy variety.
Long story short, the culprit turned out to be the per-user multifactor authentication settings, resetting which resoled things. I am not entirely sure what exactly was wrong with the per-user settings, as I have been unable to reproduce the issue with a different user. Just in case, I figured I’d put a quick post about it, so the next poor soul that runs into it has more chances to resolve it (like you’d expect to find a solution over at Answers :D).
Anyway, as I am already wasting ink on this, let me put some additional details. While the message above clearly hints at a missing registration info, the user in question had sufficient methods registered, for both MFA and SSPR coverage. The User registration details report also confirmed this, with the user appearing as Capable in all categories, and with the configured authentication methods listed. Yet, for some reason, Entra ID was triggering the registration process again and again and again…
As mentioned above, requiring the user to re-register MFA methods changed the behavior a bit. At this point, the user was presented with the familiar (shorter) “Your organization needs more information to keep your account secure.” message, without the second part we saw above, and was actually able to login, configure his methods anew, and access the service. Only to have the exact same thing happen on the next login.
What’s more puzzling was that the directory audit log trail showed the “User registered all required security info“ event, with a “success” status. Yet, subsequent login events again resulted in the dreaded 50072/Interrupted status, and with “The user was presented options to provide contact options so that they can do MFA” string for additionalDetails, so no joy. Next I tried adding methods on behalf of the user, hoping that it would satisfy the proofup requirements. No luck with that either.
At this point I was getting a bit desperate, so I resorted to an in-depth analysis of the sign-in logs (including “flagging” some events). An example set of sign-in logs is shown below, all from the same session. As you can see, after successfully providing the password, the user gets redirected to the proofup page for some unknown reason. Said page in turn enforces a strict MFA requirement, i.e. expects the token to have the corresponding claim (as indicated by the App requires MFA policy value, more details for example in this thread). Interestingly, the user was never prompted to actually perform MFA, which sort of explains the loop. Yet I still have no idea why the MFA prompt never materialized – trusted locations should not matter here. Nor have I figured out why the proofup process was triggered to begin with, as all required methods were just registered.
Anyway, while I again failed to spot anything out of the order, this last examination of the sign-in logs finally reminded me to check the per-user MFA status for the user, and lo an behold, resetting that resolved the issue. So in a nutshell, if you run into a login loop with the user repeatedly being redirected to the proofup page, while you also get this “long” message on the login screen, and never see an MFA prompt even though it is required for the proofup process, you might be in the same boat as I was. The solution turned out to be resetting the per-user MFA status, which you can now also do via the Entra portal.