Migrate Azure Multi-Factor Authentication Server to cloud-based Azure MFA
With the end of support for Azure MFA server on-premises coming September 2024, it’s time to start building the plan and testing your move to Azure cloud-based MFA. There are some planning and consideration steps that we will take a look at in today’s article, and we’ll get you to all the correct Microsoft Learn docs to build your migration successfully.
First up is a bit of a baseline on what we are starting with. Azure MFA Server is when your MFA is on-premises. There are different reasons to have your own MFA server inside your infrastructure, but we have about one year to get ready and move in to Azure cloud-based MFA as the server will stop processing requests after the deprecation date in September 2024. If you activated your on-premises MFA server before July 1, 2019; you are eligible for future updates and you will be able to download the latest version to get the migration agent — we’ll take a look at that sweet feature in a few minutes!
The first step to planning a move away from on-premises MFA is to download the latest MFA Server version, log into your Azure portal at https://portal.azure.com. Then head to Azure Active Directory > Security > MFA > Manage MFA Server > Select Server Settings and you should see a Download Link.
Installation is straight-forward (we will not cover setting up fully since we should not be doing this with a deprecation date already on the books!). Follow the installation steps with the wizard, and skip the Authentication Configuration Wizard. In case it needs to be said, please do upgrades during your approved outage window; which is never Friday afternoon right?!
Alright, now that you have the latest version of Azure MFA Server installed, run your approved patching processes and make sure everything is up to date. I’ll go make a coffee while you take care of that….
The most common scenario for usage of Azure MFA Server existing on-premises is that you are likely to have and use an AD FS environment along-side. For your MFA migration to work, you will also need to update your AD FS for Windows Server 2019 to Farm Behavior level 4 (FBL 4).
This particular AD FS configuration (FBL 4) change allows you to select an authentication provider based on group membership. You can use AD FS for Windows Server 2016 which is FBL 3, but it will not be seamless and users will be prompted to manually select their authentication provider under the FBL 3 setting. This is important to move to FBL 4 so that we can use groups to handle staged-rollouts (POC) for testing purposes. Check out the links at the end of this article to get the full Prerequisistes breakdown on the migration path.
There are additional considerations for the migration of MFA other than just the MFA provider:
- User MFA information such as phone numbers.
- Ensure Azure AD combined security information is enabled to prevent multiple registration pages for users.
- Hardware security keys – the MFA Server Migration Utility can help to syncronize MFA settings between MFA Server and Azure AD MFA to use staged rollout to test user migrations without changing domain federation configuration.
- Consider and make a decision if Azure AD authentication for users will be used. Azure AD authentication enables more robust security and governance.
- Consider moving AD FS applications to Azure AD as part of the overall migration. There are numerous benefits and security gains in doing this and you can check out my previous articles to learn more about moving to Azure AD from AD FS.
- Consider moving users to Passwordless Authentication as part of their enrolment in Azure AD MFA. There are excellent options including FIDO2 security keys and Windows Hello for Business.
- Consider enabling SSPR (Self Service Password Reset) in Azure AD. SSPR allows users to securely reset their own password, and have it written back to on-premises Windows Server AD DS. This can be enabled quite simply and the user registration is tied to my earlier suggestion to enable combined registrations in Azure AD. Register for MFA, and SSPR is also setup at the same time for the user.
- Remember any RADIUS servers that are pointing to your Azure MFA Server for authentication services. You will need to make a change possibly here and use Network Policy Server (NPS) with the Azure MFA extension enabled.
There are likely other considerations in your own environment, so please be thoughtful and methodical in building your list of in-scope items and tasks for your migration project.
One of the great features of Azure AD is that it works so well with standardized protocols such as SAML, OATH2, etc. If your environment is using 3rd part tooling such as Ping, Okta, or DUO products; your scenario is most likely supported, and federation changes may not be required unless you have decided to move authentication from on-premises Windows Server AD DS to Azure AD. That is more than one conversation right there, so let’s just leave it for today but we will revisit that in our considerations as listed above.
Please take some time to explore all of the information on this exciting move to cloud-based MFA. Building secure and robust authentication is a great way to improve efficiency, lower total overhead required to maintain the systems, and supports building improvements to security, monitoring, and ease of user for our users.