Legacy (per-user) MFA and its effects on Security Defaults, PIM, CA Policies, and Identity Protection

Problem:

• You are preparing for the AZ-500 or MS-500 (security certs) and the interaction or lack thereof between the Legacy (per-user) multi-factor authentication (MFA) portal’s settings and all the other Microsoft Entra / Azure AD security features is confusing
• Or you are annoyed by the Microsoft/Pearson trick questions with misconfigured MFA and Conditional Access (CA) policies in their example questions, which make you scratch your head as to why anyone would configure MFA in such an ass backwards way
• Or maybe you are just interested in learning about the above interactions, as Microsoft does not a great job documenting it, other than to say “Don’t use Legacy (per-user) MFA!”

Solution:

• TL; DR for Security Defaults, Privileged Identity Managment (PIM), and CA policies IGNORE the Legacy (per-user) settings for Microsoft 365 users found in your tenant here: Legacy (per-user) MFA Portal
• BUT Azure AD Identity Protection polices do interact with these settings, in the sense that with all other security / access policies being set to default,
  • if a Conditional Access policy is enabled using risky sign-ins or risky users from Azure AD Identity Protection are triggered
  • AND MFA is required to grant access per the CA policy,
    • then users who are set to “enabled “or “disabled” in the Legacy portal
    • OR otherwise NOT enrolled in MFA
  • will be blocked from signing up for MFA and consequently from logging in.

Details:

Ok that last set of bullet points was complex and I will explain here, first how I learned this little info tidbit and second I will go into a bit more detail on this specific interaction in Azure AD.

If you are familiar with the AZ-500 or MS-500, you know that this cert focuses on security for the Microsoft cloud offerings and that consequently Azure AD (or is it Entra ID already?) security policies are a big part of this. Also, anyone with experience taking the Microsoft certification tests from Pearson knows that they like trick questions. Specifically, Microsoft enjoys creating scenarios with, what I would consider to be misconfigured systems, and then asking you how they would behave in a given scenario.

For example, you are show some Conditional Access polices and some users who are logging into Microsoft 365 or Azure, and the information about the users includes their MFA status. Well, this MFA status is referencing the Legacy (per-user) MFA portal, which Microsoft themselves will tell you stop using. Furthermore, as stated above CA policies ignore these settings. The test is trying to trick you. But also this information is, as far as I can tell, is not clearly documented by Microsoft. I have only found some forum posts with possible answers and I had to perform my own testing to confirm this.

As you can see, these various portals, settings, and methods for managing MFA can become very confusing quickly especially in a production environment. This is how I learned about these interactions and why, but the second question remains, what exactly is being evaluated between Legacy MFA and the other security settings?

Here is a more detailed explanation of how multiple security features in Azure AD in fact DO NOT interact with Legacy MFA:

• If you enable Security Defaults, you will notice that they your users are performing MFA, their status, most likely to be “disabled,” in the Legacy portal are meaningless
• PIM policies that “require MFA on activation” for a privileged account will ignore the Legacy (per-user) setting/status and unenrolled users will be prompted to enroll in MFA
• Once again, Conditional Access policies will ignore the Legacy (per-user) setting/status and unenrolled users will be prompted to enroll in MFA
  • But there is one very specific exception to CA policies ignoring Legacy (per-user) MFA
  • If the risk-based CA policies which are enabled by Azure AD P2 license feature called Azure AD Identity Protection
  • AND MFA is required to “Grant Access” in the CA policy
  • AND the user being evaluated by the CA policy has not yet signed up for MFA, either in the Legacy portal or via another method, such as the three security features listed above
    • See this excellent post from activedirectorypro.com explaining how you can determine per PowerShell script if the user has enrolled in MFA, whether via the Legacy portal or otherwise
  • Then the user’s log on attempt will be blocked and the user will NOT be prompted to enroll in MFA

Conclusion:

Following the logic of the above specific circumstance where a CA risk-based policy is affected by the user’s Legacy MFA status, it makes sense that Microsoft does this. If a user or their sign-in is deemed risky by Azure AD Identity Protection, AND said user has yet enrolled in MFA, then you do not want this risky login attempt to be able to register for MFA. The login attempt is deemed risky and therefore the user’s credentials might be compromised and you do not want an attacker to perform MFA enrollment for their victim.

I hope this post helps anyone trying to wrap their head around all this different settings and Microsoft’s lovely tendency to give IT admins 15 ways to skin the same cat but not exactly explaining how they do or do not play nice with another.