Just like Microsoft is able to differentiate between different sizes and maturity levels of customers in its licensing, so is Microsoft’s on-premises Azure Multi-Factor Authentication (MFA) Server product.

Azure MFA Server allows for four Microsoft-supported deployment scenarios:

1. Simple Deployment
   One All-in-one Multi-Factor Authentication Server implementation
2. Redundant Deployment
   Two All-in-one Multi-Factor Authentication Servers with replication
3. Stretched Deployment
   A back-end Multi-Factor Authentication Server hosting the Management UI, the PhoneFactor.pfdata database and the MFA Web Service SDK and a front-end webserver running the MFA User Portal and (optionally) the MFA Mobile Portal
4. Complete Deployment
   Stretched deployment with multiple back-end and multiple front-end servers, using load-balancing, throughout.

Simple Deployment

In the Simple Deployment scenario, you’d place one Azure Multi-Factor Authentication Server on the internal network, and be done.

This server would be configured with the core Azure Multi-Factor Authentication components; the MFA Management UI and the PhoneFactor.pfdata database.

Optionally, the MFA User Portal can be installed, if the organization wants to enable end-user self-service for MFA (changing their phone numbers, their method, fallback questions and/or wants to delegate admin privileges to service desk personnel or other stakeholders within the organization. This feature needs IIS.

Optionally, the MFA Mobile Portal can be installed, if the organization wants to enhance the end-user MFA experience with the Microsoft Authenticator app. This feature needs IIS.

Pros

The Simple Deployment scenario offers a quick implementation. It can be achieved under an hour, depending on the Internet speed available, and only requires one Windows Server.

It is not a complex implementation to maintain, once implemented. In one relatively simple maintenance window, you can perform an in-place upgrade of all the functionality and revert back to the previous version, if need be, the entire server at once. You don't have to work together with other admins that have exclusive rights on web servers, for instance.

Cons

The Simple Deployment scenario does not offer high availability. When the server becomes unavailable, authentication stops. When the database gets mangled, a backup needs to be restored, or a new implementation needs to be performed.

The Simple Deployment does not offer the additional security, the more advanced deployment models offer, since all of the functionality is combined in one server on an internal network; Database and web functionality are not separated. In the unlikely event of a successful exploitation of vulnerabilities in the User Portal, other websites running on the same server or other applications hosted on the same server, the database could be compromised or deleted. Reasoning the other way around, traffic between the User Portal and the database (server) cannot be restricted or monitored.

This deployment model does not scale.

Redundant Deployment

To address the issue of not offering high availability, two MFA Servers can be implemented, as part of an MFA Server Group in the Redundant Deployment scenario. This way, replication is established between MFA Servers in the group for the authentication settings and preferences, stored in the PhoneFactor.pfdata database.

While the MFA Server core components themselves and RADIUS authentication do not require it, a load balancer should be used for the MFA Web Service SDK, the User Portal and the Mobile Portal to be made highly-available (and thus any components communicating to these, like the MFA AD FS Adapter).

PROS

In contrast to the Simple Implementation scenario, this scenario offers redundancy. If one server fails, the other server still holds the authentication settings and preferences.

Note:

Special care should be given to the Master Server role placement and the server(s) running the Directory Integration synchronization task.

This model scales. You can add additional servers. By default, additional servers become Slave servers to the initial Master server, but you can switch the Master server role to any server, if need be. Only the Azure MFA Server Master server has read/write access to the PhoneFactor.pfdata database. After changes, replication between the Azure MFA Servers distributes these changes to all servers.

CONS

High Availability (HA) comes at a price. Unless you’re merely using RADIUS or IIS authentication with a two-server setup, a load balancing solution is necessary.

This model scales, but it does so in per-server steps. When the bottleneck is with a particular Azure MFA Server component, the scale for the particular component cannot be increased without increasing the scale of all the other components in the deployment model, too.

Like the Simple Deployment, the Redundant Deployment does not offer the additional security, the more advanced deployment models offer, since all of the functionality is combined into All-in-one servers on an internal network; Database and web functionality are not separated.

Stretched Deployment

To address the security of the deployment, the MFA Server components can be divided between a back-end and a front-end server:

• MFA Back-end Server
  The back-end server runs the Azure MFA Server core components, like the MFA Management GUI, logging, Directory Synchronization. To allow communication with the front-end server, it also features the MFA Web Service SDK within IIS. The back-end server is placed on an internal network, or, when security policies dictate, on a separate network, only allowing the intended traffic with the front-end server, directory servers, DNS, time sources and MFA-enabled applications.
• MFA Front-end Server
  The front-end server is configured with IIS and offers the MFA User Portal and MFA Mobile Portal. This server is placed in a perimeter network and optionally configured as a Server Core installation. When you use MFA Server with AD FS, it makes sense to publish the MFA User Portal and MFA Mobile Portal through the Web Application Proxies.

A detailed description of the MFA Server components and their traffic flows is available on 4Sysops.com as part of my MFA Server series there.

Pros

The Stretched Deployment scenario offers, as its name suggests, a more secure implementation by separating the database and the web functionality. The traffic between the components can be monitored. Additionally, when there is a security incident with either/both the User Portal and Mobile Portal, its publishing can be disabled, without affecting the core Azure MFA Server functionality. In terms of security, we prefer to enable mutual authentication on the connection between the application and database tier, allowing ONLY connections from the web application.

When you have an IIS-based webserver in a perimeter network, you can reuse that server as the server hosting the MFA User Portal and MFA Mobile Portal.

Cons

The Stretched Deployment scenario does not offer high availability. When the server becomes unavailable, authentication stops. When the database gets mangled, a backup needs to be restored, or a new implementation needs to be performed.

Complete Deployment

In the Complete Deployment scenario, multiple back-end servers and multiple front-end servers work together to offer an highly-available secure deployment of the Azure MFA Server functionality.

Just like in the Redundant Deployment scenario, two or more back-end MFA Servers can be implemented, as part of an MFA Server Group in the Redundant Deployment scenario. This way, replication is established between MFA Servers in the group for the authentication settings and preferences, stored in the PhoneFactor.pfdata database.

Load balancing is utilized for both the webservers running the MFA User Portal and (optionally) MFA Mobile Portal, and the back-end servers running the MFA Web Service SDK. The MFA Server core components themselves and RADIUS authentication do not require load balancers.

Pros

The Complete Deployment offers high-availability. Each MFA Server component may endure a failure in its tier, without it affecting the MFA Server functionality, as long as special care is given to the Master Server placement in combination with Directory Synchronization.

The Complete Deployment offers a secure implementation by separating the database and the web functionality. It is recommended to install the UserPortal and MobilePortal on the same web server. We additionally prefer to implement mutual authentication and monitoring of the connections between the tiers, after allowing only the traffic needed between the components.

The Complete Deployment scenario offers a platform for capacity management, by enabling admins to scale each of the components relatively independent of other components.

The Complete Deployment scenario offers the right implementation strategy to cope with the absence of a true MFA IIS Plug-in.

Cons

The Complete Deployment scenario can be hard to troubleshoot, due to its relative complexity, compared to the other deployment scenarios. It’s also more time-consuming to set up and (way) more costly.

Concluding

Implementing an authentication verification measure, like Microsoft’s on-premises Azure MFA Server, requires some thought to do right.

Choose the right scenario, to meet the requirements of your organization.

Related blogposts

Azure Multi-Factor Authentication features per license and implementation
Choosing the right Azure MFA authentication methods
Azure Multi-Factor Authentication Server version 7.2.0.1 adds Oracle LDAP Support (among other features)

Further reading

Azure Multi-Factor Authentication – Part 1: Introduction and licensing
Azure Multi-Factor Authentication – Part 2: Components and traffic flows
Azure Multi-Factor Authentication – Part 3: Configuring the service and server
Azure Multi-Factor Authentication – Part 4: Portals
Azure Multi-Factor Authentication – Part 5: Settings
Azure Multi-Factor Authentication – Part 6: Onboarding
Azure Multi-Factor Authentication – Part 7: Securing AD FS
Azure Multi-Factor Authentication – Part 8: Delegating Administration