Released to Azure AD in December 2022 there is now a process for migrating from the legacy MFA methods and Self-Service Password Reset (SSPR) authentication methods to the unified Authentication Methods policies in Azure AD. This migration window is open until Jan 2024 when the legacy methods will be disabled. This change will allow you to manage all your various authentication methods from a single place and the migration work will take from a few hours to a day in total. To integrate this work with a review and improvement of your Conditional Access rules would require more time.
What are Authentication Methods
At the time of writing, also December 2022, not all legacy methods are available in the new Authentication Methods policy and so if you are using (and plan to keep using) Hardware OATH tokens for MFA or Security Questions for SSPR then you should not complete the migration to Authentication Methods. You can though move to the “migrating” stage of this process rather than the “migrated” stage in preparation for their eventual release and your configuration. If you are using neither of these methods then you can migrate now, noting though that some of these methods are in preview in Authentication Methods policy though they have been in use for years in the legacy methods.
So, what is a “method”. I have mentioned “authentication methods” above and these are the ways to add to your authentication when doing MFA or SSPR. For example, a method is “SMS” or “Voice Call” or “Software OATH” (OATH being the six-figure token that typically changes every 30 seconds as seen in Google Authenticator, Microsoft Authenticator and a number of other apps).
I have also previous written on the topic of Authentication Strengths which allows you to restrict the use of the weaker methods when signing into an application that is protected by MFA and help move to phish-resistant MFA. Authentication Strengths go hand in hand with the new Authentication Methods policy – for example you might decide to disable SMS as a method for the tenant (that is, not enabled as an Authentication Method) or you might decide to enable it tenant wide but only allow it to be used for some apps or users via Conditional Access (Authentication Strengths) or enable it only for some users (Authentication Methods, assigned to a group rather than all users) and just require “MFA” in your Conditional Access rules or by way of Security Defaults.
So how do you migrate to the new Authentication Methods. First you need to enable the Combined Registration Wizard. This was enabled for all tenants created after Aug 15th 2020 and at the time of writing Microsoft are enabling it for all previously created tenants if not done already by the tenant admin. This is highly recommended to do now if not done. Both as it will be turned on by Microsoft without notice and because it defaults to a secure MFA method as first step of the MFA registration (authenticator app) rather than SMS or voice for MFA (the old registration process).
Once you have the new registration wizard for authentication methods enabled you need to document your current configuration (pre-migration), update Authentication Methods policy to match or improve upon your legacy settings (migration) and then finally turn off the legacy method support (migrated). This process is documented by Microsoft and my steps here were put together with my colleague and fellow MVP Matt Levy (blog).
Pre-Migration
Before you start you need to document your current MFA and SSPR legacy methods configuration. This is quite easy, as these are global settings for MFA and for SSPR, if enabled for a group, it is for one group only.
The policies are located at:
- Azure Active Directory > Security > Multifactor Authentication > Getting Started > Additional cloud based multifactor authentication settings
- Azure Active Directory > Password reset > Authentication methods
You should also document your new Authentication Methods policy settings should you (or Microsoft) have made any changes here. For example, come Jan 2023 Microsoft will enable Number Matching for Microsoft Authenticator and this will (probably) require that the Microsoft Authenticator Authentication Method is enabled, as if defaults to disabled.
An example of what you might document is the following (from the pictures above):
Legacy
- Calling disabled
- All other methods enabled
Legacy SSPR
- Mobile app notification and office phone disabled
- Mobile phone (SMS only) – again because the above is a trial tenant and calling is disabled
- 1 method required to reset password
- Assigned to all users (from the Properties tab)
- Never require users to re-register (from the Registration tab)
External Identities > All Identity Providers > Email One-Time passcode:
- Yes (Email one-time passcode for guests is enabled)
New methods:
- FIDO2 enabled
- Microsoft Authenticator enabled + number match + location displayed
- All other options disabled (off)
Each of the first three areas above will be represented in the new Authentication Methods and you can easily move between “Migrating” and “Migrated” and back again without impact. To migrate you need to turn off the legacy settings, but you can “un-migrate” and turn them back on if you need to. Changes take less than 15 minutes to appear as live in the tenant, especially if you use an in-private/incognito browser session to test.
The below “Manage Migration” panel is found on the Authentication Methods page in the Azure AD portal (Azure Active Directory > Security > Authentication Methods)
Migration
Once your documentation is completed you are ready to move the migration option to “Migration In Progress”. This setting honours legacy policies and Authentication Method policies for authentication (MFA) and password reset (SSPR). Therefore, there is no change to user experience by enabling this setting.
You can now match the legacy policies to the Authentication Methods policy. Turn on Authentication Methods policy to match the legacy settings. Again, as both settings apply to the user, any negative change (i.e. turning a setting off or limiting it to a group) to the Authentication Methods policy does not impact the user.
When an MFA legacy setting matches a legacy SSPR setting (for all users) then it is easy to just turn the setting on in Authentication Methods policy to match – we will look at fine tuning the settings once we have migrated later on in this blog post.
Where SSPR and legacy MFA settings are different (apart from the “Email method” as that is SSPR only) you need to decide which to keep, as the new policy for Authentication Methods will apply the policy to both MFA and SSPR. For example, if you currently allow SMS for SSPR but not MFA, do you enable it in the Authentication Methods policy or not? If you have SSPR enabled for a group of users then you can add an Authentication Methods policy for just that group, but this ignores the fact that MFA methods are for the whole tenant and by enabling a method because it was used for SSPR it is now also available for MFA – so this can be a somewhat difficult decision though you do not need to match what you had before!
If you need help deciding what to turn off, then look at the Authentication Methods > Activity pane in Azure AD Portal. This report shows Registration and Usage information, and for your assistance you need to look at the Registration details. For example, Hardware OATH is not ready for migration at the time of writing, so is anyone using Hardware OATH? – search the Registration Activity report and filter by this method (as shown):
In the above filtered report, I can see one user “Monica Bing” who has registered Hardware OATH, but that it is not the users’ default, or primary, method (relevant filters and results outlined in red boxes). Therefore, in this tenant, I am safe to disable Hardware OATH as an MFA Method in the new Authentication Methods policy (not present at time of writing) and also disable the matching Legacy MFA method (called “Verification code from mobile app or hardware token” – note this policy controls more than just the Hardware OATH method though).
Once you have matched all your Authentication Methods you are ready to complete the migration.
But before that, what are all these Authentication Methods and what do I need to do.
For those methods that are not represented in the legacy portals (FIDO2, Temporary Access Pass and Certificate-based Authentication) you need to do nothing regards migration. Enable these as you need to (that is, enable them – they are useful)!
For the other methods, where before there were four MFA methods this has been split into multiple new methods, and this breakdown is as follows:
- Call to phone
- Voice Call – Mobile (cannot be disabled is this method is enabled)
- Voice Call – Office (can be disabled when the method is enabled)
- Text message to phone
- SMS (with “Use for sign-in” disabled, unless you want to allow those users to register their phone number to sign-in with instead of username, aka front-line worker scenario)
- Notification through mobile app
- Microsoft Authenticator
- Verification code from mobile app or hardware token
- Microsoft Authenticator – Allow use of Microsoft Authenticator OTP
- Third-party software OATH tokens – for non-Microsoft Authenticator OATH apps (i.e. Google Authenticator)
- Hardware OATH tokens (not available at time of writing)
- Email (SSPR method and one-time passcode for guest users)
- Email OTP – Enable for SSPR only, will not work for as an MFA method for internal users
- Email OTP/Configure – Enable for MFA for external guest accounts only.
For each method enable those previously enabled, taking care to match the OATH methods, as there are now four (three at the time of writing) that need enabling or not and if you want to enable them for groups or for everyone.
Check out the additional configuration options if they exist, for example “Office Phone” under voice, or Number Matching under Microsoft Authenticator.
As you are still in a point where legacy methods combine with Authentication Methods there is no user impact – at least not yet. Now it is time to move to Migrated.
Migrated
Before you can move the migration status to Migrated you need to disable the legacy methods you have enabled. So disable them one at a time and check that you get the expected response. Its best to check this via a user account where you have manually registered all possible methods in advance (including ones you might want to turn off, so for example register Google Authenticator as a 3rd party method whilst the legacy OATH option is still enabled (as well as Microsoft Authenticator push and OTP as well).
This testing should include all currently registered methods in use by your organization. You can add as many methods as you need via https://aka.ms/mfasetup.
If you are using Self-Service Password Reset and Security Questions, and plan to keep them, then also register that method and complete those answers:
Now before you can complete the migration you need to turn off the legacy methods. Switch off one at a time, keeping in mind that the setting might be duplicated across legacy MFA and SSPR, or that the setting might turn off more than one method.
For example, to turn of SMS you need to disable “Mobile Phone” in the SSPR settings and “Text message to phone” in the legacy MFA methods page:
You need to disable the following options to test the impact of having only the Authentication Method policy enabled:
- Microsoft Authenticator (Push):
- SSPR “Mobile app notification
- MFA “Notification through mobile app”
- Microsoft Authenticator (OATH):
- SSPR “Mobile app code”
- MFA “Verification code from mobile app or hardware token”
- SMS:
- SSPR “Mobile Phone”
- MFA: “Text message to phone”
- Third party software OATH token
- SSPR “Mobile app code”
- MFA “Verification code from mobile app or hardware token”
- Voice call
- SSPR “Mobile Phone”
- SSPR “Office Phone”
- MFA “Call to phone”
- Email OTP
- SSPR “Email”
Once you have switched off the correct options to test a single Authentication Method, so that the legacy settings are also not impacting your login or password reset perform a login via an in-private browser. Also register new Authentication Methods via https://aka.ms/mfasetup and see what options are available for registration.
The following screenshots show various Authentication Methods enabled and disabled as described in both registration and MFA during sign-in:
Note that the messaging regarding the OATH code reads “Microsoft Authenticator app” when in reality any OATH app will do (as long as the policy allows it). The OATH restriction for third-parties is enforced during registration as shown above.
Password reset is different, as this only limits the options you have during registration and not during actual password reset. So your test user from above (with everything registered) will probably look like this:
But for a more standard user who has registered less methods, it might look like this:
This also means that you can safely turn off methods users have registered in the past for password reset and not cause them to fail to reset their password in the future, but for new users or users updating their methods, they can only register the methods you are currently allowing via Authentication Methods policy.
Once you have tested and have turned off all the legacy methods (as shown), you can change the migration state to “Migrated”:
Once you have “Migrated” the SSPR and MFA legacy options are grayed out and cannot be selected anymore, but if you need to reverse your changes you can do so, though Microsoft will ask you for feedback as to why you are doing this:
As noted on Twitter, changing the number of methods required to do a password reset gets in a bit of a twist following the move to “Migrated”. Once you have migrated maybe only one SSPR method is available (security questions) and if you set the required number of methods to 2 it fails. Returning to “Migration In Progress” and filling in the above fields allows you to change the number of methods and then when you change back to “Migrated” you can still change the number of methods for SSPR – well, you can for a few minutes, and then it stops working again – it is a preview release after all! So for your SSPR number of required methods, set this before you finalize the migration.
All done – in reality it took longer to write about than to do, and a total time to check the reports, change and test is probably 4 to 8 hours of work.
Now its time to improve the methods availability via Conditional Access and Authentication Strengths, but that will be another blog post later.
Photo by Digital Buggu from Pexels: https://www.pexels.com/photo/colorful-toothed-wheels-171198/
Leave a Reply