_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 its 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.

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 its own blade and legacy MFA methods being in an entirely different portal of its own (which looks like child of a grey piece of paper and a corpse).

Pro tip -- read this blog in its 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.

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 (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 method 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 (https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults?WT.mc_id=ES-MVP-5004117) yesterday!)

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 (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 were due to be changed to require "number matching (https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-number-match?WT.mc_id=ES-MVP-5004117)" 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 (https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-default-enablement?WT.mc_id=ES-MVP-5004117)) 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.

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.

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 (https://learn.microsoft.com/en-us/azure/active-directory/roles/security-emergency-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 (https://learn.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-architecture?WT.mc_id=ES-MVP-5004117)

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 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 will display the following slide in:

Nice and 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.

Going into the legacy MFA portal, 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.

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:

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

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 its 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 (https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy?WT.mc_id=ES-MVP-5004117#administrator-reset-policy-differences)

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:

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 yourself to a steak dinner, you deserve it!

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.