Migrating to Authentication Methods Policies – Happy days!

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.

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.

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 legacy MFA portal (Multi-factor authentication (windowsazure.com)), first of all you should review which methods are currently enabled;
  

• 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.