{"id":7201,"date":"2023-07-18T08:59:55","date_gmt":"2023-07-18T07:59:55","guid":{"rendered":"https:\/\/rakhesh.com\/?p=7201"},"modified":"2023-07-18T08:59:55","modified_gmt":"2023-07-18T07:59:55","slug":"more-mfa-stuff-authentication-successful-but-you-cannot-access-this-right-now","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/azure\/more-mfa-stuff-authentication-successful-but-you-cannot-access-this-right-now\/","title":{"rendered":"More MFA stuff (Authentication successful but you cannot access this right now)"},"content":{"rendered":"

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

\"\"<\/p>\n

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

\"\"<\/p>\n

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).<\/p>\n

\"\"<\/p>\n

This is usually harmless, but there is a situation when this could be a pain in the ass.<\/p>\n

Conditional Access policy limiting Security Info registration<\/h3>\n

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.<\/p>\n

You can do so by creating a new policy like as below.<\/p>\n

Assignments<\/strong>: Apply to all users (or a selected group)<\/p>\n

\"\"<\/p>\n

Target resources<\/strong>: User actions of the type “Register security information”<\/p>\n

\"\"<\/p>\n

Conditions<\/strong>: Applies to all locations, but excludes trusted locations.<\/p>\n

\"\"<\/p>\n

And the device filter excludes certain types of machines.<\/p>\n

\"\"<\/p>\n

Grant<\/strong>: The action is to Block.<\/p>\n

\"\"<\/p>\n

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”.<\/p>\n

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)<\/a> and they can do it<\/a>.<\/p>\n

What’s the issue?<\/h3>\n

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”.<\/p>\n

\"\"<\/p>\n

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.<\/p>\n

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.<\/p>\n

Not so legacy after all<\/h3>\n

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

Worse, even the Per-user MFA portal still has some settings that are used. For instance, this one:<\/p>\n

\"\"<\/p>\n

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!<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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 … Continue reading More MFA stuff (Authentication successful but you cannot access this right now)<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[887],"tags":[182,982,1002,1003],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/7201"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=7201"}],"version-history":[{"count":4,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/7201\/revisions"}],"predecessor-version":[{"id":7217,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/7201\/revisions\/7217"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=7201"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=7201"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=7201"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}