In this article of my BYOD lab in Azure series, I will cover multi-factor authentication—an authentication mechanism that involves two (or more) factors, such as user credentials, certificates, or hardware tokens.

Many organizations would benefit from the demos you’d be able to provide with your Bring Your Own Device (BYOD) test lab on claims-based access, Workplace Join, and Work Folders. However, when you demo to organizations with a mature IT organization and/or to security officers, your demos will inevitably raise security questions.

I’ll tell you the best way to lay out your demos in the next and final post in this series.
Stay tuned just a little while longer.

Yes, Single Sign-On poses security risks. Providing Single Sign-On for colleagues means they have the same set of credentials in all integrated applications and services. When they change their password or have it reset, the password changes in all integrated applications and services near instantly. From a security perspective, this means the credentials obtained through shoulder surfing are the credentials to all integrated applications and services. This risk is predominantly present on devices with on-screen keyboards, such as tablet devices.

One way of addressing this is to communicate the above risk to colleagues.

Multi-factor authentication ^

Another way is to implement multi-factor authentication, strategically.

About multi-factor authentication

Multi-factor authentication, or two-factor authentication, is the term used to define the authentication mechanism that involves two (or more) factors. A “factor” is something you can prove: something you know (for instance, the username and password), something you possess (for instance, a token, a TPM-enabled device, a certificate, or a phone), or something that confirms your physical identity (for instance, a positive iris scan or a specific thumbprint).

Azure Multi-Factor Authentication

Since we’re already using loads of Azure resources, it’s logical to simply add Azure Multi-Factor Authentication (MFA) to the mix. Azure MFA is Microsoft’s multi-factor authentication solution, as Microsoft bought PhoneFactor on October 4, 2012.

Multi-Factor Authentication Flow

Multi-Factor Authentication flow

The Azure MFA solution consists of two parts: the Multi-Factor Authentication Server, which you run close to your Identity Provider (Active Directory Domain Services), and the Multi-Factor Authentication Service, which runs in Microsoft Azure.

When a colleague wants to access an on-premises application (either on-premises or from the Internet) (1), the application connects to the Identity Provider to offload authentication and to make sure the user account that was used is, in fact, authorized for the application (in terms of claims or SIDs). Instead of talking to Active Directory directly, the app talks to the Multi-Factor Authentication Server installation (2). This installation checks the credentials for the user account with Active Directory (3, 4). When this is successful, the Multi-Factor Authentication Server requests the second factor through the Multi-Factor Authentication Service (5). This service, in Microsoft’s cloud, contacts your phone device using the preferred method (6, 7). When this is successful, the Multi-Factor Authentication Server installation passes the authentication package to the application for authorization and further use (9).

The strong point of Azure MFA is its flexibility; it has multiple ways to reach out to your phone so you can prove you have it:

  • Call the number and leave a PIN that the colleague needs to enter.
  • Call the number and make the colleague press the # key.
  • Text the number and provide a PIN that the colleague needs to enter.
  • Make the colleague enter the value for a soft token in an authenticator/verificator app.

As an admin, you can set the possible methods to authenticate, as well as their priorities. Because a phone’s location can be traced, Azure MFA gives admins reports on impossible travel routes to assist with detecting fraud.

Another big thing with Azure MFA is that it seamlessly integrates with Active Directory Federation Services using the AD FS Extensibility framework. This makes deploying Azure MFA fairly simple, as I’ll show you in the following two steps.

Step 24 (optional): Configure MFA in Azure ^

To enable Azure Multi-Factor Authentication, we need to enable the MFA Service in Microsoft’s cloud. We can create the service endpoint with these steps:

  1. Log on to the Azure Management Portal through
  2. In the left pane, scroll down a bit and select Active Directory.
  3. In the ribbon at the top of the main pane, select the Multi-Factor Auth Providers tab.
  5. Give the provider a meaningful name. I chose to name it
  6. Choose the usage model you want to employ. For demo purposes, my advice is to go with the Per Enabled User model.
  7. For the Directory, choose Do not link a directory.
  8. Click Create.

That’s it.

Step 25 (optional): Configure the MFA Server ^

When you’ve taken step 24, you also want to take step 25. In this step, we’ll download the MFA Server component and configure it:

  1. While you’re still logged on in the Windows Azure Management Portal (see above), and still on the Multi-Factor Auth Providers tab, click Manage in the bottom ribbon.
    This will take you to PhoneFactor.Net where you can see the account ID, view reports, configure the service, and download the server:
    Windows Azure Multi-Factor Authentication Portal
  2. Click the DOWNLOADS link on the main page.
  3. Download the server by clicking the grey Download link below the list of supported operating systems. This will download a 114 MB heavy installer for the MFA Server in the disguise of MultiFactorAuthenticationServerSetup.exe.
  4. Keep the website open on the device you use for web browsing.

Let’s install the MFA Server:

  1. Log on to server ADFS with domain admin credentials.
  2. From Server Manager, in the grey ribbon, click Manage and then select Add Roles and Features from the context menu.
  3. Click Next > four times.
  4. On the Select Features screen, expand .NET Framework 3.5 Features, and then select .NET Framework 3.5 (includes .NET 2.0 and 3.0).
  5. Click Next >.
  6. Click Install.
  7. Click Close when the .NET Framework is installed.
  8. Using the RDP Clipboard functionality, copy the MultiFactorAuthenticationServerSetup.exe filefrom the web browser box to server ADFS. Place it somewhere convenient.
  9. Double-click MultiFactorAuthenticationServerSetup.exe.
  10. Choose C:\Program Files\Multi-Factor Authentication Server\ as the installation folder, and then click Next >.
  11. Click Finish when done.

After you’ve installed the MFA Server component, the Multi-Factor Authentication Server Authentication Configuration Wizard will automatically start. This is the starting point of our configuration. Quickly head back to your web browsing device and click the Generate Activation Credentials button to get an email and password combination. You’ll need it shortly.

  1. After the initial splash screen, on the Welcome screen, select Skip using the Authentication Configuration Wizard and click Next.
    Activate the Multi-Factor Authentication Server
  2. On the Activate screen, enter the email and password combination you gained by clicking the Generate Activation Credentials button.Note:
    We did this only now because this combination expires pretty fast—usually within the timeframe it needs to copy the installer and run it.

Click Next > when done.

  1. On the Join Group screen, create a new group by providing something appropriate in the New group: field. Click Next >.
  2. When you’re planning on a multi-server, on-premises MFA Server implementation, you’d want them to replicate. In this case, we don’t need that, so select No.

This ends the initial configuration of the MFA Server. The Multi-Factor Authentication Server Management portal opens:

Multi-Factor Authentication Server

Multi-Factor Authentication Server

And none of these procedures took more than 11 steps.

Now, let’s get ADFS hooked on Azure MFA:

  1. In the left pane, click ADFS.
  2. In the main pane, select these options:
    1. Allow User Enrollment
    2. Allow user to choose method including phone call and text message
    3. Use security questions for fallback
    4. Enable logging
  3. Click the Install ADFS Adapter button at the top.
  4. Click Next > four times.
  5. Click Close.

Next, in PowerShell, run the Register-MultiFactorAuthenticationADFSAdapter.ps1 script from the Azure MFA Server installation folder.

Now, all we need to do is restart the Active Directory Federation Service:

  1. Press Start.
  2. Type services.msc and then press the Ctrl, Shift, and Enter keys to run services.msc as administrator.
  3. Look up the Active Directory Federation Service in the list of services.
  4. Right-click the service and select Restart from the context menu.

To enable MFA in AD FS, perform these actions:

  1. In Server Manager, from the Tools menu in the ribbon, select AD FS Management.
  2. In the left pane, select Authentication Policies.
  3. In the main pane, scroll down a bit to Multi-Factor Authentication and then follow the Edit hyperlink next to the Global Settings.
    Edit Global Authentication Settings
  4. On the Multi-factor tab, select WindowsAzureMultiFactorAuthentication as an additional authentication method to enable MFA. Click OK when done.

Concluding ^

With these last optional steps, we’ve completed the setup of our Bring Your Own Device (BYOD) test lab. Join me for Part 10 of this series, where I’ll show you how to use the lab for demos.


Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account