Installing Azure Multi-Factor Authentication and ADFS


I have a requirement to ensure that Office 365 users external to the network of one of my clients need a second factor of authentication when accessing Office 365 resources from outside the corporate network. The free Multi-Factor Authentication (MFA) feature of Office 365 will not distinguish between network location so we need to enable MFA on ADFS (or Federated) authentication for external connections. External connections are those that come through a WAP server to the ADFS server and not those that come to ADFS directly.

To set this up, first install ADFS on Windows Server 2012 R2 and install additional ADFS servers and load balancers as required. Install the WAP servers in your DMZ and connect them to the on-premises ADFS server(s). Once this is all up and running enable MFA in Azure. You will need to create an MFA instance for billing purposes. Once this is created you can download the MFA software to the ADFS Server. For this blog we are using MFA Server version 7, released April 2016. This version does not need .NET 2.0 installed and works with .NET 4.0

On the ADFS Server run the MFA installer and follow the prompts. Make sure you have the Dec 2014 Cumulative Update or later (preferable the latest) installed. Accept the prompts for the two Visual C++ Runtime installations and complete the installation.

Following installation the wizard runs to configure MFA and MFA replication. I suggest making a group (called ADFS) and not using the default and setting up replication. The email address and password is obtainable from the MFA download page and is valid for 10 minutes.

Once installed start the MFA software and go to the AD FS page. Install the AD FS connector by pressing the button. On the primary ADFS server you then need to enable ADFS/MFA integration by running in PowerShell .\Register-MultiFactorAuthenticationAdfsAdapter.ps1. You can find this in Program Files\Multi-Factor Authentication Server. This is not needed on secondary servers.

Repeat the MFA install on all ADFS servers and install the MFA connector.

To allow users to set their own phone number and MFA settings install the SDK, User Portal and Mobile App features. These are detailed below:

User Portal

This requires that you install IIS/Web Server role on the server. In the role services for IIS include the HTTP Redirection feature, the ASP.NET 4.5 feature (under Application Development) and IIS 6 Metabase Compatibility (under IIS 6 Management Compatibility). Other role services are added because of these options.

Accept the prompts to create the users. You will be taken to a page about virtual directories. I tend to select the defaults here, apart from the app pool, which I set the the one that matches the name of the feature I am installing. I use HTTP Redirect feature to redirect the user from the root directory to HTTPS://fqdn/MultiFactorAuth.

image

Once the User Portal is installed I set the relevant options in the MFA admin program such as the User Portal URL and the auth methods allowed. If you are going to install the Mobile App feature then allow users to use this option.

If you are configuring HTTP Redirection then set this on the root directory of the default website now. Redirect only the root directory to HTTPS://fqdn/MultiFactorAuth

image

Make sure you turn HTTP Redirect off on all subdirectories and virtual directories of the application will not be reachable. Also check that HTTPS is bound to a certificate in IIS and to the website.

SDK

To install the SDK go to the Web Service SDK node in MFA on each ADFS server and click the Install Web Service SDK button. This requires Basic Authentication enabled in IIS. This is not a default role service, so you will need to add it to the server at this time.

Install the SDK and select the defaults:

image

If you have HTTP Redirection enabled, check it is disabled for the virtual directory as it won’t be by default.

Mobile App

To use the Azure Authenticator app to sign in to ADFS (as a second factor of authentication) you need to enable the Mobile App and have the URL reachable from the internet. The URL can be published through the WAP servers as these are available to you. To publish the MFA mobile app through WAP you can use the following cmdlet (changing the URL and certificate thumbprint as required):

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://auth.domain.co.uk/mfaApp/’ -ExternalCertificateThumbprint ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ -ExternalUrl ‘https://auth.domain.co.uk/mfaApp/’ -Name ‘Multi-Factor Authentication’ -ExternalPreAuthentication PassThrough -ClientCertificateAuthenticationBindingMode None -BackendServerCertificateValidation None -InactiveTransactionsTimeoutSec 300 -ClientCertificatePreauthenticationThumbprint ”

The mobile app needs to be installed on each ADFS server. Do this by opening a command prompt as admin and browse to the installation folder of the MFA server (C:\Program Files\Multi-Factor Authentication Server). Then run MultiFactorAuthenticationMobileAppWebServiceSetup64.msi

image

Change the Virtual Directory to something short, as users might need to enter this on their phone. I use mfaApp for this. Install and when finished If you have HTTP Redirection enabled, check it is disabled for the virtual directory as it won’t be by default.

Open this folder in admin cmd prompt (C:\inetpub\wwwroot\mfaApp in my case) and edit web.config. Modify the following two keys as follows:

<add key=”WEB_SERVICE_SDK_AUTHENTICATION_USERNAME” value=”” />
<add key=”WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD” value=”” />

The username and password here needs to be a member of the PhoneFactor Admins group in Active Directory.

Then locate <setting name=”pfpaws_pfwssdk_PfWsSdk” serializeAs=”String”> and change the Value string that follows from http://localhost:4898/PfWsSdk.asmx to https://fqdn/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx.

Finally enter the MFA App URL in the Mobile App section of the MFA admin program – this setting needs to be done once, as it will replicate to the other servers.

Restart the servers and you are ready to go.


by

Tags:

Comments

14 responses to “Installing Azure Multi-Factor Authentication and ADFS”

  1. filip avatar
    filip

    Brian,
    You install all components on the adfs servers. I presume you can install all mfa components on a separate server & install only adfs adapter on adfs?

  2. Brian Reid avatar

    Yes you can. You install the SDK on the MFA Server(s) and then copy the adapter installer to the ADFS servers and install it on each. Then you modify the config files for the adapter to point to the SDK location and the account to use. It is documented in the MFA help files.

  3. filip avatar
    filip

    can we install SDK, User Portal and Mobile App on two servers and use a load balancer to load balance these sites?

  4. filip avatar
    filip

    If we want mfa for iis/SharePoint/exchange do we need to install the ‘whole’ mfa installer on the server hosting ii’s/SharePoint/exchange? There is no iis adapter separate? And does that mean if we have 2 mfa servers already in a server group, we need to add this third also to this mfa server group?

    1. Brian Reid avatar

      Yes you do. The MFA Servrt needs to be local to IIS to add MFA to the auth pipeline. Or you could add claims support to IIS/Exchange/SharePoint and auth against a separate ADFS Server and put MFA here. This also means you get forms support.

  5. Joe Sutherland avatar
    Joe Sutherland

    Brian,
    Thanks for the article! I was planning to do something similar, but since the documentation says the Mobile Web App is generally deployed on an extranet server, I was thinking I needed to do that. I love having all three components on the federation servers and then using the existing WAP boxes to RP the app. Great idea!

    You mentioned in another comment that you can load-balance the user portal and Mobile Web App. Do you know anything, or have you been able to find any documentation on any persistence requirements for load-balancing these items? I haven’t run packet captures, but I’d imagine that the Mobile Web App would probably be fine since it’s likely all in one TCP session like ADFS. For the user portal, though, it seems like some persistence might be needed. Thoughts?

    1. Brian Reid avatar

      Yes, thought the reverse proxy for just the MFA mobile app web service via WAP is a good way to allow the mobile app (as Azure needs access to the app web service to work), and to have the user portal only available internal to the LAN (or externally via ADFS auth). Id say session persistence for the user portal or maybe cookie persistence as its a web app. The mobile app service would not need persistence if it is a single TCP packet, but not checked that!

  6. John avatar
    John

    What was the reasoning for going MFA server on-prem as opposed to MFA in the cloud? Was there an internal app that they didn’t want to publish to the App proxy?

    1. Brian Reid avatar

      Lots of reasons. App proxy only does HTTP, so MFA for RADIUS or VPN or RDP needs on-premises. On-premises integration with MFA allows for it to be called with any federated app and not just O365. Only disadvantage I can see to on-premises MFA us no support for App Passwords, do all apps/devices need to support modern auth to work

      1. Joe Sutherland avatar
        Joe Sutherland

        “All apps/devices need to support modern auth to work” … OR you can set the MFA rules in ADFS not to require MFA in certain instances. For example, I used a combination of issuance authorization rules and AdditionalAuthenticationRules (MFA rules) to configure ADFS to allow Outlook 2010 (not modern auth capable) to connect to Exchange Online, but only from on network. I also allow ActiveSync connections (also not modern auth capable) since they are governed by an MDM solution, so I am not concerned by allowing them without MFA.

        Also, app passwords are THE WORST. 🙂

  7. Joe Sutherland avatar
    Joe Sutherland

    Heads up that if you do the HTTP Redirect thing and choose “redirect all requests to exact destination” (which is nice to fix a request for mfa.customer.com/potral to mfa.customer.com/portal for you), you will break Chrome’s ability to use the portal. This breakage is due to the way Chrome requests favicon.ico. You can work around this by using the URL Rewrite functionality in IIS instead of http redirects, or you can just untick the “Redirect all requests to exact destination” box. Kudos to YAMM for blogging about this problem: https://blog.msresource.net/2016/05/13/azure-multi-factor-authentication-server-portal-looping-layer-8-issue/

  8. Wong KY avatar
    Wong KY

    Hello, your blog gave me quite a lot of after resolve “that” ADFS adapter issue in my MFA server from 6 to 7. It gave me a hell day.
    I would like to ask more about ADFS – MFA . Do you have any information that mentioned ADFS-MFA logon issue when using Chrome ? Or when using mobile browser ? What i experienced, it give me an error 364 (MSIS7001) in adfs server when using those browser… But no problem when using firefox or IE….

    Thanks~

    1. Brian Reid avatar

      Have you enabled forms auth on the intranet in ADFS for Chrome?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.