Combined MFA and password reset registration is now generally available
Published Apr 16 2020 09:00 AM 70.2K Views

Howdy folks,

 

Today we’re announcing that the combined security information registration is now generally available. This new experience makes it easy for users to register for Multi-Factor Authentication (MFA) and Self-Service Password Reset (SSPR) in a simple step-by-step process. Your feedback from the private and public previews has been awesome, and we’ve used it to make this experience even better for end users.

 

Robyn Hicock, who managed this feature, wrote a guest blog post where she dives into the details on this update. You’ll find her blog post below.

 

As always, we’d love to hear any feedback or suggestions you may have. Please let us know what you think in the comments below or on the Azure AD feedback forum.

 

Best regards,

Alex Simons (@Alex_A_Simons)

Corporate VP of Program Management

Microsoft Identity Division

 

------------------------------------------------

 

Hi everyone,

 

As organizations are asking employees to work from home to slow the spread of COVID-19, it’s even more important that users are registered for MFA and SSPR. We want to make it easier for remote workers to keep their accounts secure.


One of the most common pieces of feedback we received was that the registration experience needs to be super easy on mobile devices. Now, when users register while signing in on their phone, they’ll see this easy step-by-step experience:

 

mobile1.PNG mobile2.PNG
mobile3.PNG mobile4.PNG
mobile5.PNG

 

mobile6.PNG

 

We simplified the web experience too! Here’s what that looks like:

 

web1.PNG

 

web2.PNG

 

Once a user completes registration, they’ll see an overview of what they registered to confirm the information is correct and then they’re back to work!

 

web3.PNG

 

To learn more about the enhanced security info registration experience, check out our admin documentation and user documentation.

 

Managing Security Info

 

From the Security info page, users can easily change their default authentication method or update security info such as their phone number. From here they can also add, delete, or change a method.

 

securityinfo1.png

 

Here’s a quick video about how to manage your security information:

 

 

From this page users can also add a security key:

securityinfo2.png

 

securityinfo3.png

 

To learn more about security keys, check out our previous blog about Azure AD support for FIDO2-based passwordless sign-in.

 

Conditional Access for Registration

 

As part of this update, we’re making Conditional Access for the combined MFA and password reset registration experience generally available too! This helps ensure it’s the right user—not an attacker—registering this sensitive info. To learn more, check out our previous blog about Conditional Access for the combined MFA and SSPR registration experience.

 

CA for registering.png

 

Try It Out!

 

Even though MFA/SSPR Combined Registration is now generally available, we aren’t automatically switching everyone over to the new user experience. We want to give you the control over when you update your end user experiences. This gives you more time to test it out, update training materials, and notify your end users. To enable the enhanced security info registration experience, follow these steps:

  • Sign into the Azure portal as a global administrator or user administrator.
  • Browse to Azure Active Directory > User settings > Manage settings for access panel preview features.
  • Under Users you can use the preview features for registering and managing security info – enhanced, you can choose to enable for a Selected group of users or for All users.

opt in.PNG

 

If you're still using the old experiences for registering for MFA and SSPR, start making plans to move to this awesome new experience. We’d love to hear your feedback and suggestions. Please let us know what you think in the comments below or on the Azure AD feedback forum.

Thanks!

 

Robyn Hicock (@RobynHicock)

Senior Program Manager

Microsoft Identity Security and Protection Team

81 Comments

Yay on that and even more so for the CA bit :)

Brass Contributor

Awesome news! I have really been looking forward to this. I for one welcome our new FIDO2-key overlords. :grinning_face:

Iron Contributor

Great!  No more convincing whether to use legacy or preview :).  Any guidance around MFA registration for contractors/external users?  You can't really rely on the User Action of internal IP only.  Same goes for Covid-19 remote users without VPN or RDS.    

Copper Contributor

This is really difficult to roll out to mobile first time users.  We are trying to roll out an app to our frontline workers for this COVID-19 stuff and I had to remove the mobile app option for password reset because it was almost impossible to setup the authenticator app from a mobile device (easy to do it from a laptop).   We rolled out usernames and passwords to this user community, asked them to log into the app, forced them to change the password on first login and then forced them to setup SSPR.    Can this be simplified somehow for setting up the App from a mobile device? 

Microsoft

@JoeGasowski - We actually just fixed a problem for that this week :) It was one of the GA blocking bugs. On mobile devices there should be a link to "Pair your account to the app". Could you DM me with details if that's not working for you?

robynhicock_0-1587063439023.png

 

Copper Contributor

This is a good start, like Joe Gasowski the amount of time our help desk spends is to still too high. The video will help greatly. This only goes halfway in the MFA SSPR user journey.
Next, we need a 'simple' way for the end-user to reset or 'Re-register MFA' on their own. And if possible a Powershell command to do the Require re-register MFA.  This is typically needed for when the end-user purchases a new cell phone and now they need to get Microsoft Authenticator App setup again as they no longer have the QR code or old phone and MFA simply stops working.
Thanks, Rusty

Brass Contributor

@Rusty Brown i'd say that's intentional - allowing anyone to register for MFA by just clicking the link after signing in, isn't really secure, is it?

i mean.. i've been struggling with this as well, but then I realized, it would actually allow anyone in the world to register any android device just with a username and password, which MFA is actually supposed to prevent, as I understand the whole thing.

so currently, we're doing Conditional Access exception for Intune registration at our premises, which is the place where new users register for MFA most of the time anyway. this allows to configure MFA for pretty much all scenarios, EXCEPT when the newcomer isn't able to arrive at the office for onboarding session at all.

 

but perhaps @robynhicock can enlighten us and tell us how is the first-time user supposed to securely enroll in MFA using their android enterprise fully managed device, while MFA is required for device enrollment..

Copper Contributor

Hey,

 

How about the loop in registration if you use adfs and mfa if outside access already needs second factor. Will it be possible to allow register azure mfa without 2. factor?

 

cheers, Daniel

Microsoft

@Vasil Michev - Yes! We're excited about the CA part too. Just fyi the "Preview" tag on that will be removed tonight :smile:

 

@TomAafloen - Woooot! Security keys! :hearteyes:

 

@Chris_Clark_Netrix - Yay! Yea haha that was a hard choice before between the old version or the preview version :lol: This should work for Guest Users too and you can apply a Conditional Access policy to protect registration. Feel free to DM me if you run into any issues.

 

@Rusty Brown - Good point. The re-register MFA idea is in our backlog. We do currently have a security info freshness interrupt that checks "Is this info up to date?" but it only works for SSPR. In the meantime you'll have to send them to https://mysignins.microsoft.com/security-info to manage their info.

 

@jurajt - Yep that seems like the right way to do it: using Conditional Access to protect Registration. How are you dealing with remote workers though? Since they can't go to the office for onboarding during this COVID-19 situation. 

 

@DanielMisch - I think our dev team worked on a fix for this kind of loop. I'll check and get back to you. 

Brass Contributor

@robynhicock thx for the response. we don't have remote workers, and I was actually hoping *you* to tell us how's that supposed to work. the only one I see is to send pre-provisioned HW token (which isn't available yet), so i'd really like to know what's microsoft's take on this :)

 

especially with "the CA bit", i'm wondering what's the scenario for it.

Brass Contributor

@robynhicock We're always telling people 'never click on links'. However to setup MFA we need them to click on https://mysignins.microsoft.com/security-info
Any chance this can be added to Office | My Account | Security & privacy?

The admin documentation states that you can reach the page "by selecting Security info from My Profile". However in our tenant, this is not available.

When raised in March 2019, the response was that they were "waiting for the myprofile product to come out of preview and once its fully GA" it would be available.

 

Do you know if this should work / how to enable it?

myaccount.png

Copper Contributor

@robynhicock There is confusion on how the conditional access setting interacts with the SSPR Registration settings. If I turn SSPR registration off, does that affect the conditional access user action "register security information"?

 

Also, there has always been the issue of including all users in SSPR registration but no ability to exclude service accounts from registration in the SSPR registration settings, so we've had to script the membership of a group to target for registration. Question: Does this conditional access user action now allow us to stop using SSPR registration and use conditional access policies with group exclusions?

Brass Contributor

@PeterHoldridge isn't it possible to set SSPR registration for a selected group, and put all real users in there without service accounts..?

Copper Contributor

@jurajt I wonder if you read what I wrote here: "so we've had to script the membership of a group to target for registration." This is not the desired behavior we want. We would like conditional access to be the new way to register for SSPR and using the built in "exclude" function.

Copper Contributor

@robynhicock We are working on a new video here are our is our idea, still, your video production is more professional.

Title:  So you got a new cell phone and want to set up your office email
  1. on your office computer go to https://mysignins.microsoft.com/security-info
  2. log in with your office work email account and password
  3. Delete Microsoft Authenticator
  4. Click on Add method
  5. Add method - Microsoft Authenticator
  6. follow the setup steps to scan the QR code
  7. Now that you have the Authenticator app installed your next step is to download and install Outlook App
  8. Open Outlook App and follow the setup steps
Copper Contributor

Is it possible to make registration wizard require 3 methods to register when signing in?

Brass Contributor

So we should be sending end users to https://mysignins.microsoft.com/security-info now for MFA registration?  Can we still use https://aka.ms/mfasetup ?  I prefer the 2nd one because it's more focus and streamlined for the user.  The first one seems less "directed"?  I have to tell the user to keep hitting "Add Method" button to setup additional methods, where-as the wizard in the aka.ms/mfasetup took care of that already.  

 

Even the end-user registration screenshots at the top of this article look like the aka.ms/mfasetup screens (more wizard-based), than what I'm seeing at the mysignins.microsoft.com/security-info page so that's more confusing.  

 

Any clarification on those two different MFA registratoin URL's would be appreciated!

 

Thanks!

Jason

Iron Contributor

@Jason Hartman I actually just tested   aka.ms/mfasetup and aka.ms/setupsecurityinfo .             aka.ms/mfasetup definitely seems like a better end user experience as It tells you that your admin requires more info and then steps the user through adding their MFA methods.  It also defaults to Authenticator as the primary method.  We have been pointing clients to aka.ms/mfasetup, but i could see in certain instances it would be easier to go right to security info.  

Copper Contributor

I might be reading things incorrectly but this is all geared toward the "Interrupt mode"MFA/SSPR registration process. 

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-registration-mfa-sspr...

 

I am thinking for users who need a one-time reset or can't come to a "trusted" location you could rely on the "Manage mode" which basically means you are pre-populating something for them to use out of the gate like Phone or Alternate email. This would allow them to re-register and IT would have a higher degree of confidence it is the desired user doing the re-register process.

Copper Contributor

Nice but useless for our users that cannot use either the app or a phone for their second factor. We want to use FIDO2 keys but the system does not recognise it as a valid second factor on it's own right i.e. their MFA status remains disabled if it's the only device registered. Add a phone and when they log in there's only the option to get a call or text, neither of which is secure.

Microsoft

@jurajt - We do have something in the works to address this scenario actually, to help first-time users enroll in MFA. It's too early to announce it here though but stay tuned for Public Previews :smile:

 

@Anthony Cotton - Yes good point about links. My Account did actually go to GA in February though. The link is: https://myaccount.microsoft.com/
The Office portal does link to the security info page, highlighted here:

 

1.png

Microsoft

@PeterHoldridge - Hmm. I'll have to check with our dev team and get back to you. 

 

@Rusty Brown - Nice! I'll bring up this scenario with our content team and see if they could create a new video for this. 

Microsoft

@VladV - Yep you can :smile: It depends on your MFA and/or SSPR policy. Here's an example of registering 3 things:

 

2.PNG

 

Microsoft

@Jason Hartman and @Chris_Clark_Netrix  Yep you can still use https://aka.ms/mfasetup. That's the shorter link that will take them to the Security Info management page anyway. However if you have an SSPR or MFA or CA policy set up, they'll hit that "wizard mode" when signing in. Agreed the wizard is more streamlined since it walks users through setup 1 step at a time :smile: There's more info in our docs here about the 2 types of modes: https://aka.ms/securityinfodocs

 

@ryanfog - Yes exactly :happyface: Interrupt mode and Manage mode are different.

 

@FernandoV_RTX - We hear you. We're working on shipping all the Passwordless scenarios to enable FIDO2 keys in more places. 

Microsoft

@PeterHoldridge - I asked our Engineering team and they said:

There is confusion on how the conditional access setting interacts with the SSPR Registration settings. If I turn SSPR registration off, does that affect the conditional access user action "register security information"?

  • You can turn off SSPR registration and Conditional Access would still apply if users try to register security information.

Also, there has always been the issue of including all users in SSPR registration but no ability to exclude service accounts from registration in the SSPR registration settings, so we've had to script the membership of a group to target for registration. Question: Does this conditional access user action now allow us to stop using SSPR registration and use conditional access policies with group exclusions?

  • Unfortunately no. SSPR scoping is independent of a CA policy.
Microsoft

@DanielMisch - I checked with our Engineering team and they aren't sure if they understand the question. Could you give us more details on the scenario? With respect to ADFS – If we are referring to on-prem MFA users trying to register for Azure cloud MFA we still have a problem there where we have a loop that happens.

Brass Contributor

Hi Robynhicock,

 

Thanks for great work.

I have a question regarding one specific scenario that I feel don't work.

My users are working remote and are using Outlook App on their mobile device(iOS). They don't have access to a computer.

The company suddenly decides to requiere Azure MFA for access to email.

When the users next time get prompted to Sign-in in the Outlook App on the mobile device(iOS) they also get prompted to register for more security info. The user follows the instructions and end up on a page in the Authenticator App where they have to copy a code and a URL to complete the registration. According to the instructions that are presented to the user, they should use the code and URL when adding a work/shool Account in the Authenticator App. Why is the option to Pair your App to the device link missing?  The link is not missing when using the same device to browse to Outlook on the Web.

 

 

Brass Contributor

I have 65+ account in my Microsoft Authenticator, when can we have a search bar?

Brass Contributor

Finally! good work.

Brass Contributor

great information, especially in the comments. Keep up the good work!

Copper Contributor

@robynhicock Any suggestion how my policy should be structured? I tried modifying my SSPR but still get only 2 methods to register.

Brass Contributor

Great news, look forward to FIDO2 stuff getting full support for MFA and windows logins for hybrid devices.

 

Same concern around sending a link users need to click on. @robynhicock you mentioned: "The Office portal does link to the security info page, highlighted here:"

 

For us we typically tell our users to go to our intranet site which is a sharepoint online page, if I click on my face in top right, then "View Account" it goes to https://portal.office.com/account/?ref=MeControl which doesn't have a link to update security info (it did at some point in the past). I'm in a group which is allowed the new SSPR+MFA experience.

Annotation 2020-04-20 132338.png

 

Microsoft

@KeepingITreal  - Wow that's a lot of accounts! I'll forward your feedback to the PM's that own the Microsoft Authenticator.

 

@Mikael Cavrak - Great question. The "Pair your account" link only shows up if you're in a mobile browser. If you're signing into an app, that link was causing errors so we had to replace it with the copy/paste instructions. In the future, we do want to improve that scenario when signing into an app so it's easier.

 

@VladV - Sure. Which 3 methods are you trying to get them to register? And are you only doing an SSPR policy, or also MFA or CA too?

Microsoft

@freds123 - Hmm it might depend on some security settings in Office. I noticed that Office Portal page has different links depending on the tenant I test with. I'll ping someone to find out.

Copper Contributor

@robynhicock Thank you for helping. I'm doing MFA/SSPR and Conditional Access. I want users to register Mobile app, mobile phone, and security questions.

Copper Contributor

I have discovered the real use of this feature is to mainly prevent users from registering until they satisfy conditional access. It doesn't force registration only, it also limits you to a condition in order to register. Therefore it doesn't work well if you have guest users that need to register for MFA. It really was designed to use a block access control and limit the registration to a location IP and/or company device. 

 

This solution won't work for us since we have a diverse population and set of conditions and all types of users need to register. We don't want to limit their registration with a block access control. We do need them to register though. We have had to hack a solution together since we don't have P2 licenses.

 

Now that we know the facts, we know that we won't be implementing this solution. Also, before anyone replies, yes we know that you can require registration through Identity Protection, but this requires a P2 license. We also know, there is an "Enable Security defaults" but this doesn't serve our needs since it is too simplistic.

Brass Contributor

Hi Peter

We ended up in a previous lifetime rolling out MFA through a series of powershell scripts, as the enrolment process, left to the wizards and end-users, was encountering adoption issues.

We're working to update that framework and approach to incorporate the combined MFA/SSPR feature.

In a nutshell, using CA policies, m365 groups and scripts should provide much better control and visibility on adoption.

Copper Contributor

Hi,

I have a couple of questions regarding Registration Enforcement in the combined mode, based on information on this page https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-registration-mfa-sspr...

  1.  After you enabled combined registration, users need to register or confirm their phone number or mobile app through the new experience to use them for both MFA and SSPR. Is it so that the already registered methods in MFA or SSPR will not work for both if they do not re-register or re-confirm their authentication methods through the new experience?
  2. If we enforce registration through SSPR settings, is it correct that the registered authentication methods will only be valid for SSPR and not MFA?
  3. We want to take advantage of the SSPR feature to have users re-confirm their authentication methods after X number of days, but if we have enforce registration through MFA's identity protection settings or Conditional Access, then does that mean we cannot utilize the SSPR re-confirmation feature for both?

Thanks.

Steel Contributor

Awesome work! I’ve been in the preview since day 1 and deployed thousands of users using the new experience. All-in-all it works well even though there might some edge cases causing problems (which we have hard time identifying since we just get the report ”it doesn’t work”).


@Alex Simons (AZURE) 

Anyway, question: what is the idea/plans for the old portal.azure.com > Azure Active Directort > Users > Multi-factor authentication. This creates confusion amongst our customers. First it looks like some leftover from MFA before we had Conditional Access. Also, some settings simply does not exist anywhere else (like selecting which methods are available and mumber of days to remember device).

 

Is there a plan to move these settings somewhere or such? Since some of the settings are still required for non-Azure AD Premium customers.

Hi @Jona33 -  The team is working on cleaning up all the various authentication methods and bringing them into one experience. You'll see more progress here this summer and another wave in the fall as we work to consolidate all our various auth methods into one management experience.

 

Regards,

Alex

Brass Contributor

@robynhicock, have you been able to find out how to change the Office portal to link to the security info page that freds123  & I mentioned?

Thanks

Microsoft

@VladV - To follow up on your question about getting "users to register mobile app, mobile phone, and security questions":

 

Three methods would only show up if the user has both MFA and SSPR enabled and if one of the following is true:
1. If the methods in SSPR and MFA settings don’t overlap + 2 methods required for SSPR
2. Two methods are required for SSPR and the user’s MFA state is *enforced* (this will show the app password option)

So you can set the following:
MFA settings – only app code and notification allowed + require MFA registration for the user
SSPR settings – 2 gates required + app code and notification are disabled

 

Hope that helps! :smile: Let me know how it goes.

Microsoft

@Anthony Cotton  and @freds123 - Yep. I asked around and the good news is that we are actively working on integrating the Office account portal with the new AAD My Account site. :smile: We’re in the process of transitioning some features unique to the Office account portal to My Account and it’ll likely be a couple more quarters until Office can fully deprecate their experience. That being said, we’ll have completed enough of the integration some time this June to be able to update the ‘View account’ link in Office sites to My Account.

Microsoft

@PeterHoldridge - Sorry to hear that. I'll forward your feedback to the PM's that own Conditional Access and Identity Protection. I'm interested in the "hack solution" you mentioned since you don't have P2 licenses. Feel free to DM me if you want to chat more.

Microsoft

@DTunes - Great questions! I just need to double check something with our devs and I'll get back to you on that.

Microsoft

@Jonas Back - Thanks! Glad you like it  :smile: If you're still having issues with some edge cases feel free to DM me and I can help troubleshoot.

Copper Contributor

Can a security key be used as an SSPR factor? I'm not seeing it in the portal for Password reset | Authentication methods although I do have it enabled and working for sign on. Maybe I missed enabling something. Thanks!

Microsoft

@DTunes - To answer your questions:

  1. Previously registered MFA methods from the old MFA page will work for both MFA and SSPR (provided that the MFA method is also allowed by the SSPR policy). This is because the password reset flow only uses the data. However, previously registered SSPR methods from the old SSPR page will not work for MFA (even if the SSPR methods is allowed by the MFA policy). This is because MFA relies on data + strong auth methods and the SSPR registration page does not set strong auth methods.
  2. Nope. Methods registered from converged registration can be used for both MFA and SSPR provided that those methods are enabled in the corresponding MFA or SSPR policy.
  3. The re-confirm feature triggers an SSPR interrupt. We only pull the user’s registered SSPR security info on any SSPR interrupt (first time or rec-confirm). So, if they were to use this configuration, the user might not see all their previously registered security info when the reconfirm interrupt kicks in.
Microsoft

@jenfield - Security keys can only be used for MFA for now. It's in our plan to let them be used in SSPR though.

Copper Contributor

@robynhicock thanks!  

Version history
Last update:
‎Jul 24 2020 01:12 AM
Updated by: