Azure Multi-Factor Authentication – Part 2: Components and traffic flows

• Author
• Recent Posts

Sander Berkouwer

Sander Berkouwer is a Microsoft Certified Professional and a Microsoft Most Valuable Professional (MVP) with over a decade of experience in IT.

Latest posts by Sander Berkouwer (see all)

• Turn the tables on your organization with Adaxes 2018.1’s Web Interface and reporting capabilities - Thu, Sep 20 2018
• Review: Softerra Adaxes – Automating Active Directory management - Thu, Jun 4 2015
• Azure Multi-Factor Authentication – Part 8: Delegating Administration - Tue, Apr 28 2015

Multi-Factor Authentication components

In a typical on-premises implementation of the Multi-Factor Authentication Server, the following components exist.

The first MFA Server

This domain-joined Windows Server installation is equipped with the Azure Multi-Factor Authentication Server software. The default installation location for the Server software is C:\Program Files\Multi-Factor Authentication Server. When it’s the only server in the implementation, it is the master server by default.

The second (and subsequent) MFA Server

It is possible to implement multiple MFA Server installations. MFA Servers exchange information among themselves using RPC. This process is called replication. All servers that replicate must be either domain-joined or all standalone.

The MFA service

Each on-premises MFA Server implementation is activated with the Azure Multi-Factor Authentication service. After successful authentication with the identity provider (for instance, Active Directory), the on-premises MFA Server communicates with the MFA service to perform authentications. The MFA service makes the calls, sends (and receives) text messages, and communicates with activated mobile multi-factor authentication apps. No persistent user data is stored in the cloud. After successful (second) authentication, the MFA service notifies the MFA Server.

The mobile Multi-Factor Auth app

Microsoft has an app called Multi-Factor Auth, which is available in the respective stores of Windows Phone, iOS, and Android. Once installed, the Multi-Factor Auth app can be activated using the portals listed below to verify authentication requests from the MFA service.

The management console

Each Windows Server with the Azure Multi-Factor Authentication Server software installed offers the Multi-Factor Authentication management console. Using this graphical user interface (GUI) tool, admins can configure all aspects of the Azure Multi-Factor Authentication Server software installation, such as importing users, enabling/disabling users, changing users’ properties, installing and uninstalling portals, and managing MFA endpoints.

The management portal

On the Azure side, the Azure Multi-Factor Authentication service can be configured using the management portals. Currently, Azure-related configuration items (such as enabling and disabling users) are managed through the Azure Portal. Authentication configuration (such as the authentication factors to allow and how they need to be used) is managed through the PhoneFactor portal.

The User Portal

The Windows Server with the Azure Multi-Factor Authentication Server software installed can be additionally configured with the MFA User Portal. Through this Internet Information Services (IIS)-based web application, employees can change their phone number(s) and PINs, activate mobile Multi-Factor Auth apps, change their authentication preferences, and bypass multi-factor authentication during their next sign-on. Users will log in to the User Portal using their normal username and password and will either complete an MFA call or answer security questions to complete their authentication.

By default, the User Portal is accessible via the externally resolvable address /MultiFactorAuth">https://<FQDN>/MultiFactorAuth. The User Portal communicates with the MultiFactorAuth service on MFA Servers via the Web Service Software Development Kit (SDK), using HTTPS over TCP port 443 when it is installed on an another Windows Server. It may communicate with the MultiFactorAuth service through RPC when both are located on the same Windows Server installation, but most people prefer the HTTPS approach here.

The Mobile Portal

On the Windows Server with the Azure Multi-Factor Authentication Server software installed, the Mobile Portal can also be installed. This portal supports mobile app activations. Its default externally resolvable address is /MultiFactorAuthMobile">https://<FQDN>/MultiFactorAuthMobile. For PhoneFactor admins, the mobile web app service allows for basic troubleshooting of the app and its connection to the MultiFactorAuth service and the Web Service SDK, using HTTPS over TCP port 443.

The Web Service SDK

For the Mobile Portal to work (and to support the User Portal connecting through HTTPS), the Web Service SDK is needed. You can add this IIS-based web application to the Windows Server running the Azure Multi-Factor Authentication Server software. Its externally resolvable address is /MultiFactorAuthWebServiceSDK">https://<FQDN>/MultiFactorAuthWebServiceSDK. The Web Service SDK listens on TCP port 443.

The MFA Web Service SDK is not limited to the Mobile Portal and User Portal scenarios. It provides an interface for integrating the full features of the Multi-Factor Authentication Server into almost any application.

Multi-Factor Authentication-enabled client devices and adapters

The on-premises MFA Server can offer multi-factor authentication based on a variety of protocols, including RADIUS and LDAP. Through its AD FS Adapter, the MFA Server can also integrate with Active Directory Federation Services, based on the Authentication Extensibility Framework (AEF). This framework has been available since AD FS in Windows Server 2012 R2 (commonly referred to as AD FS 3.0).

Traffic flows

The individual components interact by exchanging network traffic. The traffic flows below depict the scenarios in which the components work together.

Using the User and/or Mobile Portal

Traffic flow with the User and Mobile Portals

When an employee uses the User and/or Mobile Portal on the Multi-Factor Authentication Server, the portal connects to the corresponding web application within IIS using HTTPS (1). When configured, IIS logs the visit. The web application then communicates with the MultiFactorAuth service through the Web Service SDK web application (2) (3), again using HTTPS. Authentication for the portal with the Web Service SDK is based on basic authentication settings defined in the web.config file of the portals.

Performing an authentication

The multi-factor authentication process

When an employee authenticates to a resource that requires multi-factor authentication (1), the authentication request is passed to the on-premises MFA Server (2). After successful authentication to the identity provider (3, 4), the MFA Server connects to the MFA service using TCP port 443 (5). The MFA service takes care of the authentication using the preferred method (6, 7), logs the activity, and, when successful, notifies the on-premises MFA Server to pass authentication (8). The MFA Server logs the activity (by default, in C:\Program Files\Multi-Factor Authentication Server\Logs) and passes the relative authentication package(s) to the client devices or adapter (9).

In these last two posts, I introduced the most important multi-factor authentication concepts. In the next installment of this series, I will explain how to install the MFA Server and configure the MFA service.