Root-Cause Investigation of MFA Prompts in MS365

Problem:

• You need to disable MFA for a service account AND CANNOT USE AN APP REGISTRATION
• Or you just need to determine what is causing an account’s MFA prompts
• You want to disable legacy MFA but keep all the users’ registered MFA methods

Solution:

• I have 5 places in MS365 / Azure for you to look and a few scripts to help better manage MFA status
• The five portals determining MFA status / prompts are:
  • The first place you should check, the sign in logs in Azure AD
  • Then the legacy (per-user) MFA portal
  • Check that security defaults are not enabled for the whole tenant under Azure AD properties
  • Your conditional access policies in Azure AD
  • The privileged identity management (PIM) portal
  • The sign-in and user risk policy portal under Azure AD Identity Protection
  • Possible on-prem MFA solutions such as third-party services, ADFS, or Azure MFA Server
• If you want to disable security defaults or legacy (per-user) MFA, but retain the user’s saved MFA methods (registered Microsoft Authenticator App, phone numbers, etc…), there is a nice script for this available from Philippe Signoret (psignoret) on Github

Details:

You have an account that is getting MFA prompts when it shouldn’t. Maybe you need to disable MFA temporarily, maybe it is the wrong format of prompt, or maybe you are breaking the rules by using a user account when a service principal would do; I won’t judge. Regardless you need to determine where these prompts or coming from and turn them off, while retaining the user’s registered MFA methods.

Obviously the sign-in logs in Azure AD can tell you how, where, when, and what MFA methods were required by a user’s login to Azure AD. You can click on the sign-in in question and investigate the details and in particular under “Authentication Methods” and “Conditional Access” you can see if MFA was required and in what form.

Now that you know where the MFA prompt is coming from you can investigate deeper. The legacy (per-user) MFA portal is usually irrelevant, as most other MFA prompting features, will simply override it or ignore it, as I wrote about in this blog post. In a similar vein, check that Security Defaults are not simply activated, requiring that everyone users is prompted for MFA. Typically in the these MFA-problem cases, I find that some interlocking and complex series of conditional access policies in Azure AD are causing the issue. Be sure to use the “What-If” feature in the conditional access portal to theory-test all possible variants of log in for the affected account. Especially check the device conformity policies, as I have often found that the device is root-cause of the issue and not the user’s account settings.

If it isn’t a Conditional Access problem then you have to start looking at some of the more “advanced” features like privileged identity management and sign-in and user risk policies. If you are getting this deep into the weeds though, be sure to also check the problem account’s assigned licenses. If they do not have Azure AD P1 or P2 licenses, then these features are not causing the problem.

Disable Legacy MFA without losing registered methods

There is a bit of a catch here when disabling MFA for end-users in the Legacy (per-user) portal. You will wipe out the user’s registered authentication methods. Thus if you want to switch from Legacy to Conditional Access based MFA (which you definitely should), then here is a nice bit of scripting from Philippe Signoret (psignoret) on Github. These two functions in this short PowerShell script allow you to set a user to “Disabled” in the Legacy portal, while restoring / not wiping their registered MFA methods, such as their phone number or Microsoft Authenticator registration. This will keep your users happy. Enjoy and I hope this little post helps!