HOWTO: Enable Azure Multi-factor Authentication on AD FS

Reading Time: 6 minutes

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll add an additional layer of information security to authentications that are routed through the Active Directory Federation Services (AD FS) implementation.

This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).


Why look at Multi-Factor Authentication

Many organizations rely on usernames and corresponding passwords to verify the person authenticating. However, there are several reasons why this is not a sufficient method to securing authentication:

  1. Web-based applications typically use the email address as the user name, because this is a globally unique identifier that people can get cheaply. Microsoft recommends keeping the userPrincipalName attribute equal to the mail attribute.
  2. People reuse passwords between accounts.
  3. Accounts are breached at a rate of 2 services per day.
  4. People are bad at coming up with strong passwords.

A (temporary) solution is to add multi-factor authentication to the authentication flow. This way, after a person has correctly entered the username and password, a second verification is performed. This verification is based on information that was previously registered, and should leverage a different authentication factor:

  • Something you can prove you know
    The password most organizations use
  • Something you can prove you are
    Think of a fingerprint, face or iris scan, like Apple has with TouchID and FaceID, and Microsoft offers on its Surface devices.
  • Something you can prove you have
    Think of a token device, a FIDO 2.0 key, certificate tied to a TPM chip or access to a phone or phone number in the form of returning a one-time password that you receive through a text message, a phone call or an authenticator app,

When you combine multiple authentication factors, multi-factor authentication (MFA) emerges, allowing for more secure authentication.


Reasons why

Usually, it only takes one leaked password to get to sensitive information an organization harbors. This could be privacy-related information related to employees and customers, but could also be information regarding products (source code), intellectual property and patents.

For systems, services and applications containing these types of information, multi-factor authentication should be used. For Azure AD-integrated applications, Conditional Access and Identity Protection offer multi-factor authentication, when needed. For AD FS-integrated applications, applying multi-factor authentication is more straightforward, unless you want to dig deep into REGEX…


Possible negative impact (What could go wrong?)

Multi-factor Authentication is a burden to end-users. Your colleagues and customers might not understand how to effectively perform multi-factor authentication, or move to a competitor that doesn’t require multi-factor authentication, or only when needed.

Choosing the right authentication method is important. Some multi-factor authentication methods are not as secure and user-friendly as others. For instance, because of recent SIM-swapping attacks, MFA through text messages is deemed too insecure to serve a purpose as multi-factor authentication method. Text messages are also inadequate for the situation where a person is on a plane, does have WiFi, but doesn’t have cellular reception.


About the Azure MFA Adapter

Microsoft introduced the Azure MFA Adapter in Windows Server 2016. When the AD FS farm runs the Windows Server 2016 Farm Behavioral Level (FBL), or up, this built-in adapter can be enabled and used.

When used, the Azure MFA Adapter communicates to Microsoft’s Azure MFA service to perform multi-factor authentication. People register only once for Self-service Password Reset, multi-factor authentication for Conditional Access, multi-factor authentication for Identity Protection and for multi-factor authentication for systems, services and applications through Active Directory Federation Services (AD FS).

Azure MFA Server also offers an AD FS MFA Adapter, but Microsoft recommends not performing new implementations of Azure MFA Server.


Getting ready

To implement the Azure MFA Adapter and secure AD FS-integrated systems, services and applications with multi-factor authentication, make sure to meet the following requirements:


Roll-out requirements

First off, everyone in scope for the AD FS-integrated systems, services and applications with multi-factor authentication needs to have performed their Azure MFA registration.

If a person doesn’t have an Azure MFA registration, access to the AD FS-integrated systems, services and applications for which multi-factor authentication is required, will be denied.

The scripts to get to know the colleagues using Azure Multi-Factor Authentication still offer sufficient functionality to discover who has an Azure MFA registration and which authentication method they use.


Information Requirements

To avoid multi-factor authentication prompt fatigue, multi-factor authentication should ideally only be required when strictly needed. It’s not the most brilliant of ideas to require multi-factor authentication for all AD FS-integrated systems, services and applications. Determine the systems, services and applications that truly need it, and require MFA in the situations where you need it. Application owners typically know best what their application does and needs.


System requirements

Make sure the AD FS servers run Windows Server 2016, or above, and are installed with the latest cumulative Windows Updates. Make sure the AD FS farm runs the Windows Server 2016 Farm Behavioral Level (FBL), or above.

As Azure Multi-factor Authentication information is stored in Azure AD only, and not written back to the on-premises Azure AD Connect or Active Directory environment, but is now used to integrate with on-premises systems, services and applications, now is a good time to look for a solution that creates backups of the Azure AD tenant.


Network requirements

The AD FS servers in the AD FS farm need to be able to communicate to the following urls over TCP port 443 (HTTPS):


Privilege requirements

Make sure to sign in with an account that:

  • Is a member of the Enterprise Admins group in Active Directory, and;
  • Has privileges to manage the AD FS farm.

In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS server.

Also, you’ll need the credentials of an account with the Global Administrator role in the Azure AD tenant in which you want to use Azure multi-factor authentication. If running these


License requirements

To use the Azure MFA Adapter with AD FS, at least one Azure AD Premium P1 license needs to be present in the Azure AD tenant. This license does not need to be assigned, but can be. The Azure AD Premium P1 license is a part of the larger Azure AD Premium P2 license, but also part of many of Microsoft larger cloud license suites, like EMS E3 and EMS E5.


Who to communicate to

If your users have not registered for Azure MFA yet, than this part of the implementation requires a communications plan.


How to enable Azure MFA on AD FS

Enabling Azure Multi-Factor Authentication on AD FS requires three steps:

  1. Register Azure MFA in the tenant
  2. Enable Azure MFA as AD FS Multi-factor Authentication method
  3. Choose an appropriate Access Policy per AD FS Relying Party Trust (RPT)


Register Azure MFA in the tenant

First, run the following lines of Windows PowerShell in an elevated PowerShell window on each of the AD FS servers in the AD FS farm:

Install-Module MSOnline


Log in.

$TenantID = (Get-MsolCompanyInformation).ObjectID

$Certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID $TenantID

New-MsolServicePrincipalCredential -AppPrincipalId
981f26a1-7f43-403b-a875-f8b09b8cd720 -Type Asymmetric –Usage Verify  -Value $CertBase64

Restart-Service adfssrv

Then, on the primary AD FS server in the AD FS farm, run the following line of Windows PowerShell:

Set-AdfsAzureMfaTenant -TenantId $TenantID -ClientId


Enable Azure MFA as AD FS multi-factor authentication method

Now that the Azure MFA Adapter is available as a multi-factor authentication mechanism, we need to enable it for the AD FS farm, again on the primary AD FS server.

Run the following lines of Windows PowerShell:

$C = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider


Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $C


Choose an appropriate Access Policy per Relying Party Trust

Each AD FS-integrated system, service and application has its own relying party trust (RPT) relationship with AD FS. In AD FS on Windows Server 2016, and above, you can enable multi-factor authentication with built-in access policies.

These policies are aptly named:

  • Permit everyone and require MFA for specific group
  • Permit everyone
  • Permit everyone for intranet access
  • Permit everyone and require MFA from unauthenticated devices
  • Permit everyone and require MFA from extranet access
  • Permit specific group
  • Permit everyone and require MFA, allow automatic device registration
  • Permit everyone and require MFA

You can add access policies yourself if none of the built-in access policies fit your organization’s needs.

By default, every relying party trust is not configured with an access policy, which is the equivalent of the Permit Everyone access policy. You can change it to another policy using the following line of Windows PowerShell:

$RPT = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform"

-TargetRelyingParty $RPT -AccessControlPolicyName "Permit everyone and require MFA from extranet access"


Testing Azure MFA on AD FS

After enabling the Extended Protection for Authentication feature,  it’s time to test.

The Permit everyone and require MFA for specific group access policy is the ideal method to test the correct registration and working of Azure MFA. Simply create a group in Active Directory, configure the access policy for a relying party trust with the access policy and the group. Then, add a user account that had previously registered MFA to the group and use it to sign in to the system, services or application that is represented by the relying party trust.



One Multi-factor Authentication method for all your organization’s Azure AD- and AD FS-integrated systems, services and applications?

Yes, it’s possible!


Further reading

Configure AD FS 2016 and Azure MFA
Getting started with Azure Multi-Factor Authentication and AD FS
Securing cloud resources with Azure Multi-Factor Authentication and AD FS
AD FS 2016 and Azure MFA – a few Nuances
Step-by-Step guide to configure Azure MFA with ADFS 2016

34 Responses to HOWTO: Enable Azure Multi-factor Authentication on AD FS


    What if you want to use more than one Tenant? Say in an education environment where there are multiple Tenants, can you associate multiple tenants to one ADFS Azure MFA configuration?

    • Hi Chris,

      You can point multiple Azure AD tenants to the same AD FS implementation.
      However, the Azure MFA configuration will always be tied to one of the Azure AD tenants and this tenant will incur the licensing cost.


    It would be worth calling out which of the constants – like GUIDs – are "pre-defined" and have to be those values, and why. For example,


    Is that a Microsoft-specified GUID? Random? Generated by App Proxy? Tenant or ADFS specific? What if there are multiple ADFS farms, tenants etc – is it always the same?

    • Hi David,

      Thank you for your question.
      The GUID you mentioned is an Azure AD-specifiek UUID. It is the UUID used to point to the MFA service and is the same for every Azure AD tenant. You point to your MFA service by specifying the tenant ID.


    In my case it only worked after installing the Azure AD Powershell Module on every server of the ADFS Farm. I've read this as a prerequisite in other guides. So is this mandatory? (Windows Server 2019, FBL 4, ADFS Farm with 2 Nodes with WID)

    • Hi Ronny,

      This week, I enabled Azure MFA on a similar AD FS Farm as yours.
      As you can see, the PowerShell snippets above all use cmdlets from the MSOnline module, not the AzureAD module.
      There is no need to install the AzureAD module to complete this task.


    It nice and clear written easy to follow.
    But I got 1 one question I'm looking for a 2fa authentication so if I log In as a user it will ask me the password and the 2fa prompt is this purpose of azure 2fa?

    • Hi Achie,

      You can use Azure MFA for this purpose:

      • when accessing services, applications and systems that are connected to Azure AD
      • when accessing services, applications and systems that are published through the Azure AD Application Proxy
      • when accessing services, applications and systems that are connected to your AD FS implementation(s)
      • when accessing services, applications and systems that are published through your Web Application Proxy server(s)
      • when accessing services, applications and systems that rely on the RADIUS protocol

      If you want multifactor authentication when signing into Windows interactively, take a look at Windows Hello with multi-factor device unlock.


    I am currently using MFA for Office 365 with success, but I suppose I would still need to run the commands on both the tenant and local ADFS to enable this feature?
    I'm wanting to enable for other services I'm using ADFS for.

    • Hi Tyler,

      You're currently using Conditional Access to require MFA. This is an Azure AD feature.
      To require (the same) MFA from people accessing your AD FS-integrated applications, services and systems.


    Confused – I setup ADFS and integrated with azure ad using the azure ad connect tool. So, I have an onprem user who was synced to o365 just fine, now when they login, it redirects them to onprem adfs etc etc.. all works well. In o365, i enabled / forced MFA for that user and now when the user goes to login, ADFS automatically prompts for ms authenticator app… This works well without me doing ANYTHING on adfs. What did I do wrong here and do I still need to run the above commands to integrate adfs with azure ad mfa?

    • Hi JT,

      What you're experiencing is Azure MFA through Conditional Access.
      Conditional Access only applies to Azure AD and Azure AD-integrated services, like Microsoft 365.

      This way, you can use Azure MFA to secure access, but only to Azure AD-integrated resources and not with other RPTs in AD FS.
      If this is the desired outcome, than you don't have to perform additional actions. If, however, you want Azure MFA with other RPTs, you'll need to perform the steps in this blogpost.


    I keep getting this error when trying to do the first steps.

    $TenantID = (Get-MsolCompanyInformation).ObjectID$Certbase64 = New-AdfsAzureMfaTenantCertificate –TenantID $TenantID

    New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type Asymmetric –Usage Verify -Value $CertBase64

    Restart-Service adfssrv

    At line:1 char:50
    + $TenantID = (Get-MsolCompanyInformation).ObjectID$Certbase64 = New-Ad …
    + ~~~~~~~~~~~
    Unexpected token '$Certbase64' in expression or statement.
    + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnexpectedToken

    • Hi Tyler,

      The first line you quoted are two lines of Windows PowerShell, not one.


    Hi, I want protect a on-premises AD FS Resource with Azure MFA. But our Azure AD Connect is configured to use the password-hash sync not a AD FS federation. Is PHS supported too?

    • Yes, you can use the AD FS MFA Adapter for this use case, too.


    This is a very nice article and process is very well defined. I have a few questions:

    • Once Azure MFA service is enabled will it have any impact on existing AD FS or Azure AD-integrated applications, until we enable Conditional Access on Relying Party Trust?
    • How can we disable and cleanup this service if we do not need it?
    • Hi Sukhwinder,

      The multi-factor authentication provider will only trigger when you configure a Relying Party Trust to require MFA (for instance through an AD FS access control policy) or when you change the Global Multi-factor authentication policy in AD FS to require MFA. If there are no requirements in AD FS to perform MFA, the MFA adapter will not trigger. But, when you've configured the federation for your verified custom DNS domain name in Azure AD with the -supportsmfa option, then the MFA adapter is known to Azure AD. Any Azure AD Conditional Access policy requiring MFA will then be rerouted to AD FS to perform MFA.

      Why would you want to remove multi-factor authentication?


    Thank you for that great article.

    Do you know any possible way to redirect new users to the MFA Setup? Actually all new users running into an ADFS Error Page

    MS have this link to setup:


    Hi Sander,

    Thank you for that great article.
    I followed your blogpost, I can't get the ADFS to prompt for MFA, any ideas ? try to setup zoom to prompt for Azure MFA .


    Hi Sander, What is the process when you add new ADFS nodes to your existing ADFS farm which is already MFA enabled?

    • Hi Michel,

      Any AD FS server that will authenticate users for an MFA-enabled relying party trust (RPT) should have the MFA adapter installed.
      This holds true for any MFA method added to AD FS.

      But of course, you may can internal AD FS servers in an AD FS farm that only authenticate internal users, that are not pointed to on Web Application Proxy servers, or are not part of the load balancer that Web Application Proxy servers are pointed to…


    When will vCenter support Azure AD and Azure MFA natively? ADFS is going away in the next couple of years and we need for vCenter to support Azure AD and Azure MFA (cloud based, not the ON-Prem MFA).

    • Hi Shannon,

      VMware currently supports IdP federation for vSphere 7's vCenter Server with AD FS on Windows Server 2016, and later. Obviously, I cannot answer if or when a multinational like VMware is to support a specific feature. However, I know that IdP Federation for vSphere vCenter Server technically works with Azure AD. (It's just not supported by VMware).

      However, federation with Azure AD for infrastructure services doesn't make much sense to me. When your internet connection fails, it means you can no longer access the connected on-premises applications, services and/or systems. I encountered an organization that had authentication to their WiFi accesspoints configured based on Azure AD authentication. When their (admittedly single) internet connection failed, they could no longer sign in to WiFi and had to find cables to get a connection to their infrastructure again. When you use the IdP Federation for vSphere vCenter with Azure AD and your internet connection fails, the Azure AD service fails (temporarily) or the Azure MFA service fails (temporarily), you will not be able to use your delegated credentials to sign into vCenter (temporarily) and will need to retrieve the root password (which is safely stored on two pieces of paper in two sealed enveloppes in two geographically dispersed vaults, right?).

      Furthermore, the information in the above blogpost features the Azure MFA service, not Microsoft's on-premises Azure MFA Server. When you perform the steps outlined above, people in your organization will have already registered with the Azure MFA service and can re-use that same registration going forward, regardless of your choice between AD FS and Azure AD.


    Thank you Sander for the simple and effective article, just want to know is there any way we can use text messages as an MFA. The MFA adapter is only prompting for the Authenticator App usage which is not always preferred by our clients.

    • Yes, the Azure MFA Adapter for AD FS supports text messages.
      However, with default settings Azure MFA does not offer text messages as Azure MFA authentication method.

      You can test authentication methods by signing into, adding security methods and changing the default method. Here's more information. If Text me a code is not available when you add Phone, Alternate phone or Office phone as an authentication method, than the text message method is disabled in either or both the legacy PhoneFactor portal settings or in the Authentication Methods blade.

      Security Defaults in Azure AD also prevent using Azure MFA authentication methods other than Authenticator-based ones.


    With the Azure MFA plugin for NPS you have a registry setting to only trigger MFA if the user is enabled for MFA. Is this also possible with Azure MFA for ADFS?


    Do yo have to do anything on the 2019 ADFS Proxy Server (WAP)?

    • Nope.


    I have seen that the app principle ID 981f26a1-7f43-403b-a875-f8b09b8cd720 only becomes available on Azure AD P1 tenants and higher. I assume the requirements are P1 and up to implement the actions written in this blog?

    • Yes.


    Hi sander,
    Great post,
    Thank you for this very detailed article and the quality of your answers.


    This is a good article. However, I customized the AD FS error page based , based on the information from the official article, so that when a non-registered MFA user tries to sign in to the Office 365 portal. First, I authenticate via input username and password in AD FS page, then an error said we need additional information to verify and it will redirect in 5 seconds, however I got the redirect error page in a loop, any ideas?

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.