Cool enhancements to the Azure AD combined MFA and password reset registration experience

[Alex Simons (AZURE)]

Howdy folks!

Today, I am excited to announce a set of fantastic enhancements—based on your feedback—to the public preview of our combined registration experience for Multi-Factor Authentication (MFA) and self-service password reset (SSPR). This new registration experience enables users to register for MFA and SSPR in a single, step-by-step process. When you deploy the preview experience for your organization, users can register in less time and with fewer hassles. In addition, the new My Profile experience provides users with a more streamlined and easier-to-navigate experience for reviewing and updating their profile info.

Keep reading to learn more about these enhancements!

Streamlined registration experience

Since we released the combined registration public preview, we received a lot of great feedback from our customers on how to make this experience even better for their users. One of the most common pieces of feedback we received was that the registration experience needs to be even easier, especially on mobile devices. To address this, we streamlined the experience so that users can simply click through each step to register their security info.

Now when users are required to register while signing in, they’ll see the following experience:

Enhanced step-by-step registration experience.

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!

Overview of the security info setup by the user.

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

New My Profile experience
When you enable the enhanced security info registration experience for your users, they’ll also have the new My Profile experience, now in public preview. My Profile is the central location where users manage their identity including security info, devices, and more.

The new My Profile experience.

From the Security info page, users can easily change their phone number or choose a different default method. From here they can also add, delete, or change a method.

Manage security info.

To learn more about the new My Profile experience, check out our documentation.

Try it out!
To enable the enhanced security info registration experience and the new My Profile experience for your users, 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 – refresh, you can choose to enable for a Selected group of users or for All users.
  
  Enable the enhanced security info registration experience.
  
  

Users who are enabled for the old security info registration experience will continue to see that experience until you enable them for the refreshed experience. This means that if you have enabled the non-refreshed experience, you will have the ability to enable and disable that experience.
If a user is enabled for both the old experience and the enhanced experience, they will see the enhanced experience.

As we move forward, we will continue to make improvements and fixes in the enhanced registration experience. If your users are using the old experience, we recommend moving them to the enhanced experience as soon as possible so that they have access to the latest updates.

Please submit your ideas to our feedback forum and we will review and respond to them. You can also let us know what you think in the comments below. As always, we’d love to hear any feedback or suggestions you have.

Best Regards, 

Alex Simons (@Alex_A_Simons )

Corporate VP of Program Management

Microsoft Identity Division

[mackintoshc2019]

Hello

I used to have these options

The first option was set to All and this gave us the new experience, working up until today

The second option (enhanced) was set to None 

By switching to the new enhanced mode, what has happened is the first option has dissapeared !!!!

i only get option 2

Now with the enhanced option set to ALL or selected group

When new users attempt to enroll a new android mobile device using company portal we end up with the follow message

Now i cant switch back to what we had before so why is this happened?

Why we cant enroll mobile devices using the new enhanced option when it was working on the previous preview option

This is not good enough!

[Sadie Henry]

@Jonas Back I'd definitely like to dig into these issues with you further. Can you send me a DM and we can look into this?

@mackintoshc2019 We are removing the control for the old version of public preview, which is why you no longer see that option. I was unaware of any issues with device enrollment but I'm happy to dig into it. Can you also send me a DM and we can look into this?

[Andrew_Christianson]

Looking for conditional access on MFA registration as well!!

Is there a way to control who is allowed to use which options? GroupA can use Phone or App, GroupB only use App for MFA?

[Sadie Henry]

@Andrew_Christianson No, not yet, but we are working on both of those capabilities. :)

[mackintoshc2019]

@Sadie Henry are you saying that currently the enrollment doesnt work if Conditional Access are in place when the user attempts to log in and register, i have  CA policy in place that requires MFA  when a user attempts to enroll a mobile phone, so if it is first time they will be asked to register for MFA otherwise if they have already regsitered for MFA then they will be asked to provide their second factor.

This was working perfectly on teh OLD Preview settinsg and still works on non preview settings, just nothing in the new preview settings

[mackintoshc2019]

@Sadie Henry 

Hello 

I was doing some additional testing and found that the Enhanced Preview settings do work for enrolment via a Windows 10 device, i get requested to setup MFA via conditional Access Policy and then setup completes ok.

The problem i am seeing appears to be specifically with Android Mobile and Company Portal, i suspect the Company Portal cant handle the new preview settings and i get an unexpected error has occurred.

Can this be verified if this is a known issue at all.

[Sadie Henry]

@mackintoshc2019 could you send me a DM so that we can follow up via email? It would be great to get more details on this. Thanks!

[Eric Kurtz]

The new one is getting better.  A few notes.

1. the direction, it says to enable the "Users who can use the preview features for registering and managing security info – refresh" version, but in my tenant it says "Users can use preview features for registering and managing security info – enhanced"  

2. Security Questions for SSPR are truncated by popup box and you cannot read the entire question. 

3. How do you know what options are for SSPR and which are for MFA? Can you add a column or comment to let the end users know that security questions or email is not available for MFA

[niels haaijer]

We are currently using this new experience to enrol our users.

The feedback we get from our users is that when the have to enter their private/personal e-mail address for example ..@Hotmail.com or …@gmail.com, they enter their work/school e-mail address and this doesn’t work off course.

So please change description to make it more clear for users that they have to enter a personal e-mail address.

[Sadie Henry]

@Eric Kurtz thanks for the feedback!

1. Yes, the title has change slightly. We'll update our documentation. :)
2. Can you private message me a screenshot of the security questions issue?
3. We don't indicate to the users which methods are used for what as we haven't found that user's are looking for that info. Have your users run into issues with this?

Thanks!

[Sadie Henry]

@niels haaijer thanks for the feedback! We'll look into making this clearer for users. 

[Brian Reid]

Hi @Sadie Henry - Recent Activity was on this portal when you released the feature for preview, but it is not there anymore. Can you share something on why this was removed and when you expect it to return please?

Thanks

---

---

[niels haaijer]

@Brian Reid  you can still access the recent activity using this link https://mysignins.microsoft.com/

[Sadie Henry]

@Brian Reid great question! Shoot me a DM and I'd be happy to discuss further. :)

[Henrik_-_CD]

First, I like the trend that things are moving towards Azure AD and look forward to all MFA config to happen there in a consistent manner. Today it is too spread out in different portals. I would like to try this new experience out and have enabled the preview. I then created a Conditional Access Policy in Azure AD that requires MFA for a user. When he logs on, the browser thinks for a few seconds, and then there is just a page with a triangle and a few exclamation marks that says "An unexpected error occured" (or something like that in english, I am Swedish so it says the error in Swedish). @Sadie Henry Something is clearly broken with this new preview MFA experience, is there an ETA on when it will actually work?

[Sadie Henry]

Hi @Henrik_-_CD  - I would love to learn more about the issue you're running into. I'm not aware of any issues that would cause that behavior. Can you send me a direct message and we can dig into the issue?

[HenrikEl]

Removed .. Double post

[HenrikEl]

Removed .. Double post

[HenrikEl]

Hello @Sadie Henry! I have changed to a more permanent persona for this forum. I have been testing this out more and have found this:

If I require a user to re-enroll MFA, the enrollment for this user breaks with an "An unknown error occurred" error. If I wait to the next day however, the enrollment for the user have self-healed and works again!? This is repeatable over days and the error is consistent.

If I go to the security settings for a user after the enrollment (see point 1), it's broken again and shows just the triangle and exclamation marks and "Unknown error" message.

When I configure the MFA methods in the SSPR area, I have to require two methods to even light up the choice to use the app notifications. I am then for some reason forced to choose three methods when requiring only two. Also, I am offered to configure app codes even if this is not chosen in the SSPR methods but is however allowed in the old portal, is this to be expected?

Why are the settings for MFA methods located in the SSPR settings? If the same settings are for both things, they should be consolidated somewhere more logical. "Where do I configure the MFA settings? In the SSPR area whether SSPR is configured or not! Eh ok?". Also, the fact that MFA settings are available in both the old portal and the new without any clear info on the correlation between the two does not exactly help. A more fine-grained setup would also be great, where you can choose different MFA methods and requirements for different users in a broader framework regarding login security for a user.
 
Listen, I get that you are trying to simplify this setup for the users which is great. But as of right now, it does not work. If I was to release this in our live environment it would be disaster with the errors that occur. I would be interested in getting this to work properly, do contact me if you want additional feedback.

[Andy-H]

@Sadie Henry We are also seeing the "unexpected error has occurred" under certain circumstances.

With IE protected mode disabled for trusted sites...

Using Edge or Firefox in private mode, accessing aka.ms/mfasetup and signing in, we are given the "unexpected error has occurred"

Using IE in private mode, isn't really private.  Trying to use an account other than the one signed into Windows, ultimately reverts back to the Windows signed in user.

[HenrikEl]

Indeed there is a problem with this. I hope they will fix it as I truly like the new look of it. :)

[JB_MG]

@Sadie Henry @Jonas Back I am seeing the same experience when scanning a QR code for Authenticator just spins forever and the push never goes through to the end device.

In addition, I think the current flow is a bit illogical.  

When a new user first logs in and goes through the MFA registration, the default method is via TOTP code using the Authenticator app.  In order to configure push notifications, they have to re-register a second time leaving two authenticators in the app which is extremely confusing.  How do you configure it so they register only once with the default method being push?  

[JB_MG]

@Sadie Henry @Jonas Back 

I have seen the same spinning while trying to authenticate using push notification this method when the user is using an Android device.

I also believe there is a workflow issue as well when logging into the account for the first time. Upon initial MFA registration, you are prompted to use "In your app, add an account and select "Other".  This should default to the work or school method so the user can register for push notification immediately upon registration.   Can we modify this?  

[Sadie Henry]

@HenrikEl Thanks for all of your feedback! We are looking into the bugs that you mentioned around clearing MFA and getting an error when you try to access the registration page. We are also working to bring the administrative experience for MFA and SSPR together so that it's easy and clear how to configure methods for a user. This will make things much simpler and clearer. :)

@Andy-H We're also looking into this. This is currently a known issue and we are working to fix it.

@JB_MG You are seeing the flow that happens when only mobile app code is enabled for the user. If you're registering using mobile app code, the account you have to select is "Other".

Thanks, folks!

[Andy-H]

@Sadie HenrySimilar but different to @HenrikEl , if a user deletes all instances of their registered Authenticator apps, and tries to re-enroll, the web pages just loop back and forth.  I had created a case with MS and was told that the web page looping is by design!

As an aside, we really need a way to differentiate the different authenticator apps within a user's profile so they don't delete all or the wrong one.

[Sadie Henry]

@Andy-H I'll look into the looping issue for you. If the user registers Microsoft Authenticator, we will show the device name if we are able to retrieve it, which differentiates the apps. Feel free to shoot me a DM and we can discuss further.

[Deleted]

Hi @Sadie Henry - as we've rolled this out to all our staff, I've had an interesting problem popup that I was able to recreate on a test account - apologies if this has already been reported!

The problem is that if a user chooses to use their Phone as the first method, and then on the second method they want to use email, they must do that there and then. If for whatever reason they don't complete the process (such as it timing out), then when they return to the setup page, "Phone" has moved to being the second method, and the first option doesn't let you choose "I want to set up a different method" anymore:

[Sadie Henry]

@Deleted thanks for notifying me of this! I'd like to understand more about your MFA and SSPR policies to troubleshoot what's going on. Can you send me a DM with the info?

[Brian Reid]

@Sadie Henry just noticed that when I have this UX enabled and I login to a new device as a Azure AD user I get asked to set up a PIN. If I choose to defer this for 14 days it ignores me and I need to complete the new wizard. The PIN UI is square in Windows 10 (1809) but the combined wizard is not square, so it does not fit well on the screen and then at the end of adding a new authenticator and phone number it presents me with the Myapps portal - but I am inside the PIN UI in Windows. I've uploaded a photo so you can see what it looks like below, and then it fails to register the pin if I close that UX with the cross top right (there is no other way out anyway). PIN registration then works if you choose Try Again in the error page, as this time I don't need to register but just enter the authenticator codePIN UI with combination wizard

PIN setup error afterwards

[Brian Reid]

@Sadie Henry - Hi, tried to register a few people into this feature when using an iPad. But in both Safari and Chrome it would not show the QRCode and only the code to enter by hand and the URL, which is quite hard to type by hand. Any idea why iPad's are not showing the QRCode?

Thanks

Brian

[Sadie Henry]

@Brian Reid - What's happening is that we're detecting you're on a mobile device and we assume it's the same mobile device that the app is on. Thus, we're not showing the QR code and we're giving you the copy/paste option instead. Does that clarify?

[Sadie Henry]

@Brian Reid - can you send me a DM about the PIN issue? PIN registration is separate from the combined experience, so I'm not sure what's going on there. 

[Brian Reid]

OK @Sadie Henry - regards the lack of QR code - for one of my clients, the iPad is the end users computing device and the phone is the second factor - the iPad itself, though mobile, is treated like a laptop. Therefore it would be useful if we could have the reverse of the "can't scan image" option (which gives us codes to enter/copy+paste, and have a "show QR code" so that we can scan something when the above and similar scenarios are met.

[Deleted]

Hi there, I'm not sure if this has been addressed already, but I just signed up for a preview of the new experience. Upon enabling a test user with MFA, it only made me set up the authenticator app. Is there any way to force users to sign up at least one more authentication method, such as a phone number?

Thanks in advance.

[Brian Reid]

Do you have phone enabled in the MFA cloud settings area of the admin portal? 

[Derek_Jew]

Yes, all types are enabled. I see here: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Cool-enhancements-to-the-Azur... that there's the "two methods" at the top. I don't see any of that.

[Sadie Henry]

Folks - apologies for the delayed response! I just returned from being out of town. :)

@Brian Reid - that's a great suggestion. I will look into this with my team.

@Derek_Jew - if you require two methods for SSPR, the user will be required to register two methods. 

[Steve Motton]

We are also running into the "An Unexpected error has occurred" issue as mentioned in several post. We've tried adjusting the IE security settings as suggest but this issue still occurs. Has a true solution to this issue been found?

[James Miller]

Hi,

I've not reviewed all of the comments, so sorry if I'm doubling up. Firstly, the new experience is a massive improvement, and I'm training it as part of trailing the support for Security Keys.

One thing I've noticed is you appear to need to allow third party cookies, and/or disable the 'prevent cross-site tracking' features in the browser to work. Is this because it is a preview release, or is this related to the cookies not working across different domains?

James

[Eric Kurtz]

What is the timeline for this to be GA?  We would like to get this turned on before the start of school so the students have a better experience. 

[Sadie Henry]

James - glad to hear that you're liking the new experience! The issue you mentioned is a known issue that we're working to address now. You can expect a fix to be rolled out soon. :)

Eric - we're targeting GA in the next few months.

[Markus Strickler]

We are getting the following prompt today for some - but not all - users trying to register for MFA via aka.ms/setupsecurityinfo "The selected account does not exist in client "Microsoft" and cannot access the application "6d544468-7fef-481a-9bdf-f2314ee734fe" in that client. The account has to be added as external user in that client first. Please use another account" Are there currently changes being made?

[Manoj Sood]

@Sadie Henry - Thanks for providing lots of great feedback on this capability. We are hoping to role the combined MFA/SSPR experience out to our entire organiztion starting in a fews but are running into the "an unexpected erro has occured" issue that has been mentioned several times in the comments. Do you have any feedback on when this might be resolved and/or work arounds?

[Mattk623]

Is there a way to change which registration method is 'default'? Meaning, does the App need to be the first to attempt to register the user? We've enabled the application method for users, but most are using the Phone method and we want that to show first as an option during registration instead of mobile app.  Otherwise we need to instruct most of users to go to the 'I want to setup a different method' twice , once for each authentication method they need to setup where it defaults to trying to push the Mobile app first. 

[Brian Reid]

@Mattk623 - if you disable the app option in both MFA and SSPR then you will get phone first. Your default is the first option you register with. You can only change your default after you register. 

Out of interest though, why are they using phone as first preference? 

[Mattk623]

@Brian Reid Thanks for the quick response. I guess we were hoping to keep the app option for those that use it just not make it the first one that comes up on registration, but instead make the phone (text) registration be the first one, so I was hoping not to disable the app option all together.

Can you confirm your question of why they are using phone as first preference? As opposed to the app? We have about 1100 users registered so far, and 90% of them have asked to use a text code instead of the app - we tried to push the app as the 'recommended' option but too many users didn't want to download an app or thought it was too complicated. Does that answer what you were asking?

[Mattk623]

FYI: We are also running into the 'an unexpected error has occurred' error on some users

[Brian Reid]

@Mattk623 yes, that's the aim of the question - so a second question if you don't mind - I can see users thinking the app code is harder than SMS, but what about push notifications where they need to do next to nothing at all?

@Sadie Henry it would be great if Microsoft where to include an admin driven default as I discovered when writing https://c7solutions.com/2019/08/MFA-and-end-user-impacts that the different wizards have different defaults and it changes based on what methods are allowed as well. 

[Mattk623]

@Brian Reid I agree for me personally - however the 'go to the app store and download an application' was where a lot of sadly users threw up their hands ;) . We're having to deploy FOBs for a handful of users who were even afraid of getting a text message. 

[Sadie Henry]

@Brian Reid @Mattk623 Thank you for your feedback! This is definitely something we've considered and we'll continue to look into it. Because the Microsoft Authenticator app option is more secure than phone, we do want to do everything we can to push users towards that option. We're working on making that flow even easier for users.