This post is part of a series, for the series contents see: Azure MFA
I’ve got an MFA auth provider setup now, so I guess, technically, I could start using it for cloud based accounts, but what I really want to do is use it with my on-premise domain identities. For that, the easiest thing to do is setup ADFS.
There are two methods to combine ADFS with Azure MFA, essentially an old way and a new way. The old stems from the fact that when Microsoft released Azure MFA the didn’t quite nail their colours to the mast and ended up with this weird halfway house of essentially two products:
- Cloud based Azure MFA
This is what we’ve setup so far and is used as an extra layer of protection for cloud based services.
- Azure MFA Server (i.e. the old way)
This is a server based product designed to protect on-premise applications and resources, including the ability to RADIUS offload devices such as firewalls to it to apply multi-factor for things such as VPN access.
My experience with the MFA server product hasn’t been good and I don’t have a good impression of it. Technically the product isn’t that smooth to configure, it’s obviously early on in an Agile process and has a lot to improve. It’s very cumbersome to setup and kind of reminds me of the Bitlocker product from a few years ago which seemed far from polished (I assume it’s a lot better nowadays).
However, whereas I’m always happy to overcome technical inadequacies where the real problem lies with the server product is its fundamental mentality and design which I’ll try to sum up in a few bullet points:
- Using the MFA server product requires you to first setup an Azure based auth provider, after which you get the option to download the product. Then, when you install it, the server will register with the Azure based auth provider and appear in your cloud dashboard. The reason for this is that the server product offloads the MFA process to the cloud based product which begs the question: is this a truly on-premise solution? It doesn’t seem to have made up its mind.
- In reality I don’t care that it uses the cloud auth provider. In fact, from my perspective, that’s great as it’s one less on-prem component to nurture, upgrade, or worry about. It’s this next point that I find really weird: the server product requires users to register with the MFA server and go through a setup/enrolment process.
You might ask: “So? What’s the problem with that?”
Well here’s the scenario where I think it doesn’t make sense:
As a business you’ve implemented Azure MFA to protect you Azure admin users and O365 accounts. You’ve rolled it out across the business and everyone has gone through the enrolment process of setting up SMS, voice calls, or the Microsoft Authenticator app as their 2nd factor of authentication. Across a large business with varying use cases, and people using all sorts of mobile devices, this can be a painful, helpdesk heavy process.
At this point, you decide that you also want to apply Azure MFA to your VPN connectivity or an on-premise app so you install the MFA server product. In an ideal world it would be as simple as telling the business “from now on VPN and app “X” will also require you to use MFA as you do with O365″. In reality, you’re going to have to get all of those users to go through yet another enrolment process to register with the MFA server and choose their 2nd factor of authentication again: SMS, voice call, or Microsoft Authenticator App.
It seems crazy to me that you’re going to have to go through all of that pain again, despite the fact that you know that the server product is talking the the Azure based MFA provider in the background. It offloads the auth process there but doesn’t care whether or not the user has already enrolled for Azure MFA using that cloud service.
Cloud and server are treated as two separate things whereas I think you should have the option of taking the offload a step further so you can take advantage of any roll out work already done so far.
OK, at this point I’m very aware that whilst I started off talking about ADFS I’ve gone off at a tangent by ranting about the MFA server product so I’ll try now to join those two things back up and get this post back on track!
The crux of the issue is that in the past if you wanted to add in Azure MFA to protect sign-in to products via your ADFS farm you would have had to have installed the MFA server product. It was marketed as the ADFS Azure MFA add-in but in reality that add-in was just a way to point ADFS authentications at you on-premise Azure MFA server. Which, again, would mean that your users would have had to have enrolled with that on-premise server in order to use it. That was the case with ADFS 2.0 and 3.0 on Windows Server 2012 (R2), but with ADFS 3.0 on Windows Server 2016 that is no longer the case!
It seems that Microsoft have come to the same realisation as me because ADFS on Server 2016 now gives the option of using MFA that offloads to your cloud setup rather than having to use the on-premise server option.
Over the next few posts I’m going to test that out by building up a server 2016 ADFS environment.