Installing and Configuring Azure Multi-Factor Authentication (MFA)

20 Feb

Following on from my previous post: SMB Multi-Factor Authentication (MFA) with Smartphones and RD Gateway

Firstly, head over to Azure, sign-up and create a free trial account, this is valid for 30 days.

Login to your Azure portal and have a look around, it’s all pretty straight forward, but for setting up on-premise MFA you need to head over to ‘ACTIVE DIRECTORY’ on the left menu

Setup the default directory with the default settings and then select ‘MULTI-FACTOR AUTH PROVIDERS’ at the top and then select ‘Add’ at the bottom.

You can then select ‘MANAGE’ at the bottom to open the MFA Management Portal:

Click on ‘Downloads’ and then download the MFA Server Software.

Click ‘Generate Activation Credentials’ and make a note of these:

Also. While you are here, click on Settings and configure the default settings:

In here, any fraud alerts will be emailed to me, also the default Bypass time can be specified. (Some users can be given admin to the internal, i.e. support staff, user portal and can allow the bypass for a user who cannot use MFA, either because they have lost their device or similar). You can also set the number that appears on users’ phones when they select to authorise by phone call, I used the IT Support number.

If you click caching on the left, I have create a user cache that is valid for 200 seconds, I will explain this later on:

Now we are done on the Azure Portal for the moment, head over to a machine on your LAN, I am using a DC running Server 2012. Install the MultiFactorAuthenticationServerSetup.exe software that we downloaded (you may need to run it as an Administrator)

It’s a pretty straight forward installation with few options, you will need to enter the activation credentials that you generated earlier.

You will actually install this software on many devices that you wish to protect, and machines that have IIS, RDP, OWA, RDWeb etc.

One copy will be the master server, I chose my DC as this master.

Click on ‘Directory Integration’ and select ‘Use Active Directory’:


You can change various filters here if you wish, I decided to change my username to be sAMAccountName so that on the user’s mobile device it displayed firstname.surname as the account rather than domain\firstname.surname.

Click on the ‘Email’ icon and set you mail sever parameters:

Click on ‘Company Settings’ and set your options, most of these you will leave as the default:

Click on the ‘Synchronization’ tab and then select ‘Add’ at the bottom.

In here select the OU with your users and set the default options for all users imported from here. (You may wish the remove users that are no longer a member)


Once the Synchronization Item has been added, head back and set how often AD will sync with MFA (This will depend on the size of your company and how often new users are added and removed). I set it to an Hour, which is probably too high. You can then manully force a sync by clicking ‘Synchronize Now’ at the bottom.

There are a few more things we need to install:

  • The user Portal – This is a website where users can login and manage their own devices, meaning IT don’t have to setup each device.
  • The Mobile App Web service – This is what the smartphones talk to.
  • Web Service SDK – This is the back end web service.

All of these websites need to run over HTTPS. As I already had a public website and certificate (and firewall rules) for OWA, I opted to install the user portal as an application within that site:

To do this, install the MultiFactorAuthenticationServerSetup.exe software (If you now click on the ‘Status’ icon, you will see all the servers where you have installed this).

Once installed, click the ‘User Portal’ icon and then the ‘Install User Portal’ button.

Make sure that you have all the prerequisites installed:

Once you do, the install process with then allow you to select the IIS site from a dropdown and then the Virtual Directory/Application name. I opted for ‘portal’ over the default as users need to navigate to this address and so it made sense to keep it simple and easy to remember.

You can then set you Portal user options:

Enter the WAN URL (this is what is sent to user’s phones when they scan the barcode later on)

I removed the OATH token method as I won’t be supporting these. I also removed the options for security questions as this seemed a possibly way to bypass the security, making it less secure.

If you click the ‘Administrators’ tab at the top you can select admins who can perform a variety of options, you will probably want to let some support staff generate bypass codes.

I also the IP ‘Whitelist’ here for the internal network, so users accessing the portal inside the secure network won’t be prompted for MFA.

(Note that the user above cannot change the default time that we specified in the Azure portal earlier, this is to stop them setting it for say 86400 seconds etc)

You also need to install the Web Service SDK, I opted to install this on the same box, but it’s up to you where you install it, the process is pretty much the same as for the portal.

Again, select a Virtual Directory/Application name, I opted for ‘mfa’.

Next install the Mobile Add Web Service, on the server with the Web Service SDK, navigate to:

C:\Program Files\Windows Azure Multi-Factor Authentication

And select the MSI for you architecture:

  • MultiFactorAuthenticationMobileAppWebServiceSetup32.msi
  • MultiFactorAuthenticationMobileAppWebServiceSetup64.msi

Again, the installer for this is straight forward, the Application Name I opted for here was ‘webservice’.

We now need to configure the Web Service SDK, navigate to ‘C:\inetpub\wwwroot\mfa’ (or where ever you opted to install it) and open up ‘Web.config’ in notepad.

In here add service account AD user details in WEB_SERVICE_SDK_AUTHENTICATION_USERNAME and WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD and also specify the Web Service URL under ‘pfpaws.Properties.Settings’.

In IIS I changed the webservice site to only be accessible from the local IP using ‘IP Address and Domain Restrictions’.

Users can now start to enrol, you may want to get users to enrol first, and troubleshoot any issues before forcing users to use MFA.

Registration is simple, and as most users now have smartphones, this is what they will use to authenticate.

The user navigates to the portal and logs in using their AD details. If they not associated a device already they can login with just their AD credentials, if they have specified a device, they will need to authenticate when logging in to the portal, unless they are coming from and IP in the Portal Whitelist that we specified earlier.

Once in they can select the method (note OATH is not an option)

If using ‘Mobile App’ the user then selects ‘Generate Activation Code’ and a barcode will be shown:

This of course assumes that user has already installed the app on their smart phone, it can be downloaded from:

  • iPhone: (iOS 4.3+ Required)
  • WindowsPhone: (WindowsPhone 7.5+ Required)
  • Android: (Android 2.2+ Required)

The rest of this guide is based on the iPhone 4S, other devices may vary slightly.

When the user opens the App they can select ‘Scan Barcode’, once the barcode is in focus is will automatically enter the Activation Code and URL. (If the users’ camera is not working, they can enter this information manually. If you get an activation error, chances are that Notifications have been turned off and the user will need to go to ‘Notification Centre’, ‘Multi-Factor’ and ensure that notifications are set to ‘Banners’ or ‘Alerts’.

The user’s device is now successfully enrolled.

If you wish, you can login to the internal portal as an administrator and find the user. Depending on you admin permission you will see some of these options:

If you select ‘Test Authentication’ is will send a notification to their device, if they verify it then it will show as successful.

Once all your users are successfully enrolled, you can look to protect some of your services.

To protect OWA for example, open up the MFA Server Software and click on ‘IIS Authentication’. Click on the ‘HTTP’ tab and enter the URL of OWA. Select the ‘Native Module’ tab and select ‘owa’:

You can protect pretty much any IIS site using this method.

The main are I wanted to protect was Remote Desktop Gateway.

On your Remote Desktop Gateway server. The guide here outlines what needs to be done, although I needed a few adjustments.

For my setup I have 3 servers:

  • Server 1 – Remote Desktop gateway Server.
  • Server 2 – Domain Controller and NPS.
  • Server 3 – Websites for Portal, SDK and WebService and also MFA RADIUS Server.

Open RD Gateway Manager (Server 1) and set the ‘RD CAP Store’ to a different server running NPS.

On that server (Server 2), open NPS and make sure you have 2 clients listed, your RD Gateway box (Server 1) and your other server running the MFA Radius (Server 2. There seemed to be issues installing these on the same box, so I split them up)

Under ‘Remote RADIUS Server’ only the default entry exists, in the properties of this I have the IP for Server 3:

Next under ‘Connection Request Policies’ we have 2 entries.

1) MFA: This is the MFA Server (Server 3) talking back to Server 2. Under conditions I have set the ‘Client IPv4’ Value to the IP of Server 3 and under ‘Settings’ it is set to ‘Authenticate requests on this server’.


2) PhoneFactor Auth: This forces MFA Authentication for users. Under settings here, we forward requests to the MFA RADIUS Server:



Next head over to Server 3 and open the MFA Software and select the ‘RADIUS Authentication’ icon:

Enable it and add a client entry for Server 2:


Click on the ‘Target’ tab and add and entry for Server 2:


You can select IP’s from which you do not request MFA, i.e. your internal office LAN Range.

– I cannot get the whit list here to work as the IP Address seems to be that of the RD Gateway, and not the actual client.

Next select ‘Multi-Factor Auth Servers’ and tick the box next to Server 3: (This will start the RADIUS service on that machine)


Remote Desktop Gateway is now protected with MFA.

There is an ongoing issue with this sending multiple requests that I’m yet to resolve, and the people from M$ seem less than helpful, infact they’ve been useless to be perfectly honest.

The work around is to make users go to the RDWeb site first, once authenticated, the authentication for that user is cached for 200 seconds, giving them time to login. I have also set the RDWeb site timeout to 2 minutes:

think this is configured in the web.config file located in “C:\Windows\Web\RDWeb\Pages” there you find:

<!– Public/Private Mode Timeout for FBA –>
<add key=”PublicModeSessionTimeoutInMinutes” value=”20″ />
<add key=”PrivateModeSessionTimeoutInMinutes” value=”240″ />

The issue with the multiple requests has been resolved, this was an odd one. It was actually the settings of the the local NPS server on the RD Gateway box. Even though RD Gateway was set to use a central NPS server it would appear that it still pulled settings from the local NPS.

So on the RD Gateway box, open NPS, go to Remote RADIUS Server and edit that and set the load balancing settings in there to:

  • Priority: 1
  • Weight: 50
  • Number of seconds without a response before request is considered dropped: 60 (not 3!)
  • Maximum number of dropped requests before a server is identified as unavailable: 5
  • Number of seconds between requests when server is identified as unavailable: 60


  • David Gorman

    Hi Dave, I wonder if you can help. I am trying to setup MFA for radius for VPN traffic. I have configured all the options as far as I can tell but MFA does nothing. I can connect to VPN without any MFA challenge, any ideas?



    • dphuk


      It took me a long while to get this working, what device is the VPN end point and does that have logging that might shed a bit more light? There are plenty of differing radius standards too, just to make things more complicated 🙂



  • KJ

    What Conditions did you set for the the PhoneFactor Auth connection policy?

    • dave

      Worry KJ, I have 2 policies on my NPS Server (Server 2).
      1 – “MFA” – Type = Remote Desktop Gateway, Conditions: Client IPv4 = x.x.x.x
      2 – “PhoneFactor Auth” – Type = Remote Desktop Gateway, Conditions: NAS Port Type = “Virtual (VPN)”.
      Hope that helps. Cheers, Dave.

  • dudley

    Hi Dave, nice article.
    Can you tell me if you have on-prem Exchange, ADFS, MFA, WAP (DMZ) – do you need to dirsync between Azure AD and your internal AD? or is the sync between MFA an the internal AD all that is required

    • dave

      Sorry Dudley, didn’t notifications of these comments, need to check my settings there! On-prem Exchange, everything is on-prem, only really using azure for MFA and some test VM’s.

  • Pingback: Building the Ultimate Enterprise Mobility Lab Environment… - 640K Ought To Be Enough For Everyone... - Site Home - TechNet Blogs()

  • Kim

    I installed MFA Server in my client machine but I couldn’t able import the user from my Azure AD , Can you help me

    • Hoani

      Hi Kim,

      The on-premises MFA server is for securing on-premises services like RDS or VPN. This works in conjunction with your azure licensing for MFA and you import your on-premises AD user accounts, not azure AD into the tool.

      These users of course, will marry up to your AADConnect synchronised Azure AD user accounts that have been applied licenses.

      Depending on your requirements you might not need the MFA server, what services are you trying to secure, or is it for Azure/Office 365 services only?

  • Erik Nettekoven

    Although I followed many manuals in configuring MFA, I keep running in to the following when trying the Mobile App part: “Exception calling the Web Service SDK: Unable to connect to the remote server”

    any idea how to fix this?

    • Sounds like an SSL error maybe, are you using a self signed certificate?

      • Erik Nettekoven

        We use a wildcard certificate from Comodo, which is working fine. I finally got it working by adding a FW Lookup zone to the internal DNS server. The internal domain is named So I created a new FW lookup zone and put in a glue record to the internal IP address of the MFA server. That fixed my problem.

        Your guide is more comprehensive than the one from Microsoft though, good job!

        • Cheers Erik, glad you got it sorted!