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:
Configuration/deployment
I won’t re-document the configuration steps here, I’ll just summarise the actual process:
- 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
- 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.
- 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.
Summary
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. pawill@contoso.com, and their Azure Authentication one-time-pin (OTP) code.
