MSEndpointMgr

Migrating to Authentication Methods Policies – Happy days!

1 authentication portal to rule them all

Over recent times we have seen Microsoft introduce a range of security hardening configuration options as the world continues to adopt to the fact that their internal infrastructure is no longer the main threat surface. In this post we will look at the latest of which (due to be enforced in January 2024).

The new Authentication Methods Policies configuration (also referred to as the “converged authentication method experience”) is something which brings a welcome change, retiring per user based MFA configurations managed through the Microsoft admin portal (which effectively just launches a legacy portal of it’s own), along with separate configuration methods for Azure AD Self Service Password Reset. This is welcomed change, especially for the legacy per user MFA configuration, which if you are still using it, please stop.

Authentication methods policies – The new normal

The existing authentication methods policy blade has received a new function called “Manage Migration (preview). (Azure AD -> Security -> Authentication Methods).

Essentially this new migration path will allow you to handle all authentication methods policies in a single blade of the Azure AD portal. Vs. SSPR authentication methods being in it’s own blade and legacy MFA methods being in an entirely different portal of it’s own (which looks like child of a grey piece of paper and a corpse).

Pro tip – read this blog in it’s entirety before doing anything in production. There are a ton of external references throughout this post. And for good reason! Authentication in Azure AD is a complex subject which takes time to master.

Bye Bye Per User MFA Configuration

A little intro for those who might not know what “Per user MFA” covers;
Per user based MFA configuration has been around since the “Office 365” brand was launched (ca. 2012), providing the ability to enforce multi-factor authentication requirement for users. Management takes place within the Microsoft Admin portal (https://admin.microsoft.com), and by default resulted in users being provided with an “app password” which was used to sign into Microsoft Office applications, providing in effect an “MFA bypass” for those trusted applications due to the fact they had a system defined password which was different to the user’s actual password.

The experience IMO was, shall we say.. terrible. This methods is also classed as legacy authentication and thus app passwords do not work with accounts which are required to use modern auth.

Real time video of an administrator configuring per-user MFA

Since then thankfully the world has moved on quite a bit, and today, if you are using the legacy MFA configuration portal to enforce MFA, you are simply doing things wrong. Multi-factor challenge requirements should be all handled via conditional access, and identity protection policies, depending of course upon your Azure AD Premium licensing model (non-premium licensees should enable security defaults yesterday!)

Supporting Microsoft Learn Documentation
Enable per-user Multi-Factor Authentication – Azure Active Directory – Microsoft Entra | Microsoft Learn
What is Conditional Access in Azure Active Directory? – Microsoft Entra | Microsoft Learn
What is Azure Active Directory Identity Protection? – Microsoft Entra | Microsoft Learn

Authentication Configuration “revamped”

As many of you might have spotted either in the Azure Active Directory blade, or within the new Microsoft Entra portal (https://entra.microsoft.com), authentication methods provides you the ability to enable and configure multiple authentication types which can be used within your Azure tenant.

authentication methods policies blade
Authentication Methods Policies blade

If you haven’t spotted this, then you are also missing out on the fact that MFA app based challenges where due to be changed to require “number matching” for all tenants on February 27th 2023, although this has been pushed back to May 8th 2023 when you read the documentation;

If that has come as a surprise to you, then I suggest you review the changes (Protecting authentication methods in Azure Active Directory – Microsoft Entra | Microsoft Learn) and issue communications to your user base as to avoid your helpdesk staff having to deal with “did you change something? I have to enter a number now” type questions.

Pre-Migration Considerations

Before you go ahead and make the jump to the new way of doing things, it is important you consider how removal of MFA enforcement will impact the security of your tenant. For example, if you have been using this method for your admins, you either need to enable security defaults (which brings limitations), or ensure / create conditional access policies are configured to cater for the different authentication scenarios.

Privileged Role Accounts

As an absolute minimum baseline, protecting your privileged role members can be undertaken through using the CA policy templates;

As always when creating conditional access policies, ensure you have a break glass / emergency admin account created, with a complex password, and excluded from the conditional access policy (just in case something goes bump in the night with the MFA service) – Manage emergency access admin accounts – Azure AD – Microsoft Entra | Microsoft Learn.

General User Access

We won’t be covering conditional access policies for all scenarios in this post, as it is a large topic by itself. I would suggest that you take a persona based approach to your CA configuration however, and recommend that you read the Microsoft learn docs in relation to this – Conditional Access architecture and personas – Azure Architecture Center | Microsoft Learn

Security Questions in SSPR – not in the new experience

Within the migration to the new authentication methods configuration, the ability to use security questions for Azure Self Service Password Reset is retired. This is for the best, as typically the answers to questions are either forgotten or the same answer is used for all questions. Microsoft has however stated that a migration will happen at a later point, but for now you must either remove the security questions option, or leave it as is in the SSPR portal.

The Migration Process

The process of moving from the old legacy portal to the new authentication methods configuration is quite simple, so let us step through this.

  • In the Authentication Methods configuration (in either Azure portal Active Directory Authentication Methods or Entra portal Authentication methods) you will see a notice about the “Manage migration (Preview)” feature;
  • Clicking on the “Manage migration (Preview)” link, clicking this will display the following slide in:

Nice an easy step-by-step method (good job MS!) But, First things first. Before pulling any levers we need to start with reviewing and aligning the existing supported methods to our desired outcome.

Review and set

  • Going into the Azure AD Self-Service Password Reset configuration, again let’s review the existing methods here also;
  • In this example we have then decided that I am going to retire SMS and Phone calls, moving to a model that uses the Authenticator app and Temporary Access Pass methods.

    We recommend, where possible, retiring SMS and Phone call authentication as they are the weakest options, however, you could take a phased approach where these methods are phased out.
  • Before we make changes, we need to disable the legacy MFA enforcement for all enforced users in the legacy MFA portal (you did read the part about Conditional access right? No? OK, wow…):
  • Now going back to the Authentication methods configuration, we configure the required methods;
  • In the configuration options for the Authenticator method, we can also specify to enforce number code matching before it is pushed by Microsoft to all tenants, and also include the options to display the location and application signing in, all of which are important information to present to the end user;
  • The temporary access pass configuration is then also configured;

With the new configuration set, for both the legacy MFA portal and AD SSPR configuration we are ready remove all methods from these legacy management areas. Which we can’t do before we set our migration state to “migration in progress“.

Now we’re making bacon!

When switching to the authentication methods policies blade to manage all our methods, the first thing that we need is to set the tenant into a “Migration in Progress” state. What this does under the hood is to allow us to uncheck the supported MFA methods in both the legacy per user multi-factor, and Azure AD Self Service Password Reset configuration pages (don’t worry, you can roll-back).

  • Now go to the SSPR blade and uncheck all methods (except of course the security questions if you need those to be enabled, which I am sure your users will just love you for!).

NOTE: the “Number of methods required to reset” is not being moved as this is an SSPR only setting (Self-Service Password Reset is still it’s own thing as a service and will not disappear anytime soon). Please keep this in mind and always make two methods available in the new policies blade.
Self-service password reset policies – Azure Active Directory – Microsoft Entra | Microsoft Learn

  • Next up is the legacy (phonefactor) MFA portal, where you can find relief in the fact that you never have to visit this portal again! So, untick those verification options and get the heck out of there!
  • If you receive the following error, try refreshing the portal as the configuration has not been updated to allow you to have no methods specified (try refreshing / signing out and back in );
  • Testing the updated configuration, we should receive an authenticator prompt with the additional number matching and location information displayed;

If you believe you can achieve

  • At this point with all configuration items done, we can go and set the tenant state to “Migrated” in the Authentication Methods configuration;
  • You should now receive a visual confirmation that the setting has been applied;

That’s it! You are welcome to treat your self to a steak dinner, you deserve it!

Closing Thoughts

Migrating to the authentication methods configuration is a straight forward process, resulting in a single configuration page for your auth methods (security questions aside).

So our suggestion is to plan your migration today, and not leave it up to January 2024 to be in a panic situation, especially when it comes to your conditional access policy configurations.

And as always we do appreciate the likes and follows on the SoMe’s as it is our only real indicator of popularity , as we seldom leave our bat-cave.

(12529)

Maurice Daly

Maurice has been working in the IT industry for the past 20 years and currently working in the role of Senior Cloud Architect with CloudWay. With a focus on OS deployment through SCCM/MDT, group policies, active directory, virtualisation and office 365, Maurice has been a Windows Server MCSE since 2008 and was awarded Enterprise Mobility MVP in March 2017. Most recently his focus has been on automation of deployment tasks, creating and sharing PowerShell scripts and other content to help others streamline their deployment processes.

Jan Ketil Skanke

Jan Ketil is an Enterprise Mobility MVP since 2016 and are working as a COO and Principal Cloud Architect at CloudWay in Norway. He has been in the industry for more than 20 years working for both Microsoft Partners and Microsoft. He loves to speak about anything around Enterprise Mobility and Secure Productivity. He is also the lead for the community conference Experts Live Norway. Jan Ketil has presented at large industry conferences like Microsoft Ignite, Microsoft Ignite The Tour, Microsoft Inspire, Experts Live Europe, Techmentor HQ (3rd best session 2019) and NIC Conference in Oslo.

Michael Mardahl

Michael Mardahl is a seasoned IT pro with over 25 years of experience under his belt. He's a Microsoft Certified Cloud Architect at APENTO in Denmark, where he helps customers move from traditional infrastructure to the cloud while keeping security top of mind. When he's not working, Michael's either spending time with his family and friends or passionately blogging about Microsoft cloud technology. His expertise in this area has even earned him the prestigious title of Microsoft Most Valuable Professional (MVP) in both the Enterprise Mobility and Security categories. In short, Michael is the IT equivalent of a rockstar, but don't expect him to act like one - he's way too down-to-earth for that.

4 comments

    • Hi Nigel,
      Thanks for the feedback.
      The article does assume existing knowledge of how SSPR functions, but I will update the article with a note 🙂

      I did speak with Microsoft about this, and there are no plans to move the control for “number of methods required”.
      For Admins it has and will always require two methods. the policies that we are moving are simply controlling what methods are allowed not the amount that SSPR will require.
      Since he was prompted, I assume you have required registration in SSPR in the “Password reset | registration” blade?

      • Thanks for the very thorough response,

        Yes, this is set to require register.

        I guess the question I have is what two methods will be enforced to admins with the new authentication experience. Namely, we do not allow SMS or Phone now, yet this is the prompt one of our admins received after migration.

Sponsors