Leverage Azure MFA Server with AD FS in Windows Server 2012 R2

Introduction

Today many organizations use on-premises multi-factor authentication systems to protect mission critical data in their file servers and their critical Line of Business (LOB) applications. As these workloads (or parts of them) move to the cloud, they need an effective and easy-to-use solution in the Cloud for protecting:

  • That data in the Microsoft services, such Office 365 and Dynamics 365, or other Software-as-a-Service (SaaS) they've subscribed to,
  • The custom cloud-based Line of Business (LOB) applications – on Azure or in other clouds -,
  • And the modern business applications they've created. 

Passwords in use that are often not enough strong and the consumerization of IT has only even increased the scope of vulnerability.

Multi-factor authentication is becoming the new standard for securing access and how businesses ensure trust in a multi-device, mobile, cloud world.

Note    Not only do the above organizations need multi-factor authentication for their employees, but many of them are also increasingly opening their environment to their partners as part of their business-to-business relationships (B2B), and building cloud-based applications for consumers and citizens that require multi-factor authentication to ensure a high level of security.  These business-to-business B2C scenarios are growing rapidly and require easy end-user technology.

Furthermore, multi-factor authentication is no longer optional for many of the above organizations; many are required by various governing or regulatory agencies to strongly authenticate access to sensitive data and applications across a broad range of industries.

In such a landscape, phone-based authentication constitutes a very compelling technical approach for multi-factor authentication as it provides enhanced security for businesses and consumers in a convenient form factor that the user already has: their phone.

Azure Multi-Factor Authentication (Azure MFA) addresses user demand for a simple sign-in process while also helping address the organization's security and compliance standards. The service offers enhanced protection from malware threats, and real-time alerts notify your IT department of potentially compromised account credentials.

Azure MFA helps to deliver strong security via a range of easy authentication options. Thus, in addition to entering a username and password during sign in, enabled users are also required to authenticate with a mobile app on their mobile device or via an automated phone call or a text message, allowing these users to choose the method that works best for them. Consequently, in order for an attacker to gain access to a user's account, they would need to know the user's login credentials AND be in possession of the user's phone. Furthermore, support for the above multiple methods enables to support more scenarios such as offline (no carrier) scenarios.

Azure MFA exists in different flavors:

  • Azure MFA stand-alone.
  • Included in Azure AD Premium P1 and Premium P2 editions.
  • A subset of Azure MFA functionality included in Office 365 for both administrators and users.
  • Free for Azure administrators.

Whilst Azure MFA is powered by a cloud service, the stand-alone version and well as the one included in Azure AD Premium support on-premises, cloud, and hybrid scenarios. The following solutions are indeed available for use with Azure MFA:

  • Adding Multi-Factor Authentication to Azure AD. Azure MFA works with any applications that use the Azure AD directory tenants. As such, Azure MFA can be rapidly enabled for Azure AD identities to help secure access:
    • The Azure portal,
    • Microsoft Online Services like Office 365, Intune, and Dynamics 365, etc.
    • Any custom LOB, third-party multi-tenant cloud-based, or modern business applications that integrate with Azure AD for authentication,
    • As well as thousands (2797 at the time of this writing) of cloud SaaS pre-integrated applications like ADP, Concur, Google Apps, Salesforce.com and others.

    Users will be prompted to set up additional verification the next time they sign in.

Note     For more information, see article Getting started with Azure Multi-Factor Authentication in the cloud.

The white-paper Leverage Multi-Factor Authentication with Azure AD describes how to enable, configure, and use Azure MFA with such cloud users in Azure AD for securing resource access in the Cloud.

  • Enabling Multi-Factor Authentication for on-premises applications and Windows Server. The Azure Multi-Factor Authentication Server (Azure MFA Server) works out-of-the-box with a wide range of on-premises applications, such as remote access VPNs, web applications, virtual desktops, single sign-on systems and much more. This includes:
    • Microsoft products and technologies like Microsoft VPN/RRAS, Remote Desktop Services and Remote Desktop Gateway, Universal Access Gateway, SharePoint, Outlook Web Access, etc.
    • As well as third party VPNs and virtual desktop system.

The Azure MFA Server allows the administrator integrate with IIS authentication to secure Microsoft IIS web applications, RADIUS authentication, LDAP authentication, and Windows authentication.

The Azure MFA Server can be run on-premises on your existing hardware - as a virtual machine (VM) or not -, or in the cloud for instance as an Azure Virtual Machine. Multiple, redundant servers can be configured for high availability and fail-over.

Note    For more information, see article Getting started with the Azure Multi-Factor Authentication Server.

  • Building Multi-Factor Authentication into custom applications. A Software Development Kit (SDK) is available for use for direct integration with custom cloud-based and on-premises applications. It enables to build Multi-Factor Authentication phone call and text message verification into the application's sign-in or transaction processes and leverage the application's existing user database.

Note    For more information, see article Building Multi-Factor Authentication into Custom Apps (SDK).

Objectives of this paper

As an addition to the aforementioned white-paper Leverage Azure Multi-Factor Authentication with Azure AD, and for an organization that is federated with Azure AD, this paper aims at describing how to use Azure MFA Server with Active Directory Federation Services (AD FS) in Windows Server 2012 R2, and how to configure it to secure cloud resources such as Office 365 and Dynamics 365 so that so that federated users will be prompted to set up additional verification the next time they sign in on-premises.

Important note    Integration between Azure MFA and AD FS in Windows Server 2016 doesn't require the on-premises Azure MFA Server components. In Windows Server 2016, the Azure MFA adapter rather integrates directly with Azure AD for all the MFA configuration. For more information, see article Configure AD FS 2016 and Azure MFA.

Such a scenario typically complements the directory synchronization with single sign-on (SSO), a.k.a. identity federation scenario that can be achieved with the Azure AD Connect tool, and which aims at providing users with the one of the supported seamless sign-in experiences as they access Microsoft cloud services and/or other cloud-based applications while logged on to the corporate network.

Note    For more information, see whitepaper Azure AD/Office seamless sign-in.

This integration implies to configure the Azure MFA Server components to work with AD FS in Windows Server 2012 R2 so that multi-factor authentication is triggered on-premises, or in an Infrastructure-as-a-Service (IaaS) cloud environment such as Azure as per White paper: Office 365 Adapter - Deploying Office 365 single sign-on using Azure Virtual Machines.

Note    Such an integration is natively supported by AD FS in Windows Server 2012. For more information, see articles Getting started with Azure Multi-Factor Authentication and Active Directory Federation Services and Secure your cloud and on-premises resources using Azure Multi-Factor Authentication Server with AD FS in Windows Server 2012 R2.

Beyond this integration, this scenario additionally implies directory synchronization between the on-premises identity infrastructure (based on Windows Server Active Directory (AD) or on other (LDAP-based) directories) and the Azure MFA Server to streamline user management and automated provisioning.

This also supposes to deploy:

  • The on-premises Azure MFA Server user portal, which allows users to enroll in multi-factor authentication and maintain their accounts.
  • And optionally the Azure MFA Server mobile app web service, which is used in the Microsoft Authenticator mobile app activation process. The Microsoft Authenticator app offers an additional out-of-band authentication option.

Note     For more information, see article Microsoft Authenticator.

With all of the above, the enrolled federated users can use their on-premises corporate credentials (user name and password) and their existing phone for additional authentication to access Azure AD and any cloud-based application that is integrated into Azure AD as well as their existing on-premises resources.

Important note     With the Azure MFA Server integration, only web browser based clients and Office clients that support modern authentication are supported. For clients that are not support such as legacy Office clients, Exchange active sync (i.e. native email clients on mobile devices), customers are encouraged to use the modern authentication equivalent.

Built on existing Microsoft documentation and knowledge base articles, this document provides a complete walkthrough to build a suitable test lab environment in Azure, test, and evaluate the above scenario. It provides additional guidance if any.

Note    For more information, see article Using Multi-Factor Authentication with Azure AD.

Non-objectives of this paper

This document doesn't introduce Azure MFA. Such a presentation is provided in the aforementioned whitepaper Leverage Azure Multi-Factor Authentication with Azure AD.

This document doesn't discuss either how to configure Azure MFA for cloud identities in Azure AD to secure cloud-based resources. This scenario is also covered in detail in the above whitepaper. This document doesn't describe either how to configure the advanced settings and reports of the service. All of these are also covered in the above whitepaper. For more information, please refer to it.

As already mentioned, the Azure MFA Server also works out-of-the-box with a wide range of on-premises applications, such as remote access VPNs, web applications, virtual desktops, single sign-on systems and much more. Those scenarios are not discussed in this document.

Note    For more information, see links in section § Next steps of the article Getting started with the Azure Multi-Factor Authentication Server.

Organization of this paper

To cover the aforementioned objectives, this document is organized in the following two sections:

  • Building a test lab environment.
  • Testing and evaluating the Azure MFA Server.

These sections provide the information details necessary to (hopefully) successfully build a working environment for the Azure MFA Server. They must be followed in order.

About the audience

This document is intended for system architects and IT professionals who are interested in understanding how to enable and configure the Azure MFA Server for Azure AD federated users to help secure access to cloud resources such as Office 365.

Building a test lab environment

As its title suggests, this section guides you through a set of instructions required to build a representative test lab environment that will be used in the next section to configure, test, and evaluate the multi-factor authentication in AD FS in Windows Server 2012 R2.

Considering the involved services, products, and technologies that encompass such a cross-premises configuration, the test configuration should feature:

  • In the cloud, an Azure AD/Office 365 tenant, and cloud-based applications that leverage Azure AD for identity management and access control,
  • In the on-premises, Windows Server Active Directory, Active Directory Certificate Services (AD CS), Active Directory Federation Services (AD FS), and Internet Information Services (IIS), to name a few - and the related required configuration.

The following diagram provides an overview of the overall test lab environment with the software and service components that need to be deployed / configured.

We have tried to streamline and to ease as much as possible the way to build a suitable test lab environment, to consequently reduce the number of instructions that tell you what servers to create, how to configure the operating systems and core platform services, and how to install and configure the required core services, products and technologies, and, at the end, to reduce the overall effort that is needed for such an environment.

We hope that the provided experience will enable you to see all of the components and the configuration steps both on-premises and in the cloud that go into such a multi-products and services solution.

Creating an Azure AD/Office 365 test tenant

The easiest way to provision both an Azure AD/Microsoft Office 365 Enterprise tenant and related Office application workloads for the purpose of the test lab certainly consists in signing up to a free 30-day trial. To sign-up for such a tenant, follow the instructions at https://go.microsoft.com/fwlink/p/?LinkID=403802&culture=en-US&country=US.

For the course of this walkthrough, we've provisioned an Office 365 Enterprise (E3) tenant: litware369.onmicrosoft.com. You will have to choose in lieu of a tenant domain name of your choice whose name is currently not in used. Whenever a reference to litware369.onmicrosoft.com is made in a procedure, it has to be replaced by the tenant domain name of your choice to reflect accordingly the change in naming.

Building the "on-premises" test lab environment

A challenge in creating a useful on-premises test lab environment is to enable their reusability and extensibility. Because creating a test lab can represent a significant investment of time and resources, your ability to reuse and extend the work required to create the test lab is important. An ideal test lab environment would enable you to create a basic lab configuration, save that configuration, and then build out multiple test lab scenarios in the future by starting with the base configuration.

Moreover, another challenge people is usually facing with relates to the hardware configuration needed to run such a base configuration that involves several (virtual) machines.

For these reasons and considering the above objectives, this document will leverage the Microsoft Azure environment along with the Azure PowerShell cmdlets to build the on-premises test lab environment to test and evaluate Multi-Factor Authentication Server.

Signing up for an Azure trial

If you do not already have an Azure account, you can sign up for a free one-month trial.

Note    If you have an MSDN Subscription, see article Azure benefit for MSDN subscribers.

Note    Once you have completed your trial tenant signup, you will be redirected to the Azure account portal
and can proceed to the Azure portal by clicking Portal at the top right corner of your screen.

Adding the Azure trial to the Office 365 account

Once you have signed up and established your organization with an account in Office 365 Enterprise E3, you can then add an Azure trial subscription to your Office 365 account. This can be achieved by accessing the Azure Sign Up page at https://account.windowsazure.com/SignUp with your Office 365 global administrator account. You need to select Sign in with your organizational account for that purpose.

Note    You can log into the Office 365 administrator portal and go to the Azure Signup page or go directly to the signup page, select sign in with an organizational account and log in with your Office 365 global administrator credentials.
Once you have completed your trial tenant signup you will be redirected to the Azure account portal and can proceed to the Azure portal by clicking Portal at the top right corner of your screen.

At this stage, you should have an Office 365 Enterprise E3 trial subscription with an Azure trial subscription.

Setting up the Azure-based lab environment

The Part 4 or Part 4bis of the whitepaper Azure AD/Office 365 Seamless Sign-In fully depict the setup of such an environment.

In order not to "reinvent the wheels", this document leverages the instrumented end-to-end walkthrough provided in the above whitepaper to rollout a working single sign-on configuration for Azure AD/Office 365 with AD FS by featuring the Azure AD Connect tool.

Note    Azure AD Connect
provides a single and unified wizard that streamlines the overall onboarding process for directory synchronization (single or multiple directories), password sync and/or single sign-on, and that automatically performs the following steps: download and setup of all the prerequisites, download, setup and guided configuration of the synchronization, activation of the sync in the Azure AD tenant, setup, and/or configuration of AD FS – AD FS being the preferred STS, etc. Azure AD Connect is the one stop shop for connecting your on-premises directories to Azure AD, whether you are evaluating, piloting, or in production.

For more information, see blog post Azure AD Connect & Connect Health is now GA!, and article Connect Active Directory with Azure Active Directory.

By following the instructions outlined in this whitepaper along with the provided Azure/Windows PowerShell scripts, you should be able to successfully prepare your Azure-based lab environment based on virtual machines (VMs) running in Azure to later deploy and configure the Azure MFA Server environment, install and configure it with AD FS in Windows Server 2012 R2, etc. and start evaluating/using it.

Important note    Individual virtual machines (VMs) are needed to separate the services provided on the network and to clearly show the desired functionality. This being said, the suggested configuration to later evaluate the Azure MFA Server is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab networking environment.

Any modifications that you make to the configuration details provided in the rest of this document may affect or limit your chances of successfully setting up the on-premises collaboration environment that will serve as the basis for the integration with the Azure MFA service in the Cloud.

Microsoft has successfully built the suggested environment with Azure IaaS, and Windows Server 2012 R2 virtual machines.

Once completed the aforementioned whitepaper's walkthrough, you'll have in place an environment with a federated domain in the Azure AD tenant (e.g. litware369.onmicrosoft.com), the whitepaper has opted to configure the domain litware369.com (LITWARE369). You will have to choose in lieu of a domain name of your choice whose DNS domain name is currently not in used on the Internet. For checking purpose, you can for instance use the domain search capability provided by several popular domain name registrars.

Whenever a reference to litware369.com is made in a procedure later in this document, it has to be replaced by the DNS domain name of your choice to reflect accordingly the change in naming. Likewise, any reference to LITWARE369 should be substituted by the NETBIOS domain name of your choice.

The Azure-based test lab infrastructure consists of the following components:

  • Two computers running Windows Server 2012 R2 (or Windows Server 2016) (named DC1 respectively DC2 by default) that will be configured as a domain controller with a test user and group accounts, and Domain Name System (DNS) servers. DC1 will host Azure AD Connect for the sync between the Azure-based test lab infrastructure and the Azure AD/Office 365 subscription. Alternatively, DC2 will be configured as an enterprise root certification authority (PKI server),
  • Two intranet member server running Windows Server 2012 R2 (or Windows Server 2016) (named ADFS1 respectively ADFS2 by default) that will be configured as an AD FS farm.
  • Two Internet-facing member server running Windows Server 2012 R2 (or Windows Server 2016) (named WAP1 respectively WAP2 by default) that is configured as Web servers for the Web Application Proxy (WAP) farm.

Note     Windows Server 2012 R2 offers businesses and hosting providers a scalable, dynamic, and multitenant-aware infrastructure that is optimized for the cloud. For more information, see the Microsoft TechNet Windows Server 2012 R2 homepage.

For the sake of simplicity, the same password "Pass@word1!?" is used throughout the configuration. This is neither mandatory nor recommended in a real world scenario.

To perform all the tasks in this guide, we will use the LITWARE369 domain Administrator account AzureAdmin for each Windows Server 2012 R2 VM, unless instructed otherwise.

The base configuration should now be completed at this stage if you've followed the whitepaper's walkthrough.

To avoid spending your credit when you don't work on the test lab, you can shut down the 6 VMs (DC1, DC2, ADFS1, ADFS2, WAP1 and WAP2) when you don't work on the test lab.

To shut down the VMs of the test lab environment, proceed with the following steps:

  1. Open a browsing session and navigate to the Azure portal at https://portal.azure.com.
  2. Sign in with your administrative credentials to your Azure subscription in which you've deployed the test lab environment.
  3. On the left pane of the Azure portal, click virtual machines.

  1. On the virtual machine page, select wap1. A new blade opens up.

  1. Click Stop. A dialog pops up.
  2. Click Yes to confirm the shutdown.
  3. Repeat steps 4 to 6 with wap2, adfs2, adfs1, dc2, and then dc1.

To resume working on the test lab environment, you will then need to start the six VMs that constitute it.

To start the VMs of the test lab environment, proceed with the following steps:

  1. From the Azure portal, click virtual machines.
  2. On the virtual machine page, select dc1. A new blade opens up.
  3. Click Start.

  1. Repeat steps 2 to 3 with dc2, adfs1, adfs2, wap1, and then wap2.

Note    for more information, see article Manage virtual machines using Azure Resource Manager and PowerShell.

You are now in a position to install and configure the Azure MFA Server environment on your on-premises test lab environment.

Testing and evaluating the Azure MFA Server

This walkthrough provides instructions for configuring multi-factor authentication in AD FS in Windows Server 2012 R2. It is based on the "on-premises" test lab environment deployed in Azure as per previous section.

Note    For the purpose of this document, it leverages the existing walkthrough as part of the article Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications, adapt it to the Office 365 context in lieu of the sample application ClaimApp, and extend it to illustrate the deployment of additional Azure MFA components, namely the Users portal, the SDK, and the Mobile Application web service.
For more information, see article.

It consists in the following seven steps that must be followed in order:

  1. Creating an Azure MFA provider.
  2. Downloading the Azure MFA Server on the AD FS farm.
  3. Installing the Azure MFA Server on the AD FS farm.
  4. Configuring multi-factor authentication on the AD FS farm.
  5. Installing the Multi-Factor Authentication SDK on the AD FS farm (optional).
  6. Deploying the Azure MFA Server user portal on the WAP farm (optional).
  7. Deploying the Azure MFA Server mobile app web service on the WAP farm (optional).

The following subsections describe in the context of our test lab environment each of these steps.

Creating an Azure MFA provider

To create an Azure MFA provider via the classic Azure portal, proceed with the following steps:

  1. Open a browsing session from your local machine and navigate to the classic Azure portal at https://manage.windowsazure.com.
  2. Sign in with your administrative credentials.
  3. On the left pane of the Azure portal, click ACTIVE DIRECTORY.
  4. On the active directory page, at the top, click MULTI-FACTOR AUTH PROVIDERS.

  • Click CREATE A NEW MULTI-FACTOR AUTHENTICATION PROVIDER or click NEW in the tray at the bottom, and then select APP SERVICES, ACTIVE DIRECTORY, MULTI-FACTOR AUTH PROVIDER, and then QUICK CREATE.

  • Fill in the following fields and click CREATE.
    • Name. The name of the Azure MFA provider, for example "Litware369 Auth".
    • Usage Model. The usage model of the Azure MFA provider.
      • Per Authentication. This purchasing model charges per authentication, and is typically used for scenarios that use Azure MFA in a consumer-facing application.
      • Per Enabled User. This purchasing model charges per enabled user, and is typically used for employee-facing scenarios.

Note    For more information on usage model, see Multi-Factor Authentication Pricing Details.

  • Directory. The Azure AD tenant that the Azure MFA provider is associated with. This is optional as the provider does not have to be linked to Azure AD when securing on-premises resources. Ensure Do not link a directory is selected.
  • Once you click CREATE, the Azure MFA provider will be created and you should see a message stating: "Successfully created Multi-Factor Authentication Provider". Click OK.

Note    For more information, see article Getting started with Azure Multi-Factor Authentication in the cloud.

Next, you must download the Azure MFA Server. You can do this by launching the Azure MFA portal through the Azure portal.

Downloading the Azure MFA Server on the AD FS farm

The instructions below should be done on the ADFS1 and the ADFS2 computers.

To download the Azure MFA Server on the AD FS farm, proceed with the following steps:

  1. Open a remote desktop connection as LITWARE369\AzureAdmin on the ADFS1 computer.
  2. Open a browsing session and navigate to the Azure portal at https://manage.windowsazure.com.
  3. Sign in with your administrative credentials.
  4. On the left pane of the Azure portal, click ACTIVE DIRECTORY.
  5. On the active directory page, at the top, click MULTI-FACTOR AUTH PROVIDERS.

  1. Click on the Azure MFA provider you've just created in the section above. Then click MANAGE at the tray of the bottom. This launches the Azure Multi-Factor Authentication portal at https://pfweb.phonefactor.net/framefactory.


  1. Click Server under DOWNLOADS. You navigate to a Downloads Server page.

  1. Click Download to download the setup file (MultiFactorAuthenticationServerSetup.exe) for Azure MFA Server.

  1. Click Save to save the setup file.
  2. Open a remote desktop connection as LITWARE369\AzureAdmin on the ADFS2 computer.
  3. Repeat step 2 to 9.

Note    For more information, see article Getting started with the Azure Multi-Factor Authentication Server.

You are now ready to install the above setup file for Azure MFA Server on the ADFS1 and ADFS2 computers.

Installing the Azure MFA Server on the AD FS farm

The instructions below should be done on the ADFS1 and ADFS2 computers as instructed.

Installing the Azure MFA Server on the AD FS farm

To install the Azure MFA on the AD FS farm, proceed with the following steps:

  • Whilst still being remotely logged on the ADFS1 computer as LITWARE369\AzureAdmin, double-click the downloaded setup file (MultiFactorAuthenticationServerSetup.exe) to begin the installation.


Note     For more information, see article Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update: April 2014.

Click OK to proceed. A new dialog invites you to install Visual C++ runtime libraries updates.

  • Click Install and proceed with the installation.
  • A Multi-factor Authentication Server setup wizard eventually brings up.

  • Ensure that the destination folder is correct and click Next.

  • Once the installation complete, click Finish. As indicated, this launches the Multi-Factor
    Authentication Server Authentication Configuration wizard to configure it. This will be the topic of the next section.
  • Open a remote desktop connection as LITWARE369\AzureAdmin on the ADFS2 computer.
  • Repeat step 1 to 9 on the ADFS2 computer.

You are now ready to configure the Azure MFA Server agent as an additional authentication method in AD FS in Windows Server 2012 R2 for the course of this walkthrough.

Configuring multi-factor authentication on the AD FS farm

The configuration of multi-factor authentication in AD FS in Windows Server 2012 R2 consists in:

  • Configuring Azure MFA Server on the primary federation server.
  • Configuring Azure MFA Server on the secondary federation server.
  • Setting up the multi-factor authentication policy.
  • Setting the MFA default behavior (Optional).
  • Verifying the multi-factor authentication mechanism.

Configuring Azure MFA Server on the primary federation server

Unless noticed otherwise, all the instructions below should be done on the ADFS1 computer.

To configure Azure MFA Server on the ADFS1 computer, proceed with the following steps:

  • The completion of the installation of the Azure MFA Server launches the Multi-Factor
    Authentication Server Authentication Configuration wizard.

  • On the Welcome page, check Skip using the Authentication Configuration Wizard, and click Next. This closes the wizard as expected and the Multi-Factor Authentication Server user interface (MultiFactorAuthUI) brings up.

  • To activate the Azure MFA Server, go back to the Downloads Server page in the Azure MFA portal where you've downloaded the setup file for the Azure MFA Server and click Generate Activation Credentials. Credentials valid for 10 minutes are then displayed underneath.

  • Back in the Azure MFA Server user interface, enter the credentials that were generated and click Activate. A Join Group dialog appears.

  • Click OK. Next, the Multi-Factor Authentication Server user interface prompts you to run the Multi-Server Configuration Wizard.

  • Select Yes. Since the test lab environment contains a farm of two federation servers, you must install the Azure MFA Server and complete the Multi-Server Configuration Wizard on each federation server in order to enable replication between the Azure MFA servers running on your AD FS servers.

  • Click Next.

  • Leave Active Directory and Certificates selected, and then click Next.

  • Leave all the options selected, and then click Next.

Note     The Multi-Server Configuration wizard will create a security group called PhoneFactor Admins in litware369.com AD and then adds the ADFS1 computer account and AzureAdmin global administrator to this group.

It is recommended that you verify on your domain controller that the PhoneFactor Admins group is indeed created and that the above accounts are members of this group. If necessary, add these accounts to the PhoneFactor Admins group on your domain controller manually. For more details on installing the AD FS Adapter, click the Help link in the top right corner of the Azure MFA Server.

  • Click Next.

  • Click Finish. The ADFS1 computer restarts.
  • Once the reboot completes, launch Multi-Factor Authentication Server (MultiFactorAuthUI.exe). The file is located under C:\Program Files\Multi-Factor Authentication Server.

    A Multi-Factor Authentication Server opens.

  • In the Multi-Factor Authentication Server user interface, select Company Settings and set your options, most of these you will leave as the default.

You can see in User defaults the support for a variety of options like phone call, one-way text message with One Time Passwords (OTPs), two-way text messaging, mobile app, third-party OATH token, etc.

  • Now select Users on the left pane.

  • Click Import from Active Directory. An Import from Active Directory window brings up.

  • Expand litware369.com, and then select Users underneath.
  • Select the Robert Hatley test account to provision it in Azure MFA, and then click Import. An Import from Active Directory dialog brings up.

  • Click OK, and then click Close.
  • Back in the Users list, select the Robert Hatley test account, and click Edit. An Edit User window brings up.

  • Select the appropriate country code in Country Code and provide a cell phone number of this account in Phone, make sure Enabled is checked, click Apply, and then Close.
  • Back in the Users list, select the Robert Hatley test account, and click Test. A Test User dialog brings up.

  • Provide the credentials (e.g. "Pass@word1!?") for the Robert Hatley test account and click Test. When the cell phone rings, press "#" to complete the account verification. An information dialog confirms the successful authentication.

  • Click OK and click Close.
  • Back in the Multi-Factor Authentication Server user interface, select the AD FS icon.

  • Make sure that Allow user enrollment, Allow users to select method (including Phone call, Text message, and Mobile app), Use security questions for fallback and Enable logging are checked, click Install AD FS Adapter. An Install ADFS Adapter installation wizard brings up.

  • In the Active Directory page, click Next.

  • In the Launch installer page, click Next. A Multi-Factor Authentication ADFS Adapter installation wizard brings up.

  • Click Next.

  • In the Installation Complete page, click Close.
  • To register the adapter in the federation service on the ADFS1 computer, open a Windows PowerShell command prompt, and run the following commands:

PS C:\> cd "C:\Program Files\Multi-Factor Authentication Server"
PS C:\> .\Register-MultiFactorAuthenticationAdfsAdapter.ps1
WARNING: PS0114: The authentication provider was successfully registered with the policy store. To enable this
provider, you must restart the AD FS Windows Service on each server in the farm.
PS C:\>

The adapter is now registered as WindowsAzureMultiFactorAuthentication (see below).  As indicated, you must restart the AD FS service (adfssrv) for the registration to take effect.

  • Run the following command to restart the:

PS C:\> Restart-Service adfssrv
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to stop...
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to stop...
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to stop...
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to stop...
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to start...
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to start...
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to start...
PS C:\>

  • Close the Windows PowerShell command prompt and launch the AD FS Management console from the Tools menu of the Server Manager to finally configure Azure MFA as the additional authentication method.

  • Navigate to the Authentication Policies node, scroll down in the middle pane to the Multi-factor Authentication section.

  • Click Edit next to the Global Settings sub-section. An Edit Global Authentication Policy window brings up.

  • Select Azure Multi-factor Authentication Server as an additional authentication method, and then click OK.

Note    You can customize the name and description of the Azure MFA method, as well as any configured third-party authentication method, as it appears in your AD FS UI, by running the Set-AdfsAuthenticationProviderWebContent cmdlet.
For more information, see article Set-AdfsAuthenticationProviderWebContent.

Configuring Azure MFA Server on the secondary federation server

To configure Azure MFA Server on the ADFS2 computer, proceed with the following steps:

  • Repeat steps 1 to 6 of the previous section on the ADFS2 computer. The Multi-Server Configuration Wizard opens.

  • Complete it on the ADFS2 computer in order to enable replication between the Azure MFA servers running on your AD FS servers.
  • Restart the ADFS2 computer when invited to do so.
  • Once the reboot completes, launch Multi-Factor Authentication Server (MultiFactorAuthUI.exe). The file is located under C:\Program Files\Multi-Factor Authentication Server.

    The following dialog may bring up.

  • Click Yes.
  • Once the reboot completes, relaunch Multi-Factor Authentication Server.

The ADFS1 and ADFS2 computes should be both listed as illustrated above.

Setting up the multi-factor authentication policy

To set up the multi-factor authentication policy, proceed with the following steps on the ADFS1 computer:

  • Open an elevated Windows PowerShell command prompt and run the following command to retrieve the Office 365 relying party:

PS C:\> $rp = Get-AdfsRelyingPartyTrust –Name "Microsoft Office 365 Identity Platform"

  • Run the following command to specify the claim rule:

PS C:\> $groupMfaClaimTriggerRule = 'c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i) S-1-5-21-2309203066-2729394637-456832893-3109$"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");'

  • Run the following command to set the claim rule on the Office 365 relying party:

PS C:\> Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules $groupMfaClaimTriggerRule

Note    Make sure to replace S-1-5-21-2766110245-3868540559-1908332702-2111 with the value of the SID of your AD group Finance.

Setting the MFA default behavior (Optional)

The default multi-factor authentication behavior for federated Azure AD/Office 365 tenants is set to occur in the cloud where in the past it was set to occur on-premises.

You can affect this behavior by downloading latest version of the Azure AD PowerShell V1 module tool (e.g. version 1.1.166.0 as of this writing), a.k.a. the Microsoft Online (MSOL) library, and running the below commands.

Note    The Azure AD PowerShell V1 module is regularly updated with new features and functionality. The above link should always point to the most current version of the module. For more information, see the Microsoft Wiki article Microsoft Azure Active Directory PowerShell Module Version Release History.

Important note    The Azure AD PowerShell V1 module is going to be progressively replaced by the Active Directory V2 PowerShell module currently in public preview. For more information, see blog post In case you missed it: #AzureAD PowerShell v2.0 is now in public preview! and eponym article Azure Active Directory V2 PowerShell module.

To perform multi-factor authentication on-premises for litware369.com, run the following command on the ADFS1 computer:

PS C:\> Set-MsolDomainFederationSettings -DomainName litware369.com -SupportsMFA $true

Where SupportsMFA as true means that Azure AD will redirected the user to AD FS for multi-factor authentication if multi-factor authentication is required and a claim of type "http://schemas.microsoft.com/claims/authnmethodsreferences" with the value "http://schemas.microsoft.com/claims/multipleauthn", which is so-called the MFA claim, is missing.

To perform multi-factor authentication in the cloud for litware369.com, run the following command:

PS C:\> Set-MsolDomainFederationSettings -DomainName litware369.com -SupportsMFA $false

Where SupportsMFA as false means that Azure AD does multi-factor authentication natively (again assuming multi-factor authentication is required and MFA claim is missing). If flag is not set, it is assumed to be false. Users won't be double MFA'd. If multi-factor authentication was already done at AD FS as part of login, the MFA claim will be present and Azure AD won't ask for multi-factor authentication again.

Note     For more information, see article Getting started with Azure Multi-Factor Authentication and Active Directory Federation Services.

Verifying the multi-factor authentication mechanism

To verify the multi-factor authentication policy, proceed with the following steps:

  1. Close the current remote desktop connection if any on the Internet-facing WAP1 computer and open a new one as LITWARE369\RobertH with "Pass@word1!?" as password.
  2. Open a browsing session and add https://adfs.litware369.com to the Local Intranet zone.
  3. Navigate to the Office 365 portal at https://portal.office.com.


  1. Log on with the Robert Hatley test account credentials:

Username: roberth@litware369.com

You should be automatically redirected to the ADFS farm. At this point, after a successful seamless authentication with your local user credentials (thanks to the Windows Integrated Authentication), you are prompted to undergo additional authentication because of the previously configured multi-factor authentication policy.

  1. When the cell phone rings, press "#" to complete the account verification.
  2. You are then redirected back to the portal after a successful authentication with both your local user credentials (thanks to the Windows Integrated Authentication (WIA)) and the multi-factor authentication. At the end of the process, you should have a seamless access to the signed in user settings in Office 365.

At this stage, you have successfully deployed the Azure MFA Server in your environment.

You can optionally deploy the Azure MFA Server user portal and the Azure MFA server mobile app Web service.

The Azure MFA Server user portal is an Internet Information Services (IIS) web site which allows on-premises users to enroll in Azure MFA and maintain their on-premises accounts. A user may change their phone number, change their PIN, or bypass Azure MFA during their next sign on.

Users will log in to the Azure MFA Server user portal using their normal on-premises username and password and will either complete an Azure MFA call or answer security questions to complete the authentication. If user enrollment is allowed, a user will configure their phone number and PIN the first time they log in to the Azure MFA Server user portal.

The corporate administrators may be set up and granted permission to add new users and update existing users.

The Azure MFA Server mobile app web service enable the users to install the Microsoft Authenticator app on their smartphone from the Azure MFA Server user portal.

In our configuration, this supposes to first install the Multi-Factor Authentication SDK.

Installing the Multi-Factor Authentication SDK on the AD FS farm (optional)

The installation of the Multi-Factor Authentication SDK consists in:

  • Installing the Multi-Factor Authentication SDK on the primary federation server.
  • Installing the Multi-Factor Authentication SDK on the secondary federation server.
  • Testing the Multi-Factor Authentication SDK configuration.

Installing the Multi-Factor Authentication SDK on the primary federation server

All the instructions should be done on the ADFS1 computer.

Installing the prerequisites

To install the Web Server (IIS) service role, proceed with the following steps:

  • Open a remote desktop connection on ADFS1 if needed and log on as LITWARE369\AzureAdmin.
  • Launch Server Manager.
  • Click Manage, and then select Add Roles and Features. An eponym wizard opens.

  • Click Next.

  • Leave Role-based or feature-based installation selected, and click Next.

  • Click Next.

  • Under Web Server (IIS), select ASP.NET 4.5 under Application Development, IIS 6 Metabase Compatibility under Management Tools, and Basic Authentication under Security. Accept the installation of all the depedencies.
  • Click Next, and then proceed with the installation.

Once complete, you can then install the Multi-Factor Authentication SDK

Installing the Multi-Factor Authentication SDK

To install the Multi-Factor Authentication SDK, proceed with the following steps:

  • Open the Multi-Factor Authentication Server.
  • Click the Web Service SDK icon.

  • Click Install Web Service SDK. An Multi-Factor Authentication Web Service SDK installation wizard brings up. If the above prerequisites are satisfied, the Select Installation Address page is displayed.

  • Click Next.

  • Click Close.

The Web Service SDK (PfWsSdk) is configured to be secured with an SSL certificate. We thus need to configure HTTPS on the default web site. We already issued an adfs.litware369.com SSL certificate for the AD FS configuration.

Configuring HTTPS on the default web site

To configure HTTPS on the default web site, proceed with the following steps:

  • Open an elevated Windows PowerShell command prompt if none, and run the following command to add a SSL binding to the default web Site:

PS C:\> New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https

  • Run the following commands to associate the already issued adfs.litware369.com SSL certificate to the newly created SSL binding:

PS C:\> Get-ChildItem cert:\LocalMachine\MY | where { $_.Subject -match "CN\=adfs.litware369.com" } | select -First 1 | New-Item IIS:\SslBindings\0.0.0.0!443

IP Address Port Host Name Store Sites
---------- ---- --------- ----- -----
0.0.0.0 443 MY Default Web Site

PS C:\Users\AzureAdmin.LITWARE369>

Installing the Multi-Factor Authentication SDK on the secondary federation server

Repeat all the steps outlined in section § Installing the Multi-Factor Authentication SDK on the primary federation server on the ADFS2 computer.

Testing the Multi-Factor Authentication SDK configuration

To test the Multi-Factor Authentication SDK configuration, proceed with the following steps:

  • Provide the credentials for the LITWARE369\AzureAdmin administrator account such as:

Username: AzureAdmin

Password: Pass@word1!?

  • Click OK. The collection of operations supported by the Web Service SDK (PfWsSdk) should now be listed in the .asmx page.

Deploying the Azure MFA Server user portal on the WAP farm (optional)

The deployment of the Azure MFA Server user portal on the WAP farm consists in installing and configuring it on the two servers of the farm.

Installing the Azure MFA Server user portal on the first server in the WAP farm

Unless noticed otherwise, all the instructions should be done on the Internet-facing WAP1 computer.

Before installing the Azure MFA Server user portal, ensure in Server Manager that, under Web Server (IIS),

  • ASP.NET 4.5 under Application Development,
  • IIS 6 Metabase Compatibility under Management Tools,
  • and Basic Authentication under Security

are installed.

If this isn't case, install them via the Server Manager tool, see section § Installing the prerequisites.

To install and configure the Azure MFA Server user portal, proceed with the following steps:

  • Open a remote desktop connection on ADFS1 if needed and log on as LITWARE369\AzureAdmin.
  • Open a remote desktop connection on WAP1 if needed and log on as LITWARE369\AzureAdmin.
  • Open Windows Explorer on the ADFS1 computer and navigate to the folder where Azure MFA Server is installed (e.g. C:\Program Files\Windows Azure Multi-Factor Authentication). Choose the MultiFactorAuthenticationUserPortalSetup64.msi installation file as appropriate (64-bit version) for the WAP1 computer that the Azure MFA Server user portal will be installed on. Copy the installation file to the WAP1 computer.

  • On the WAP1 computer, the setup file must be run with administrator rights. Open an elevated command prompt as an administrator and navigate to the location where the installation file was copied, for example the Desktop in our illustration.

PS C:\> cd .\Desktop

  • Run the MultiFactorAuthenticationUserPortalSetup64.msi installation file.

PS C:\> .\MultiFactorAuthenticationUserPortalSetup64.msi

A dialog pops up inviting you to install a Visual C++ redistributable x86 update.

  • Click Yes.

  • Click Save. Rename the file vc_redist.x86.exe, and the execute it.
  • Another dialog pops up inviting you to install a Visual C++ redistributable x64 update. Repeat above step 7.
  • Rerun the MultiFactorAuthenticationUserPortalSetup64.msi installation file. A Multi-Factor Authentication User Portal installation wizard eventually brings up.

  • Click Next.

  • Click Close.
  • After finishing the install of the MultiFactorAuthenticationUserPortalSetup64.msi file, browse to C:\inetpub\wwwroot\MultiFactorAuth (or appropriate directory based on the virtual directory name) and edit the web.config file with the editor of your choice.
  • Locate the appSettings section in the web.config file.

<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="pfup.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
</sectionGroup>
</configSections>
<appSettings>
<add key="USE_WEB_SERVICE_SDK" value="false"/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_USERNAME" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PATH" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PASSWORD" value=""/>
<add key="OVERRIDE_PHONE_APP_WEB_SERVICE_URL" value=""/>
</appSettings>

</configuration>

  • Set the value of the following keys as follows:
    • USE_WEB_SERVICE_SDK: true
    • WEB_SERVICE_SDK_AUTHENTICATION_USERNAME: LITWARE369\AzureAdmin
    • WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD: Pass@word1!?
    • OVERRIDE_PHONE_APP_WEB_SERVICE_URL: https://www.litware369.com/MultiFactorAuthMobileAppWebService (see later in this document)

Note    The username must be a member of the PhoneFactor Admins security group. Be sure to enter the Username and Password in between the quotation marks at the end of the line, (value=""/>). It is recommended to use a qualified username (e.g. domain\username).

  • Locate the pfup_pfwssdk_PfWsSdk setting.

<?xml version="1.0"?>
<configuration>

<applicationSettings>
<pfup.Properties.Settings>
<setting name="pfup_pfwssdk_PfWsSdk" serializeAs="String">
<value>http://localhost:4898/PfWsSdk.asmx</value>
</setting>
</pfup.Properties.Settings>
</applicationSettings>
</configuration>

Change the value from "http://localhost:4898/PfWsSdk.asmx" to the URL of the Web Service SDK that is running on the ADFS farm, e.g. https://adfs.litware369.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx in our configuration.

Note    Since SSL is used for this connection, you must reference the Web Service SDK by server name and not IP address since the SSL certificate will have been issued for the server name and the URL used must match the name on the certificate. In our configuration, the adfs.litware369.com server name does resolve to an IP address from the Internet-facing WAP farms. You should otherwise add an entry to the hosts file on that servers to map the name of the Azure MFA Server computers to its IP address.

Note     The root certification authority litware369-DC2-CA certificate is imported into the Trusted Root Certification Authorities store of the WAP1 computer that will be our Azure MFA mobile app web service web server. Thus, it will trust the adfs.litware369.com certificate when initiating the SSL connection.

  • Save the web.config file after changes have been made.

Important note    It is helpful to open a browsing session on WAP1 and navigate to the URL of the Web Service SDK that was entered into the web.config file, e.g. https://adfs.litware369.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx
in our configuration. If the browser can get to the web service successfully, it should prompt you for credentials as previously illustrated. Enter the username and password that were entered into the web.config file exactly as it appears in the file. Ensure that no certificate warnings or errors are displayed.

Testing the Azure MFA Server user portal

To test the Azure MFA Server user portal, proceed with the following steps:

  • Close the current remote desktop connection if any on the Internet-facing WAP1 computer and open a new one as LITWARE369\AzureAdmin with "Pass@word1!?" as password.
  • Open a browser session and navigate to https://www.litware369.com/MultiFactorAuth/.

  1. Provide the credentials (e.g. "roberth" and "Pass@word1!?") for the Robert Hatley test account and click Log In. When the cell phone rings, press "#" to complete the account verification. After a successful authentication, and once the security questions answered, you can now manage the account settings.

Note    For more information, see article Deploy the user portal for the Azure Multi-Factor Authentication Server.

Installing the Azure MFA Server user portal on the second server in the WAP farm

Repeat all the steps outlined in section § Installing the Azure MFA Server user portal on the first server in the WAP farm on the WAP2 computer.

Deploying the Azure MFA Server mobile app web service on the WAP farm (optional)

The deployment of the Azure MFA Server mobile app web service on the WAP farm consists in installing and configuring it on the two servers of the farm.

Installing the Azure MFA Server mobile app web service on the first server of the WAP farm

To deploy the Azure MFA mobile app web service on the Internet-facing WAP1 computer, proceed with the following steps:

  • Open a remote desktop connection on ADFS1 if needed and log on as LITWARE369\AzureAdmin.
  • Open a remote desktop connection on WAP1 if needed and log on as LITWARE369\AzureAdmin.
  • Open Windows Explorer on the ADFS1 computer and navigate to the folder where the Azure MFA Server is installed (e.g. C:\Program Files\Windows Azure Multi-Factor Authentication). Choose the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi installation file as appropriate (64-bit version) for the WAP1 computer that Azure MFA Server mobile app web service will be installed on. Copy the installation file to the WAP1 computer.
  • On WAP1, the above installation file must be run with administrator rights. The easiest way to do this is to open a command prompt as an administrator and navigate to the location where the installation file was copied, for example the Desktop in our illustration.

PS C:\Users\AzureAdmin.LITWARE369> cd .\Desktop
PS C:\Users\AzureAdmin.LITWARE369\Desktop>

  • Run the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi installation file.

PS C:\Users\AzureAdmin.LITWARE369\Desktop> .\MultiFactorAuthenticationMobileAppWebServiceSetup64.msi
PS C:\Users\AzureAdmin.LITWARE369\Desktop>

A Multi-Factor Authentication User Portal installation wizard brings up.

  • Change the Site if desired and change the Virtual directory to a short name such as "PA". A short virtual directory name is recommended since users must enter the Azure MFA Server mobile app web service URL into the mobile device during activation. Click Next.

  • Click Close.
  • After finishing the installation of the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi file, browse to C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService (or appropriate directory based on the virtual directory name) and edit the web.config file.
  • Locate the appSettings section in the web.config file.

<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="pfup.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
</sectionGroup>
</configSections>
<appSettings>

<add key="WEB_SERVICE_SDK_AUTHENTICATION_USERNAME" value=""/>
    <add key="WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD" value=""/>
    <add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PATH" value=""/>
    <add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PASSWORD" value=""/>

</appSettings>

</configuration>

  • Set the value of the following keys as follows:
    • WEB_SERVICE_SDK_AUTHENTICATION_USERNAME: LITWARE369\AzureAdmin
    • WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD: Pass@word1!?

Note    The username must a member of the PhoneFactor Admins security group. Be sure to enter the Username and Password in between the quotation marks at the end of the line, (value=""/>). It is recommended to use a qualified username (e.g. domain\username).

  • Locate the pfpaws_pfwssdk_PfWsSdk setting.

<?xml version="1.0"?>
<configuration>

<applicationSettings>
<pfpaws.Properties.Settings>
<setting name="pfpaws_pfwssdk_PfWsSdk" serializeAs="String">
<value>http://localhost:4898/PfWsSdk.asmx</value>
</setting>
</pfpaws.Properties.Settings>
</applicationSettings>
</configuration>

Change the value from "http://localhost:4898/PfWsSdk.asmx" to the URL of the Web Service SDK that is running on the ADFS farm, e.g. https://adfs.litware369.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx in our configuration.

  • Save the web.config file after changes have been made.

Note    Since the Azure MFA Server user portal is already installed on the farms, i.e. WAP1 and WAP2 computers, the username, password and URL to the Web Service SDK can be copied from the User Portal's web.config file.

Installing the Azure MFA Server mobile app web service on the second server of the WAP farm

Repeat all the steps outlined in section § Installing the Azure MFA Server mobile app web service on the second server of the WAP farm on the WAP2 computer.

Validating the configuration of Azure MFA Server mobile app web service

To validate the configuration of the Azure MFA Server mobile app web service, open a browsing session from any computer connected to the Internet and navigate to the URL where Azure MFA Server mobile app web service was installed (e.g. https://www.litware369.com/MultiFactorAuthMobileAppWebService/). Ensure that no certificate warnings or errors are displayed as illustrated hereafter.

Configuring the mobile app settings in the Azure MFA Server

All the instructions should be done on the ADFS1 computer.

To configure the mobile app Settings in the Azure MFA Server, proceed with the following steps:

  1. Open a remote desktop connection on ADFS1 if needed and log on as LITWARE369\AzureAdmin.
  2. Launch the Multi-Factor Authentication Server.
  3. Click on the User Portal icon.


  1. On the Settings tab, type the Azure MFA Server user portal URL, for example "https://www.litware369.com/MultiFactorAuth" in our configuration.
  2. Check Allow user enrollment.
  3. Check Allow users to select method. Under Allow users to select method, check Mobile app. Without this feature enabled, end users will be required to contact the Help Desk to complete activation for the Mobile App. Also check Phone call and Text message.
  4. Check Allow users to activate mobile app.
  5. Click on the Mobile App icon.

  1. In Mobile App Web Service URL, type the URL being used with the virtual directory which was created when installing the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi file, for example "https://www.litware369.com/MultiFactorAuthMobileAppWebService" in our configuration.
  2. In Account name, an account name may be entered in the space provided. This company name will display in the mobile application. If left blank, the name of your MFA provider created in the Azure portal will be displayed, for example "Litware369 Auth" in our configuration. Type "Litware369 Inc." for example.

Activating the Microsoft Authenticator app for end users

To activate the Mobile App, proceed with the following steps:

  1. Download the Microsoft Authenticator application from your app store. This application is available for Windows Phone, Android, and iOS. Once the Microsoft Authenticator app has been downloaded and is installed, you can activate it for multiple accounts.

Note    For more information, see article Microsoft Authenticator.

  1. Open a browsing session from any computer connected to the Internet and navigate to the Azure MFA Server user portal at https://www.litware369.com/MultiFactorAuth.
  2. Provide the credentials (e.g. "roberth" and "Pass@word1!?") for the Robert Hatley test account and click Log In. When the cell phone rings, press "#" to complete the account verification.


  1. Under My Account on the left, click Activate Mobile App.


  1. Click Generate Activation Code. (You can instead contact an administrator who will generate an activation code for them.)

  1. Switch to your mobile device
  2. Open
    the Multi-Factor Authentication application.
  3. In the mobile app, click New (+).

Note    The interface will differ slightly between mobile OS apps.

  1. Activate the Microsoft Authenticator app by entering the above activation code and URL or by scanning the barcode picture.
  2. Switch the authentication method to Mobile App or contact an administrator who will change it for them

Note    For more information, see article Getting started the MFA Server Mobile App Web Service.