I’ve been designing, implementing, updating and managing Azure Multi-Factor Authentication for several organizations. It has become one of my favorite tools in my toolbox, but there are a couple of things that I think you should know:
1. You can’t implement it through scripting
Although we have built extensive PowerShell scripts to configure Internet Information Services (IIS) to prepare for the Multi-Factor Authentication User Portal and Multi-Factor Authentication Mobile Portal and the Web Services SDK and to configure service accounts and certificates, installation of the Multi-Factor Authentication Server components themselves cannot be scripted to your needs.
That doesn’t sound too bad, except for when you want to deploy the Multi-Factor Authentication Server in an environment that requires quick scale out and scale back. Adding a new fresh Multi-Factor Authentication Server to that mix, or removing it, is not as easy as it sounds.
2. No such thing as an IIS Agent
Yes, you can install a special sleek package on your Active Directory Federation Services (AD FS) Servers to add multi-factor authentication to all your claims-based web-based application connected to it, but there is no such package for Internet Information Services (IIS).
The Windows Integrated Authentication (WIA) and Forms-based Authentication (FBA) features only work for web-based applications, but it requires full installations of Azure Multi-Factor Authentication Server on these IIS Servers. Of course, you can reroute only the login pages to these IIS Servers and host your content on other web servers (including Apache and Nginx), but having a full server with its (replicated) database in a DMZ network is far from ideal.
3. No database encryption
Azure Multi-Factor Authentication Server uses its own phonefactor.pfdata file to store its settings and directory. There is an ingenious replication mechanism to keep this file up to date (that actually involves copying complete copies of the file around) so you don’t really have to worry about database corruption.
Unless someone writes ‘Sander was here’ in this file. Who would do such a thing, right!? Oh wait. I actually would (and did) for Disaster Recovery purposes.
Upon opening the phonefactor.pfdata file on several Multi-Factor Authentication Servers, however, I found that several of the pieces of information are actually simply stored in plain text in this file. (just scroll down a bit and you’ll come across your user definitions).
For a security product, this is far from ideal.
4. No API or PowerShell
Remember Microsofts 2009 Common Engineering Criteria (CEC)? It requires every product to have PowerShell support. Azure Multi-Factor Authentication Server doesn’t have that. We’ve searched long and hard for application programming interfaces (APIs) we could use for our purposes, but didn’t find any either.
Basically, this means that the Azure Multi-Factor Authentication Server Administration Console and the Web Portals are the only ways to manage Azure Multi-Factor Authentication Server. Installing the Administration Console only requires a full installation, so we can safely conclude that remote management of core functionality boils down to RDP’ing into the primary Azure Multi-Factor Authentication Server.
For user management, the User Portal offers delegated and granular management to Service desk personnel.
5. No Azure MFA Server Health
My implementations of Azure Multi-Factor Authentication Server have shifted over the previous couple of years from offering RADIUS and IIS authentication to AD FS integration. It’s been a fun ride, but I’ve seen Microsofts Identity Division make great improvements in the Hybrid Identity stack, where they’ve left Azure Multi-Factor Authentication Server in the dark.
Azure AD Connect Health offers centralized monitoring, reporting and troubleshooting in one Azure-based dashboard for Azure AD Connect installations, Web Application Proxies, Active Directory Federation Services (AD FS) and Active Directory Domain Services (AD DS), but not for Azure Multi-Factor Authentication Server.
Single Pane? Single Pain.
6. SIEM and TSCM are hard
Azure Multi-Factor Authentication Server offers logging. Its logging capabilities are granular and its log entries are concise. However, every component on every Azure Multi-Factor Authentication Server is logged into its own plain text file and log rotation is based on file sizes.
We’ve spent weeks at a customer building a centralized Technical State Compliancy Monitoring (TSCM) solution for their eight Azure Multi-Factor Authentication Servers and plugging into their centralized Security Information and Event Management (SIEM) configuration: While user auditing in Azure Multi-Factor Authentication Server is very mature and even offers SYSLOG integration, auditing configuration changes is hard.
7. No programmatic queue monitoring
One of the technical limitations we’ve regularly hit at customers is the length of the authentication queue on the side of the Multi-Factor Authentication Provider in Azure. When phone-based and text-based authentication requests are in this queue for too long, the authentication request times out and end-users can’t log on.
There is no programmatic way to get access to this queue. It’s displayed in the PhoneFactor portal, but having someone refresh this page three times per minute surely isn’t my definition of actively managing the authentication queue…
8. Azure Multi-Factor Authentication still lives in the old Portal
While large portions of Azure Active Directory and its related Identity solutions have moved to the new ‘Ibiza’ portal, the Multi-Factor Authentication Provider that Azure Multi-Factor Authentication Server relies on, is only available in the Azure Management Website, or as many have come to refer to as ‘the old portal’.
9. No support for RSA Tokens
Yes, Azure Multi-Factor Authentication supports hard tokens. It’s great!
Except for the fact that it doesn’t support the one hard token almost every organization has entrenched themselves with in my neck of the woods: the RSA token.
Azure Multi-Factor Authentication supports OATH-based hard tokens, like the ones from Gemalto, Yubico, Feitian, Secutech and Vasco.
10. You’ll need (at least) two MFA Solutions
Azure Multi-Factor Authentication Server does not protect Windows interactive logons. While this seems like an edge case, the ‘Windows Integrated Authentication’-feature to protect web-based applications often gets misunderstood as doing this.
The Azure Multi-Factor Authentication Server User Portal always requires people perform multi-factor authentication. In delegated admin scenarios, these admins need to perform multi-factor authentication every time they log on to help a colleague or customer. This makes sense. However, admins using the Server Management Console and RDP’ing into the box(es) to manage the Azure Multi-Factor Authentication Server configuration, do not have to perform multi-factor authentication.
You can use Azure Multi-Factor Authentication Server to protect these admin logons by making them use the RDS Web Gateway, but this won’t do you much good, when you want your admins to fix a broken Azure Multi-Factor Authentication configuration: they wouldn’t be able to go in.
Therefore, you’d need at least two Multi-Factor Authentication solutions, where each solution protects the admin logons to the management of the other solution.