Recently, I’ve been involved in some larger Azure Multi-Factor Authentication (MFA) Server projects as a senior engineer with a couple of demanding customers. It’s been a lot of fun and quite the roller coaster ride.

In my opinion, an increasing number of organizations are looking to implement multi-factor authentication. They may be required to by regulators, they’ve seen the amount of breaches currently, or they’ve simply got the message from Microsoft’s cloud strategy.

These organizations, increasingly have requirements throughout their environments, that require a little more thought, than simply check the Require Multi-Factor Authentication option in Office 365 or deploy an Azure MFA Server with default settings.

One of the requirements they might have is that confidential information is not stored unencrypted in configuration files, like the web.config files of the Azure MFA User Portal, Azure MFA Mobile Portal and Azure MFA AD FS Adapter so they can connect to the Azure MFA Web Service SDK.

Choices

Throughout this blogpost, I’ll make the following (design) choices:

1. We’ll use an internal Certification Authority (CA) to issue certificates. We could use a publicly trusted Certification Authority (CA), but this might require external connections towards certificate revocation information (HTTP). We don’t use self-signed certificates, signed by the servers in scope, either.
2. Since the communications between the Azure MFA User Portal, Azure MFA Mobile Portal, Azure MFA AD FS Adapter and the Azure MFA Web Service SDK already utilizes one (configurable) TCP port, we don’t implement IPSec.

Assumptions

Throughout this blogpost, I’ll make the following assumptions:

• The Root Certification Authority is an Enterprise Root CA. This will allow you to set permissions on certificate templates, make domain-joined systems automatically enroll for certificates and make the certificate chain trusted throughout the Active Directory environment.
• You’ve setup Azure Multi-Factor Authentication Server version 7 successfully, using one of the many write-ups available to do so using usernames and passwords for the service account. If you want to know your deployment options, click here. If you want to follow my write-up, start here.

Prerequisites

First, perform these steps:

• Create at least one service account.
• Add the service account(s) to the PhoneFactor Admins group in Active Directory.
• Ensure the Certification Authority Web Enrollment feature is installed on the (issuing) Certificate Authority (CA), by navigating to /CertSrv">https://<CAName>/CertSrv.

Steps

Test the configuration

To test the configuration, visit the User Portal and log on using multi-factor authentication, based on the Mobile App to gain access to it. When it’s not working using username/password configuration, it certainly won’t magically start working using certificate authentication.

Ensuring the availability of the right certificates

Perform these steps to allow the right certificate to be requested:

• Log on to an Active Directory Domain Controller.
• Open the Active Directory Sites and Services MMC Snap-in.
• Enable Advanced Features.
• In the navigation pane, navigate to Certificate Templates.
• In the main pane, select the User certificate. Then, right-click it and select Properties from the context menu.
• On the Security tab, grant the PhoneFactor Admins group permissions to enroll the certificate.
• Log off.

Requesting the certificate

Perform these steps to request a certificate for a service account:

Note:
When you use service accounts per service, so one service account for AD FS, one service account for the Azure Multi-Factor Authentication Server User Portal and one service account for the Azure Multi-Factor Authentication Server Mobile Portal, perform the below fifteen steps for requesting a certificate for each of the service accounts.

• Log on to the primary Azure Multi-Factor Authentication (MFA) Server as an admin.
• Connect to the Certification Authority Web Enrollment website by navigating to \CertSrv">\CertSrv">http://<CAName>\CertSrv using Internet Explorer.
• Log in with the Service Account.
• Click Request a certificate.
• On Request a Certificate, click User Certificate.
• On the User Certificate Identifying Information page, do one of the following:
  • Comply to the message "No further identifying information is required. To complete your certificate, press Submit."
  • Enter your identifying information for the certificate request.
• (Optional) Click More Options to specify the cryptographic service provider (CSP) and choose if you want to enable strong private key protection. (You receive a prompt every time you use the private key that is associated with the certificate.)
• Click Submit.
• Do one of the following:
  • If you see the Certificate Pending page, the Certification Authority administrator will have to approve the request before you can retrieve and install the certificate.
  • If you see the Certificate Issued page, click Install this certificate.
• Download the certificate.
• Install the certificate within the admin session by right-clicking the downloaded certificate and selecting Install from the context-menu.
• Open the Certificates MMC Snap-in, go to the Certificate pane and select User Account.
• Right-click the certificate you installed previously and select Export from the context menu. Save it to a secure location and note the password you use to protect the key pair.
• Export the certificate to a base64 .cer file, too.
• Close the Certificates MMC Snap-in.

Configure the MFA WebService SDK

Perform these steps to configure Azure MFA Server’s Web Service SDK:

• In Server Manager, verify that the Web Server (IIS)\Web Server\Security\IIS Client Certificate Mapping Authentication feature is installed. If it is not installed, select Add Roles and Features to add this feature.
• In IIS Manager, double-click Configuration Editor in the website that contains the Web Service SDK virtual directory.

Note:
For security reasons, you want to perform these steps at the website level and not at the virtual directory level.

• Go to the following section:  system.webServer/security/authentication/iisClientCertificateMappingAuthentication
• Change enabled to true.
• Change oneToOneCertificateMappingsEnabled to true.
• Click the … button next to oneToOneMappings, and then click the Add link.
• Open the Base64 .cer file you exported earlier. Remove —–BEGIN CERTIFICATE—–, —–END CERTIFICATE—–, and any line breaks. It becomes a single line. Copy the resulting string.
• Configure the certificate using the string copied in the preceding step.
• Change enabled to true.
• Configure userName to the service account your created as part of the prerequisites and is a member of the PhoneFactor Admins security group.

Tip!
Use the <domain>\<user name> format here.

• Set the password to the appropriate service account password.
• Close Configuration Editor.
• Click the Apply link.
• In the Web Service SDK virtual directory, double-click Authentication.
• Verify that ASP.NET Impersonation and Basic Authentication are set to Enabled and all other items are set to Disabled.
• In the Web Service SDK virtual directory, double-click SSL Settings.
• Set Client Certificates to Accept, and then click Apply.

Configure the MFA AD FS Adapter

To (re)configure the Azure Multi-Factor Authentication (MFA) Server Active Directory Federation Services (AD FS) adapter, perform these steps:

• Copy the .pfx file you exported earlier to the server that is running the AD FS adapter.
• Open the MMC Snap-In for Local Computer Certificates by pressing the Start button and typing certlm.msc.
• Import the .pfx file to the local computer’s personal certificate store.
• Right-click and select Manage Private Keys, and then grant read access to the account you used to sign in to the AD FS service.
• Open the client certificate and copy the thumbprint from the Details tab.
• Make the following three changes in the MultiFactorAuthenticationAdfsAdapter.config file:
  • Change the value for WebServiceSdkCertificateThumbprint to the string copied in the previous step.
  • Change UseWebServiceSDK to “true” (Do not change it to “True”)
  • Specify the value for WebServiceSDKUrl.
• Afterwards, it should look like this:

• Save the MultiFactorAuthenticationAdfsAdapter.config. file.
• Next, alter the Register-MultiFactorAuthenticationAdfsAdapter.ps1 script to include the ConfigurationFilePath parameter to the full path of the MultiFactorAuthenticationAdfsAdapter.config file.
• To register the MFA AD FS adapter, start a Windows PowerShell console window as administrator and run the Register-MultiFactorAuthenticationAdfsAdapter.ps1 script.

Configure the MFA User Portal and mobile portal

Perform these steps to (re)configure Azure Multi-Factor Authentication Server’s User Portal and Mobile Portal:

• Copy the .pfx file you exported earlier to the server that is running the Azure Multi-Factor Authentication User Portal and/or Azure Multi-Factor Authentication Mobile Portal.
• Open the MMC Snap-In for Local Computer Certificates by pressing the Start button and typing certlm.msc.
• Import the .pfx file to the local computer’s personal certificate store.

When the server that is running the Azure Multi-Factor Authentication User Portal and/or Azure Multi-Factor Authentication Mobile Portal runs in a perimeter network, and is not joined to the Active Directory domain, also import the certificate chain, containing the Root CA, any relevant intermediate CAs and the CA that issued the certificate.

• Right-click and select Manage Private Keys, and then grant read access to the following accounts:
  • IIS APPPOOL\MultiFactorAuthPhoneAppWebService*
  • IIS APPPOOL\MultiFactorAuthUserPortal
    *The application pools used in IIS to host the virtual directory’s.
• Change the web.config of the Mobile Portal to include the private key as the value for the WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_THUMBPRINT setting and remove any values for WEB_…_USERNAME and WEB_…_PASSWORD:

• Save the web.config file.
• Change the web.config file on the User Portal to change the value for the USE_WEB_SERVICE_SDK setting to true and the private key as the value for the WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_THUMBPRINT setting and remove any values for WEB_…_USERNAME and WEB_…_PASSWORD:

Test the configuration

To test the configuration, visit the User Portal and log on using multi-factor authentication, based on the Mobile App to gain access to it.

Concluding

The requirement to not store confidential information unencrypted in configuration files, can be met using the steps above for the Azure MFA User Portal, Azure MFA Mobile Portal and Azure MFA AD FS Adapter for their connection to the Azure MFA Web Service SDK.

Related blogposts

Ten Things you need to know about Azure Multi-Factor Authentication Server
Supported Azure MFA Server Deployment Scenarios and their pros and cons
Azure Multi-Factor Authentication Server 7.3.0.3 with lots of improvements
Branding the Azure Multi-Factor Authentication Server User Portal
Azure Multi-Factor Authentication features per license and implementation
Azure Multi-Factor Authentication Methods per Supported Protocol

Further reading

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