Currently, managing MFA in Azure is… complicated. We have two separate policies which theoretically apply to the same things but in practice allow and disallow different things. In this post, we will cover migration to new consolidated policy (thank you MS!), lessons learned, and what MS should look at. Additionally, we will talk about physical MFA tokens (which have been ‘In Preview’ for last TWO YEARS!!!) and what really should be fixed about them!
Old policies?
If you have no idea what I am talking about, quick summary. Currently, we have two places where we can manage MFA: Legacy ‘Per-user’ MFA methods and ‘Password-reset’ MFA methods.
To check the legacy one, go to: https://portal.azure.com, select Entra ID, Users and then ‘Per-user MFA’.
At the newly opened webpage select ‘Service settings’ and here you go! Now you can see legacy per-user MFA settings.
As you can see the ‘Call to phone’ option is disabled BUT only on new tenants and/or tenants where that option was enabled in the past. Why shouldn’t you use that option? Because the only form of verification when workflow is triggered, is to press ‘0’ on the keypad.. Would it be possible to use a short code to verify a user? Yes, but I assume Microsoft wants the user to move to a better form of second factor like Authenticator App or a hardware security key.
To check the ‘Password reset’ one, please go to https://portal.azure.com, select Entra ID, and then Password Reset. Now you can see MFA methods which can be configured for password reset flow in Azure:
Note: With password reset portal enabled it is better to keep both policies matching. Why? Because you can cause a situation when the user will be able to enroll one MFA method but never use it! Confusing, right?
Note 2: On the screenshot above, you can see that some methods are not greyed out. That is because my tenant is already migrated.
Okay, let’s move to the new policy!
It is not that easy, we need to do it in 3 phases:
- Pre-migration phase: Use policy for authentication only, respect legacy policies.
- Migration in progress: Use policy for authentication and SSPR, respect legacy policies.
- Migration Complete: Use policy for authentication and SSPR, ignore legacy policies.
Happy to say, right now you are in the ‘Pre-migration phase’, only two more steps and you are done! But before we kick it off, let’s have a quick look at the new ‘Authentication Policy’, go to: https://portal.azure.com, select Entra ID, Security and then Authentication Methods.
Okay, we know how to check old policies, we know how many steps we need to perform for migration but those names… each policy names each method differently (thanks MS!), so let’s clear up situation:
| Multifactor (Legacy) authentication policy | Authentication method policy |
|---|---|
| Call to phone | Voice calls |
| Text message to phone | SMS |
| Notification through mobile app | Microsoft Authenticator |
| Verification code from mobile app or hardware token | Third party software OATH tokens Hardware OATH tokens Microsoft Authenticator |
| SSPR authentication methods | Authentication method policy |
|---|---|
| Mobile app notification | Microsoft Authenticator |
| Mobile app code | Microsoft Authenticator Software OATH tokens |
| Email OTP | |
| Mobile phone | Voice calls SMS |
| Office phone | Voice calls |
| Security questions | Not yet available; copy questions for later use |
We now know everything we need to move to the new method. The first step to move is to set new Authentication aligned with old two policies.
What does it mean? It means that if in one of the old policies you picked ‘Text message’ and/or ‘Mobile Phone’ then in the new policy you want to select ‘SMS’.
What if in one policy you have selected the ‘Notification through mobile app’ option but in the second one you have not selected ‘Mobile app notification’? Well, you need to decide if you want to have it enabled or not. For this specific one I would suggest to have it enabled!
I know what options I want, is that all?
Nope, with new ‘Authentication Policy’ you have a few additional tweaks you’ll want to configure before deployment:
- For Microsoft Authenticator, you want to check the configure section, what I would suggest it definitely enabling the option for number matching (it will show you a two digit number that you need to out in MS Authenticator app notification), showing application name and geographic location. MS Authenticator on companion apps works as designed, enabling it or not is up to you and your company policy.
- For SMS option a very interesting option is called ‘Use for sign-in’ enabled by default (not cool MS, not cool), why not cool? Because it allows your users to use their phone number to log in. Personally I am not a fun of this option being enabled by default. Can cause quite a mess in the environment!
- A few more options worth checking and implementing maybe separately from the policies consolidation that we are performing right now are ‘Passkey (FIDO2)’, ‘Temporary Access Pass’. Others worth checking out if you have a use case for them are ‘Third-party software OATH tokens’ and ‘Certificate-based authentications’.
Note: I have totally skipped ‘Hardware OATH tokens’ as I will speak about those in a separate post! Part two of this article.
Now we are REALLY ready!
Once you’ve decided what MFA methods you want to implement, tweaked all the settings for each and disabled hidden settings, you are really ready to move to ‘Migration in progress’ state. What will really happen? Once you switch it to new state, all new policies will be applied BUT old ones will take precedence. It gives you the opportunity to disable MFA methods one by one in old policies so new ones will take over. Once you disable all entries in the old one you can move migration to ‘Migration Complete’ state.
That is it, all done!
In next post I will speak little more about Hardware tokens!
~Kamil
Sources:
- How to migrate MFA and SSPR policy settings to the Authentication methods policy for Microsoft Entra
- Configure and enable users for SMS-based authentication using Microsoft Entra ID
- How number matching works in multifactor authentication push notifications for Authenticator – Authentication methods policy
- How to use additional context in Microsoft Authenticator notifications – Authentication methods policy