When you should use Azure MFA and when you should use MFA Server

One of the most common security-related trends I’m seeing with customers is an interest in adding multifactor authentication (MFA) to both their new and existing solutions. This trend is usually driven by a need to increase overall security, or to satisfy regulatory requirements. As a hybrid service, Azure MFA

MFA and the Market

MFA is the “what you have” factor added to the “what you know” authentication factor (e.g. userid / password). Though “what you have” has historically been a hard token such as an RSA SecureID fob, or a software incarnation of the same, what has really boosted MFA’s popularity in the last few years is the fact that most of us now have a device that can be used as a second factor: your smart phone. A company named PhoneFactor developed an MFA solution that recognized this, and in addition made deployment simpler by putting the telephony end (handling the MFA notifications by phone, text, or push notification) into a cloud service so customers didn’t have to mess with it. Microsoft purchased PhoneFactor in 2012 to incorporate its technology into Azure, and the evolved product is known as Azure Multifactor Authentication.

As I’ve said, businesses already understand the advantages of MFA. In the consumer market, however, even though MFA is increasingly available for prominent SaaS applications (for example Google, Facebook, Twitter, Microsoft, and LastPass) I fear that adoption is still very low. As a professional identity-type person, I’ve enabled MFA on as many services as I can. Don’t get me wrong; I hate the extra pain of checking my phone for an SMS message or an authentication code from an app as much as the next person. But I recognize it can – and has – saved my accounts from hacking, so I deal with it. And if you’re reading this I strongly recommend you also turn on MFA wherever possible.

MFA for Office 365 vs. Azure MFA vs. MFA Server

Let’s say you’re evaluating Azure MFA to determine if it will help your company’s security. First, understand that if you want all of Azure MFA’s capabilities you must purchase an Azure AD Premium subscription. A subset of MFA capabilities is available without Azure AD Premium (for example basic MFA for Office 365 users and admins, or MFA for Azure AD admins), but most companies considering a broad MFA adoption need the Premium subscription. (This table shows the difference between MFA for Office 365 and Azure MFA.) As always, there are licensing and pricing considerations in your deployment; if you’re buying Azure MFA standalone you can license it on a per authentication or a per user basis.

The full capabilities of Azure MFA include the on-premises MFA Server.  (Yes, the branding is confusing.) MFA Server and its associated components – User Portal, Mobile App Web Service, and AD FS Adaptor – is the most visible part of the original PhoneFactor product. The UI (below) is significantly different than Microsoft-developed products, and the administration model is unusual as well.

MFA Server administration console

When would your requirements be satisfied with Azure MFA alone? When would you need to deploy MFA Server? Let’s look at the most common use cases for both Azure MFA and MFA Server:

You can see the trend: most of the time, you need MFA Server if you’re going to protect on-premises resources. The other set of use cases for MFA Server are when authentication is taking place against your on-premises AD because you have AD FS with a federated trust to Azure AD. In these cases, authentication requests presented to Azure AD are redirected to AD FS. And if AD FS has the MFA Server’s AD FS Adapter installed, it will use MFA Server to perform the MFA request. (Note that MFA Server doesn’t support third party federation servers; you must use AD FS.)

There are circumstances, such as securing access to Office 365, when you can use either Azure MFA alone or MFA Server. Which you choose depends on where you want the MFA enforcement in the authentication flow. For example, if you need additional authentication rules to provide a more granular allow / deny / MFA policy for Office 365 users, you’d want to put MFA with AD FS because AD FS offers that additional level of control.

Going forward, I’m convinced that Microsoft’s hybrid MFA service will continue to provide solid support to secure both cloud and on-premises resources, and we’ll continue to see new capabilities appear. But I doubt the architecture will look the same as we see it today. The on-premises component will become much lighter in weight and eventually be very minimal, simply relaying MFA requests to Azure MFA.

I have no inside information to lead me to this particular prediction. But Microsoft’s clear hybrid identity architecture trend – Azure AD Application Proxy, Azure RMS, and others in the works – isn’t to increase the on-premises footprint with servers to enable cloud capabilities. Customers have told Microsoft, loudly and clearly, that this architecture is a step backward to make a step forward. Instead, putting a lightweight connector or groups of connectors into a company’s data center that are relatively easy to install and automatically provide load balancing and high availability capabilities is far more palatable. Anyone that works with MFA Server over a period of time recognizes that it’s the cloud service being enhanced while the on-premises server is being maintained, but not enhanced. Indeed, some of its capabilities are being moved: AD FS in Windows Server 2016 has a built-in Azure MFA adapter, eliminating the need for the MFA Server AD FS Adapter.

Look to Azure Multifactor Authentication to secure both on-premises and cloud resources in the Microsoft hybrid identity architecture. But as with any architecture in today’s rapidly evolving information technology landscape, don’t expect it to look the same a few years from now.