Well, this is nice. Microsoft has released a migration tool to get rid of your On-premises MFA server.
Table of Contents
Scenarios
Moving the registered MFA phone numbers is only part of the migration from MFA Server to Azure AD Multi-Factor Authentication. The best approaches to integrate with Azure AD Multi-Factor Authentication depend on how the many systems that Microsoft’s MFA server can be integrated with are using MFA Server.
| Goal: Decommission MFA Server ONLY | Goal: Decommission MFA Server and move to Azure AD Authentication | Goal: Decommission MFA Server and AD FS | |
|---|---|---|---|
| MFA provider | Change MFA provider from MFA Server to Azure AD Multi-Factor Authentication. | Change MFA provider from MFA Server to Azure AD Multi-Factor Authentication. | Change MFA provider from MFA Server to Azure AD Multi-Factor Authentication. |
| User authentication | Continue to use federation for Azure AD authentication. | Move to Azure AD with Password Hash Synchronization (preferred) or Passthrough Authentication and Seamless single sign-on (SSO). | Move to Azure AD with Password Hash Synchronization (preferred) or Passthrough Authentication and SSO. |
| Application authentication | Continue to use AD FS authentication for your applications. | Continue to use AD FS authentication for your applications. | Move apps to Azure AD before migrating to Azure AD Multi-Factor Authentication. |
Who can use Azure MFA?
| If you’re a user of | Capabilities and use cases |
|---|---|
| Microsoft 365 Business Premium and EMS or Microsoft 365 E3 and E5 | EMS E3, Microsoft 365 E3, and Microsoft 365 Business Premium includes Azure AD Premium P1. EMS E5 or Microsoft 365 E5 includes Azure AD Premium P2. You can use the same Conditional Access features noted in the following sections to provide multi-factor authentication to users. |
| Azure AD Premium P1 | You can use Azure AD Conditional Access to prompt users for multi-factor authentication during certain scenarios or events to fit your business requirements. |
| Azure AD Premium P2 | Provides the strongest security position and improved user experience. Adds risk-based Conditional Access to the Azure AD Premium P1 features that adapts to user’s patterns and minimizes multi-factor authentication prompts. |
| All Microsoft 365 plans | Azure AD Multi-Factor Authentication can be enabled all users using security defaults. Management of Azure AD Multi-Factor Authentication is through the Microsoft 365 portal. For an improved user experience, upgrade to Azure AD Premium P1 or P2 and use Conditional Access. For more information, see secure Microsoft 365 resources with multi-factor authentication. |
| Office 365 free Azure AD free | You can use security defaults to prompt users for multi-factor authentication as needed but you don’t have granular control of enabled users or scenarios, but it does provide that additional security step. Even when security defaults aren’t used to enable multi-factor authentication for everyone, users assigned the Azure AD Global Administrator role can be configured to use multi-factor authentication. This feature of the free tier makes sure the critical administrator accounts are protected by multi-factor authentication. |
Azure MFA and NPS
Half legacy but half cloud. Many organizations use NPS for securing their Wi-Fi and LAN traffic or just to authenticate user based on their location inside AD or group memberships.
NPS is Microsoft radius-based access management solutions that has been the same from Server 2008 R2, no big game changers here.
Microsoft used to have an standalone on-premise version of MFA called MFA Server, but as of July 1, 2019, Microsoft no longer offers MFA Server for new deployments and organizations that want to use MFA have to move to Azure MFA.
But this is not a big deal, Microsoft offers MFA NPS Extension for NPS server to transfer organizations to the cloud based two-factor authentication.
How Azure MFA works with NPS
NPS get a authentication request example from Third-party VPN-solution with a user attribute ex. User group membership, radius will send this info to the requester. The requester acknowledges the request and sends the second authentication request for the user name.
Then radius send this request to MFA NPS Extension which will send it to Azure. Azure will check users authentication methods and send the request for authentication to user predefined device or user defined way.
When the user successfully completed the authentication Azure will send a notification to radius which will send it the VPN-solution then user will be signed to VPN. Windows Server 2012 or above.
Only Two-way SMS isn’t supported anymore as it was completely deprecated February 24, 2021.
How to configure Azure MFA NPS Extension
Extension will be installed to NPS Server directly so radius can use it freely and it can be installed to Server 2012 and above.
Download MFA Extension https://aka.ms/npsmfa and run the setup.exe.
When it will completes, enable tls 1.2 by running below from Administrative PowerShell.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Then you will configure the extension by running C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1 and will be asked for Global Admin credentials.
Quick tip! The new Hybrid Identity Administrator will also work for this setup.
You will need Azure tenant ID and you can find:
With Azure PowerShell
Connect-AzAccount
Get-AzTenant
With Azure Cli
az login
az account list
az account tenant list
With M365 Cli
m365 tenant id
Or with GUI
- Sign in to the Azure portal.
- Select Azure Active Directory.
- Select Properties.
- Then, scroll down to the Tenant ID field. Your tenant ID will be in the box.
The install will ask this tenant ID to register your MFA Extension to a correct tenant.
Notes for Azure MFA NPS Extension
The certificates the script generates are valid valid for 2 years. You have to monitor their revocation period if they expire extension will stop working.
For users that are not enrolled to MFA you need to enable REQUIRE_USER_MATCH in the registry of NPS Server that has extension installed.
Navigate to HKLM\SOFTWARE\Microsoft\AzureMfa and Create a new string value named REQUIRE_USER_MATCH and set the value to TRUE
You can check the successful logins with.
Get-WinEvent -Logname Security | where {$_.ID -eq '6272'} | FL
Or checking with GUI from security log.
You can debug information from AzureMfa/AuthN/AuthNOptCh, AzureMfa/AuthZ/AuthZAdminCh, and AzureMfa/AuthZ/AuthZOptCh event logs.
And can see the auth request with wireshark either with radius or with destion ports with
“ip.src==IpAddressOfSource and udp port 1812” if you used the default port. And without the brackets.
More info https://wiki.wireshark.org/Radius
or with Microsoft provided MFA health check script which will check the module
It will check the following, actually almost all the thing that could be wrong.
- Check accessibility to https://login.microsoftonline.com
- Check accessibility to https://adnotifications.windowsazure.com
- Check MFA version.
- Check if the NPS Service is Running.
- Check if the SPN for Azure MFA is Exist and Enabled.
- Check if Authorization and Extension registry keys have the right values.
- Check other Azure MFA related registry keys have the right values.
- Check if there is a valid certificated matched with the certificates stored in Azure AD.
- Check the time synchronization in the Server.
- Compare server time with reliable time server.
- Check all missing updates on the server.
Quicktip! In China Azure MFA doesn’t currently support mobile device notification as mobile phone notification services (Push notifications) are not working in there.
Enable MFA with Conditional access or per user
MFA migration tool
For the tool itself, the look and like of the tool is nice and compact.
Limitations and requirements
- The MFA Server Migration Utility is currently in public preview. Some features might not be supported or have limited capabilities. For more information about previews, see Supplemental Terms of Use for Microsoft Azure Previews.
- The MFA Server Migration Utility requires a new preview build of the MFA Server solution to be installed on your Primary MFA Server. The build makes updates to the MFA Server data file, and includes the new MFA Server Migration Utility. You don’t have to update the WebSDK or User portal. Installing the update doesn’t start the migration automatically.
- The MFA Server Migration Utility copies the data from the database file onto the user objects in Azure AD. During migration, users can be targeted for Azure AD MFA for testing purposes using Staged Rollout. Staged migration lets you test without making any changes to your domain federation settings. Once migrations are complete, you must finalize your migration by making changes to your domain federation settings.
- AD FS running Windows Server 2016 or higher is required to provide MFA authentication on any AD FS relying parties, not including Azure AD and Office 365.
- Review your AD FS claims rules and make sure none requires MFA to be performed on-premises as part of the authentication process.
- Staged rollout can target a maximum of 500,000 users (10 groups containing a maximum of 50,000 users each).
How to migrate?
Migration logic
| Method | Logic |
|---|---|
| Phone | If there’s no extension, update MFA phone. If there’s an extension, update Office phone. Exception: If the default method is Text Message, drop extension and update MFA phone. |
| Backup Phone | If there’s no extension, update Alternate phone. If there’s an extension, update Office phone. Exception: If both Phone and Backup Phone have an extension, skip Backup Phone. |
| Mobile App | Maximum of five devices will be migrated or only four if the user also has a hardware OATH token. If there are multiple devices with the same name, only migrate the most recent one. Devices will be ordered from newest to oldest. If devices already exist in Azure AD, match on OATH Token Secret Key and update. – If there’s no match on OATH Token Secret Key, match on Device Token — If found, create a Software OATH Token for the MFA Server device to allow OATH Token method to work. Notifications will still work using the existing Azure AD MFA device. — If not found, create a new device. If adding a new device will exceed the five-device limit, the device will be skipped. |
| OATH Token | If devices already exist in Azure AD, match on OATH Token Secret Key and update. – If not found, add a new Hardware OATH Token device. If adding a new device will exceed the five-device limit, the OATH token will be skipped. |
What when all goes south?
Microsoft has also a Roll-back solutions that you could use.
If the upgrade had issues, follow these steps to roll back:
- Uninstall MFA Server 8.1.
- Replace PhoneFactor.pfdata with the backup made before upgrading. NoteAny changes since the backup was made will be lost, but should be minimal if backup was made right before upgrade and upgrade was unsuccessful.
- Run the installer for your previous version (for example, 8.0.x.x).
- Configure Azure AD to accept MFA requests to your on-premises federation server. Use Graph PowerShell to set federatedIdpMfaBehavior to
enforceMfaByFederatedIdp, as shown in the following example.
|
1 2 3 4 5 |
PATCH https://graph.microsoft.com/beta/domains/YouDomain/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc Content-Type: application/json { "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" } |
And the users will no longer be redirected to your on-premises federation server for MFA, whether they’re targeted by the Staged Rollout tool or not. Note this can take up to 24 hours to take effect.
RSS - Posts