Exploring Azure Multi-Factor Authentication Server

In October of last year, Microsoft purchased the company PhoneFactor.  Over the following months, they repackaged the PhoneFactor product into what is now Azure Multi-Factor server, announced in September 26th for General Availability.  With such a recent release, it's not surprising that documentation on the product is a bit sparse, and at times misleading.  Recently, I implemented the MFA server at a client to compliment access to their Citrix environment through a NetScaler.  The experience was informative, and I wanted to share my insights and discoveries.

First of all, what is Azure MFA?  It is a cloud based multi-factor authentication service provider which includes an on-premise server component.  The on-premise server (and by server I am referring to the software installed on any member server) can use LDAP or Active Directory for an identity source and is able to provide a secondary authentication mechanism for a number of different applications including:

That's a pretty comprehensive list.  The service can either call you, text you, or interact with an app on your smartphone to provide the secondary authentication.  The on-premise server handles the user configuration and interaction with the various identity providers and authentication sources.  The cloud portion of the service handles the actual contact with the client endpoint to perform the authentication.  

Each installation of the MFA server software requires it to be activated with the hosted portion and be assigned to a new or existing group.  Servers which are grouped together share a common configuration file.  That configuration file is located in %Program Files%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata.  Within the group, a single server is designated as the master, and only it can edit the pfdata file.  All other servers in the group synchronize with the master server.  When launching the Multi-Factor Authentication Server UI, the UI must be able to communicate with the master server.  Otherwise launching the UI fails.  Replication between the servers in a group can be secured using either certificates of Active Directory.  In the same path as the pfdata file, there are a number of certificate files which are used to secure communication between the servers in the group.  The groupCACert has a Subject corresponding to the value found in the groupKey file.  The CACert has a Subject corresponding to the value found in the licenseKey file with -CA appended.  The certificate is issued by noc@positivenetworks.net.  The final cert file is issued to a combination of the licenseKey and groupKey values.  Each server in the group should have the same CACert and groupCACert files.  The cert file is the public key which other servers in the group can use to encrypt communications.  There is also pkey file which hold the private RSA key.

If for any reason you ever need to reauthorize a server, all you need to do is delete the content of the Data folder and run the UI again.  It will force you to reactivate the server with a new code from the hosted service.  You can also use this process to seize the master role if your master server goes into some unrecoverable state.  Essentially you are trying to make the pfdata file writable again.  You can do that by following these steps:
  1. Stop the MultiFactorAuth service on the server
  2. Go into the installation folder: %Program Files%\Multi-Factor Authentication Server\Data and copy PhoneFactor.pfdata to the Desktop
  3. Delete all files from %Program Files%\Multi-Factor Authentication Server\Data
  4. Start the MultiFactorAuth service on the server
  5. Launch the Multi-Factor Authentication Server UI and select to skip the Configuration Wizard
  6. Log into the Manage.windowsazure.com portal and select Manage the MFA Provider
  7. Under Server Status on the MFA Management page delete the missing master server
  8. Under the Downloads area generate Activation Credentials
  9. Activate the slave server and join it to the correct group
  10. When prompted, elect to transfer the master role
  11. Once the UI is finished loading, close the interface
  12. Stop the MultiFactorAuth service on the server
  13. Copy the PhoneFactor.pfdata file from the Desktop back into %Program Files%\Multi-Factor Authentication Server\Data
  14. Start the MultiFactorAuth service on the server
  15. Open the UI and all settings should be restored
Even if the master server is unavailable, all the remaining servers in the group will continue to function properly.  You simply will not be able to make any modifications to the configuration (including adding new users).  Microsoft support has claimed that simply starting the UI on a non-master should prompt the user to grab the master role.  I have not found that to be the case, and the process outlined above does indeed work.

That's probably enough for now.  I'll be back in part two to talk about the full setup and Exchange OWA integration.

Labels: , , , , , , ,