Azure Multi-Factor Authentication (#AzureMFA) and Active Directory Federation Services (#ADFS)

Today, implementing Azure Multi-Factor Authentication (MFA) in an hybrid identity and access management solution based on Azure Active Directory (Azure AD, AAD) and Active Directory Federation Services (AD FS) more often than not requires that you implement the on-premises Azure MFA Server component.  This is because you typically have relying party (RP) trusts established in your on-premises AD FS federation service.  That is, you have some Software-as-a-Service (SaaS) apps that authenticate via AD FS and not Azure AD.  In order to introduce Azure MFA into the authentication process for these apps you require a secondary authentication provider deployed within AD FS.  Smaller deployments can install the MFA Server component directly on the federation service (FS) servers; larger deployments, i.e. more than two FS, will generally build out a load-balanced Azure MFA Server “farm” and utilise the Azure MFA “adapter” (the secondary authentication provider) to talk to Azure MFA Server via the load-balanced VIP (virtual IPv4 address).

I’ll provide a couple of drawings, to illustrate what I’m talking about.  Firstly, here’s the on-premises scenario – SaaS, AD FS and MFA Server.  In this case Azure MFA Server is mandatory – it’s no different to implementing any other MFA technology.  The cloud can’t really help with this use case today.


If you have an hybrid Azure AD and AD FS IdP then this is what it looks like: Azure AD, AD FS and MFA Server authenticating an Azure AD-hosted SaaS app.  In this case Azure MFA (cloud) is not used and again Azure MFA Server (on-premises) is because it’s a hybrid environment – it factors the AAD SaaS (and first-party) apps as well as on-premises apps.


If you’re building this now, especially if it’s for AD FS-only purposes, then this pattern is somewhat frustrating, more so if you have users registered with Azure MFA (the cloud service) or even Azure Password Management.  You cannot migrate registration data between cloud and on-premises (or between on-premises and the cloud) so you end up having to go all-out and deploy on-premises MFA Server, user and mobile registration portals, localisations and then manage the end-user communications and helpdesk management as well as the directory synchronisation.  Not ideal.  One example, I had to add eight (8) additional servers to an existing (I previously deployed) twenty (20) node AD FS deployment (8 FS, 8 WAP, 4 SQL) – 28 servers in total!

Which is why Windows Server 2016 Active Directory Federation Services (AD FS 2016) has a new and improved Azure MFA secondary authentication provider.  AD FS 2016 ships with a built-in “connector” for Azure MFA that talks directly to the cloud service and negates the need for any on-premises MFA Server infrastructure.  As long as the identities that AD FS is authenticating are synchronised to your Azure AD everything is in place.  Furthermore, AD FS 2016 actually enables Azure MFA as a primary authentication mechanism!  What does that mean?  It means that if you register the Azure Authenticator app, next time you access an AD FS protected resource you can authenticate by providing your username and the one-time-pin (OTP) code from the app.  No password!  This is one of several key new features arriving in AD FS 2016 that negate the need for users to provide credentials in the form of passwords!  I’ll blog about all of the no-password features in a separate post.  For now my focus is the Azure MFA [cloud] “adapter”.

May 2016 (Windows Server 2016 Technical Preview)

Windows Server 2016 Technical Preview 5 shipped a little while back.  When it shipped the Azure MFA secondary authentication provider was in private preview.  As of the 17th of May, 2016, the preview is public.  This means WS 2016 TP5 gives you everything you need to deploy Azure MFA as a primary or secondary authentication provider!

The official documentation was a few days behind the actual transition from private to public but is there now.  Here’s the URLs:


I won’t re-document the configuration steps here, I’ll just summarise the actual process:

  1. For each federation service server/node in your AD FS farm, you create a certificate that will be used to authenticate with Azure MFA.  AD FS provides a PowerShell cmdlet for this – New-AdfsAzureMfaTenantCertificate
  2. Each certificate is assigned to an Azure AD Service Principal by creating a service principal credential.  This is done via New-MsolServicePrincipalCredential and is no different to assigning a credential to an Azure Web App or Web API, etc.  The app principal ID is a constant – it’s 981f26a1-7f43-403b-a875-f8b09b8cd720.
  3. Lastly, once you’ve created a cert for each FS node and created a service principal credential for each cert you configure the Azure MFA provider using another AD FS PowerShell cmdlet – Set-AdfsAzureMfaTenant.  This operation is performed once per farm and can be run from any node.

Once this configuration is done you’re ready to start configuring additional authentication policies for RP trusts other than urn:federation:MicrosoftOnline (The Azure AD/Office 365/MSOnline) trust.  For the Azure AD trust you configure the SupportsMfa Boolean property of each federated domain (Set-MsolFederatedDomain) and utilise Conditional Access Policy (CAP) to invoke MFA for Azure AD apps (SaaS, PaaS, App Proxy and first-party apps).  When using Azure MFA there is no need to offload MFA to AD FS – you just use the cloud.  This is different – the inverse – from the AD FS 2012 R2 and AAD hyrbid model.

Caveats and limitations

There are some features missing.  You have to enable (or enforce) at the per-user level if you want an in-line registration experience.  Per-app MFA with automatic “in-line” registration is not available.  You obviously cannot only utilise Azure MFA as a primary authentication provider either, so the typical pattern will be to enable in isolation for the extranet and utilise IWA and/or FBA for the intranet.

The per-user model is particularly frustrating.  It effectively mandates the use of app passwords which are difficult to deploy and use.  The alternative is getting users to register themselves and then utilising CAP, however as this will break non-registered users I can’t see this being a suitable option either.  Time will tell how useful this is and whether it is a sufficiently flexible implementation that truly negates the need for an on-premises MFA Server setup.


Prior to Windows Server 2016 integrating Azure MFA with on-premises SaaS apps that authenticate using AD FS required an on-premises implementation of Azure MFA Server

Windows Server 2016 (starting in public preview in Technical Preview 5) introduces a new and improved secondary authentication provider for Azure MFA that does not require any on-premises components.  The “adapter” talks directly to the cloud service; configuration of all MFA properties are managed in the cloud (it’s a hybrid of on-premises and cloud when you use the on-premises MFA Server).

In addition to negating the need for on-premises MFA components AD FS 2016 also introduces additional authentication scenarios for Azure MFA customers.  Namely, as part of the drive to never require a password when accessing corporate resources from outside of the corporate network, AD FS 2016 supports Azure MFA as a primary authentication provider, which means users can sign-in to AD FS-protected resources using their username, e.g., and their Azure Authentication one-time-pin (OTP) code.


About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in AD FS, Azure MFA and tagged , , , , , . Bookmark the permalink.

10 Responses to Azure Multi-Factor Authentication (#AzureMFA) and Active Directory Federation Services (#ADFS)

  1. Arjan Mensch says:

    Thanks for this, and also has been updated.
    I’ve got a question though.
    The Principal ID (981f26a1-7f43-403b-a875-f8b09b8cd720) is a constant, and identifies the AzureMFA principal ID that is needed for the configuration.
    Any idea what to do when that ID is missing from the IDs on my tenant?
    If I Connect-MSOLService and then Get-MsolServicePrincipal | select DisplayName,AppPrincipalId | sort AppPrincipalId, that ID is missing.
    I have added the Multi-Factor Auth provider (twice now) from the Classic Portal, to no avail.
    Can I simply create the principal ID if I know all properties that need to be set?

  2. Wes says:

    Hi Paul, good stuff!

    We have Azure AD Join configured and this is working well with SSO for our Win10 (and Win2016 remote desktop server) machines for IE and Outlook. We have not deployed ADFS.

    Looking for a straightforward way to be able to integrate Azure MFA to protect a win2016 remote desktop server. Deploying RDG+ADFS+WAP all just to protect a single remote desktop server is kind of ridiculous. Is there a way to use ADFS on win2016 to simplify this scenario since our users will already be registered for Azure MFA and the win2016 servers are Azure ADjoined?

  3. Arjan Mensch says:

    Paul, thanks for your earlier replies.
    I managed to get some licenses for Office 365 E3 Premium, and of course, running into this issue again. Since you were able to look into this, is it possible to verify this:
    – Azure MSDN subscription
    – Office 365 E3 license
    – Azure AD Sync configured and running
    – ADFS 2016 up and running
    – Whole setup works as expected
    – I can enable and disable MFA from the Office Admin Portal for users
    – Still no principal 981f26a1-7f43-403b-a875-f8b09b8cd720

    Now that the Office 365 E3 licenses come into play, which DO include the MFA option, is there anyway to get the principal added to my tenant?

    Thanks again!


  4. Gismo says:

    How can you do to use MFA for users on a specific group from the extranet and unregistered device with Azure MFA Cloud and ADFS 2012 R2?

  5. Trix says:

    I really wish these diagrams were linked to their original source, which presumably had a legend that described what the numbers referred to.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s