More MFA stuff (Authentication successful but you cannot access this right now)

Ever encountered this situation where in you are logging in to Azure/ M365 and get the following “More information required” prompt:

You click Next, and are taken to this “Is this info up to date?” screen where there isn’t much to do:

This happens because Azure AD/ Entra ID has a setting that checks for freshness of your security info. It’s under Password Reset > Registration and is by default 180 days. (In the screenshot below I have set it to 1).

This is usually harmless, but there is a situation when this could be a pain in the ass.

Conditional Access policy limiting Security Info registration

Say you want to limit who can register their security info. You don’t want users to be able to do this from anywhere/ any device due to security reasons – it must be from trusted networks or an Azure AD registered/ Hybrid joined machine.

You can do so by creating a new policy like as below.

Assignments: Apply to all users (or a selected group)

Target resources: User actions of the type “Register security information”

Conditions: Applies to all locations, but excludes trusted locations.

And the device filter excludes certain types of machines.

Grant: The action is to Block.

Essentially this policy says “block all attempts at registering security information, for all users, unless it’s from trusted networks or specific types of machines”.

If, for whatever reason, a user needs to register their information from a machine or network that isn’t in the above criteria, no big deal. The service desk can generate a Temporary Access Pass (TAP) and they can do it.

What’s the issue?

The issue is that with the above policy in place when a user tries to login, they are able to login successfully (including pass any MFA requirements) but then they get the “More information required” window (because they have hit the re-confirm period) and then… boom! “You cannot access this right now”.

At this point the user is effectively locked out until they either contact the service desk, get a TAP (assuming that is configured), and use that to get to the “Is this info up to date?” screen, confirm things and log in. Or else, login from a trusted network or device.

I encountered this at work recently because we turned on a similar Conditional Access policy to limit security info registration and that led to a bunch of tickets where users couldn’t login. I started digging around and found the freshness setting. It was set to the default 180 for us.

Not so legacy after all

Thing is, I sort of knew about that setting. But once we migrate from legacy SSPR settings (my previous post) I figure this is not used any more. But nope, it is!

Worse, even the Per-user MFA portal still has some settings that are used. For instance, this one:

If that is ticked (the default) users continue getting the option to remember MFA even though this is the legacy portal and one assumes post-migration it won’t be used at all!