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:
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:
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:
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.
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.
Note For more information, see article Building Multi-Factor Authentication into Custom Apps (SDK).
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:
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.
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.
To cover the aforementioned objectives, this document is organized in the following two sections:
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.
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.
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:
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.
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.
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.
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.
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:
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:
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:
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.
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:
The following subsections describe in the context of our test lab environment each of these steps.
To create an Azure MFA provider via the classic Azure portal, proceed with the following steps:
Note For more information on usage model, see Multi-Factor Authentication Pricing Details.
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.
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:
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.
The instructions below should be done on the ADFS1 and ADFS2 computers as instructed.
To install the Azure MFA on the AD FS farm, proceed with the following steps:
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.
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.
The configuration of multi-factor authentication in AD FS in Windows Server 2012 R2 consists in:
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:
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.
A Multi-Factor Authentication Server opens.
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.
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.
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:\>
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.
To configure Azure MFA Server on the ADFS2 computer, proceed with the following steps:
The following dialog may bring up.
The ADFS1 and ADFS2 computes should be both listed as illustrated above.
To set up the multi-factor authentication policy, proceed with the following steps on the ADFS1 computer:
PS C:\> $rp = Get-AdfsRelyingPartyTrust –Name "Microsoft Office 365 Identity Platform"
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");'
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.
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.
To verify the multi-factor authentication policy, proceed with the following steps:
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.
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.
The installation of the Multi-Factor Authentication SDK consists in:
All the instructions should be done on the ADFS1 computer.
To install the Web Server (IIS) service role, proceed with the following steps:
Once complete, you can then install the Multi-Factor Authentication SDK
To install the Multi-Factor Authentication SDK, proceed with the following steps:
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.
To configure HTTPS on the default web site, proceed with the following steps:
PS C:\> New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https
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>
Repeat all the steps outlined in section § Installing the Multi-Factor Authentication SDK on the primary federation server on the ADFS2 computer.
To test the Multi-Factor Authentication SDK configuration, proceed with the following steps:
Username: AzureAdmin
Password: Pass@word1!?
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.
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),
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:
PS C:\> cd .\Desktop
PS C:\> .\MultiFactorAuthenticationUserPortalSetup64.msi
A dialog pops up inviting you to install a Visual C++ redistributable x86 update.
<?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>
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).
<?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.
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.
To test the Azure MFA Server user portal, proceed with the following steps:
Note For more information, see article Deploy the user portal for the Azure Multi-Factor Authentication Server.
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.
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.
To deploy the Azure MFA mobile app web service on the Internet-facing WAP1 computer, proceed with the following steps:
PS C:\Users\AzureAdmin.LITWARE369> cd .\Desktop
PS C:\Users\AzureAdmin.LITWARE369\Desktop>
PS C:\Users\AzureAdmin.LITWARE369\Desktop> .\MultiFactorAuthenticationMobileAppWebServiceSetup64.msi
PS C:\Users\AzureAdmin.LITWARE369\Desktop>
A Multi-Factor Authentication User Portal installation wizard brings up.
<?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>
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).
<?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.
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.
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.
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.
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:
To activate the Mobile App, proceed with the following steps:
Note For more information, see article Microsoft Authenticator.
Note The interface will differ slightly between mobile OS apps.
Note For more information, see article Getting started the MFA Server Mobile App Web Service.