This article will look at the various different MFA settings found in Azure AD (which controls MFA for Office 365 and other SaaS services) and how those decisions impact users.
There is lots on the internet on enabling MFA, and lots on what that looks like for the user – but nothing I could see that directly laid out all the options and the impact of each option.
The options that the admin can set that I will cover in this article are:
- Default settings for the MFA registration service
- The enhanced registration service (now depreciated)
- The refreshed enhanced registration service (MFA and Self-Service Password Reset registration combined)
The general impact to the user is that the user needs to provide a second factor to login. In this article I will not detail the above registration for each of the second factors and only cover the general process of registration – your exact experience on registration will depend upon what second factors (app notifications, app code, phone call and text message) you choose to implement.
This article will look mainly at the different between having no MFA and what happens from the users perspective as the admin turns on a requirement to have MFA. The various options that the admin can use to enable MFA are as follows:
- Office 365 MFA (aka the legacy method) that is available to all users with or without a licence
- Azure AD Conditional Access and setting a rule that requires MFA (when the user is not registered)
- Azure AD Premium 2 licence and MFA Registration (register without requiring MFA to be enabled)
- Azure AD Free fixed Conditional Access rules (MFA for all users) which is in preview at the time of writing (Aug 2019)
Terminology and Settings
This article refers back to a series of different settings in each of the following sections. To make the article avoid repeating itself, this section outlines each of the general settings, what I mean by the description I use and where I turn that setting on or off.
Office 365 MFA – This is the legacy MFA options set via https://admin.microsoft.com > User Management > Multi-Factor Authentication. This user experience turns on or off MFA for users regardless of app or location (unlike Conditional Access) and has settings for the different second factor methods (for example you can disable SMS from here).
Conditional Access Based MFA – This is where you set rules for accessing cloud apps based on the user, the location, the risk (P2 licence required), the device (domain joined or compliant), the location (IP), the device risk (MDATP licence required), compliance (Intune required) etc. If you rule requires MFA and the logging in user passes the requirements for this rule (and is not otherwise blocked) then this is what I call Conditional Access Based MFA. This is set in https://portal.azure.com > Azure Active Directory > Enterprise Applications > Conditional Access
Azure AD Premium 2 MFA Registration – This is where you can get users to register before you turn on MFA via either of the above routes. Without the P2 licence you turn on MFA and at the next login the user needs to register. With P2 you can turn on registration at login without forcing MFA. You would then enable MFA later or you can have registration at next login (and defer that by 14 days) so that the user registers even if they never hit an endpoint that the need to do MFA on. For example, MFA when external and the user never works remotely. Therefore they will never have to do MFA and therefore never be required to register – which P2 licence you can get them to register independent of the requirement to do MFA. You access these settings via https://portal.azure.com > Azure AD Identity Protection > MFA Registration
Self Service Password Reset Registration – This is shown if the user is in scope for SSPR and SSPR is enabled. This is not MFA registration – but if the user is in scope they will be asked to register for this as well. This therefore can result in two registrations at next login – one for SSPR and one for MFA. We will show this below, but it is best if you move to the combined MFA/SSPR registration wizard mentioned below.
Enhanced Registration (Depreciated) – This was the new registration wizard in 2018 and have been replaced by the next option. If you still have users on this option you will see it, otherwise the option to enable this older wizard is now removed. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview
Combined MFA and SSPR Registration – This is the current recommended MFA registration process and it includes self-service password reset registration as well. You should aim to move your settings to this. All the new MFA reporting and insights are based on this process. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview. Note that if you still have users on the previous “Enhanced Registration” shown above then this one is listed as “enhanced”. If not – if only one slider is shown – it is the new registration process. You can enable this for a group of users (for pilot) or all users:
Office 365 MFA + Original Registration
This is not recommended to be used any more – use the Azure AD Free Conditional Access rules for all users or all admins instead. But for completion of the process to show all the options, you select a user(s) in the Office 365 MFA page and click Enable. In the below screenshot we can see that Cameron White is enabled for MFA. This means that it has been turned on for him, but he has not yet gone through the registration wizard:
The video below shows the first run experience of this user – they login and are prompted to register for MFA. They register using the legacy experience and are then granted access to the application.
Office 365 MFA + Enhanced Registration
For this scenario I have a user called Brian Johnson. He has been enabled for MFA as above (Office 365 method) but additionally has been added to a group that is configured to support the new MFA+SSPR combined registration process. Brian is not enabled for SSPR. The video shows the user experience. Note that the user needs a valid licence to be able to use this experience. If they do not have any licences they will get the old experience:
Conditional Access MFA
The following video looks at the experience of two users who are enforced for MFA via Conditional Access. The login will trigger the registration for MFA as neither user is already registered. The first user (Christie) gets the old registration wizard and the second (Debra) gets the new registration wizard. The Conditional Access settings are basic – MFA in all circumstances for our two users:
Impact of SSPR on MFA Registration and User Sign-In
When users are set up to register their password reset security methods and MFA, but using the old registration wizard the user needs to do two sets of registration. Again, it is recommended that the combined registration process is used instead of this process.
For this demostration, we are enabling SSPR for our test users. One with the old registration wizard and one with the new one:
Adding SSPR To Already Registered Users
Once a user has registered for MFA (old or new registration) it might come a time where you enable SSPR for them after that (and not at the time of original registration). In this scenario the users that registered with the old registration wizard are asked to register for SSPR, but users who went through the new wizard – though they did not specifically register for SSPR – there is enough details already available for them to use the service (as long as app notifications and codes is enabled for SSPR). If SSPR is left on the default of SMS and Email, then the new registration wizard does not have your alternative email and so SSPR is unavailable to you. The user process and flow is shown in the next video:
Azure AD Identity Protection and MFA Registration
The Azure AD Premium 2 licensed feature called Identity Protection contains the ability to request that the user registers for MFA (and SSPR if via the new combined registration wizard) even if the user is not required to perform MFA for login – all our previous registrations only required registration because the user needed to do MFA. You can ask users to pre-register via https://aka.ms/mfasetup but Identity Protection adds this functionality with a 14 day option to defer. The video shows the settings and the user experience:
Azure AD Free Conditional Access for All Users
Early Q2 2019 Microsoft rolled out new baseline policies for Azure AD Conditional Access. These are available even without the Azure AD P1 licence needed for Conditional Access – but as they are licence free they are heavily restricted – they apply to all users and need MFA if sign-in is risky. So though they do not require MFA on all logins (unlike the O365 MFA legacy settings) they do require registration. But they offer a 14 day deferral process if the user is not ready to register. But unlike Azure AD Identity Protection mentioned above, you cannot do this for some users – it is enabled for all users upon enabling the rule. Lets see the settings and the user experience in the video. The video will also enable the “all admins” baseline policy as well, as that should always be turned on.
What happens of we not enable mfa for userX and direct userX to aka.ms/mfasetup and he registers himself. Will userX then be required for mfa?
Second question, if we not enable mfa for userY and direct userY to aka.ms/mfasetup and he registers himself and we use AAD CA mfa and only require mfa for Exchange will he be required to do mfa for sharepoint ?
Teams and Exchange or Teams and SharePoint need to have matching rules. It tells you this when you create a Conditional Access rule now
If a user registers themselves via the URL or the AADP2 Identity Protection MFA Registration feature then they are not required to use MFA until they hit a Conditional Access rule requiring it, or they change their password or they go back to the registration page – you need MFA to get to the registration page if you have already registered.
Thanks a lot Brian for your testing and answers. This blog post makes everything so clear cause the documentation on the internet is poor or scattered around eveywhere or even outdated. The video’s are a great asset to this post. PS there is also the possibility to set the MFA registration via PowerShell for the users so they dont have to register themselves. But not really in scope for this post 🙂 PS2. If we used the new enhanced mfa/SSPR option and we redirect user to aka.ms/mfasetup will the user get the new experience? (AAD P2 costs money so any way to avoid this could help smaller organizations).
Registration wizard and license are unrelated. You will get the wizard if enabled for it even if P1 license
First of all, excellent explanation. In my case, we have enforced MFA using the old wizard and users have verified their mobile, office phone and microsoft authenticator.
We are now planning to enable SSPR but don’t want users to verify their details again, how to do that ?
If we enable combined registration and then enable SSPR, will it still ask users to verify their details again or since they have their details verified for the MFA, SSPR will use those details ?
“don’t want users to verify their details again” – if Azure AD does not have the correct number of registered proofs for the user they will be required to register the additional proofs. So for example, if SSPR requires 2 methods and the user has only registered one, they will need to register a second method. If they have already got two methods (app notification and app code is not counted as two methods) then they do not need to register again. The “Authentication Methods Activity” report (AAD Portal > Usage & Insights) will show you two reports of users and what they have registered – see how many users have less methods registered than the number you require for SSPR.
Thanks Brian, we have set it to 1 method for SSPR and when we enabled the “Combined Registration”, users got the “Success message” and they didn’t have to register again.
Thanks for the explanation – much appreciated.