Multifactor Authentication Server is not compatible with password sync?

I was recently asked for help implementing Microsoft’s Multifactor Authentication Server for an on-premises Remote Desktop farm.  There is a great resource on the web at RDS Gurus that steps you through this process.  Just for the sake of doing my homework, I decided to read up on more detail on Azure’s documentation library.* And wouldn’t you know it, look what I found:

It turns out, if you are using Azure AD Connect (formerly DirSync) with the password sync feature (this is like 90% of my client base), then the MFA Server is not going to be an option you.  Curious, isn’t it?  I plan to follow-up with whoever I can bug at Microsoft to figure out what the deal is here.  But this is what I suspect: the MFA server must rely on some data or tokens stored in your individual Azure AD tenant, right alongside your password hashes that are synced from the on-premises Active Directory.  Of course, this means that anyone who could compromise one could get at the other. A single trust domain for both factors of authentication = no bueno.

Seems like a miss on Microsoft’s part, doesn’t it?  Especially because they also have MFA in the cloud for their own Office 365 & other services (which must be using a separate provider). Therefore, I can enable password sync and MFA for my Office 365 users, no problem.  But I can’t then also enable MFA on-premises without either A) breaking password sync or B) implementing Active Directory Federated Services? What gives?

Of course, if you do decide to go with AD FS instead of password sync, your users still have the benefit of single sign-on, and in this case, there are really two separate trust domains.  Why? Because implementing AD FS with Azure AD means that any authentication request for Azure AD (logging into Office 365, etc.), really just redirects that request back to your on-premises AD servers; the password data is kept on-premises, while the MFA provider remains in Azure AD as always. Therefore an attacker would need to gain access to both your on-prem AD servers as well as your Azure AD tenant in order to break through the MFA.

So why complain? If you want MFA on-prem, just go with AD FS, right?

No–not okay. AD FS is stupid for many small organizations, because it creates a strong dependency on your local Active Directory.  In other words, if your office building loses power, and the server closet goes down for a few hours, nobody in the org can get into their cloud email accounts. Dumb. The fact that the cloud operates even when your building’s power is out is in fact one of the primary benefits/features that my clients love so much about Office 365.

“Well Alex, why don’t you just put those servers in Azure, instead?!”

Yup. That’s right. More carrots leading us into Azure. I don’t necessarily oppose the idea of putting a small company’s virtual machines in the cloud. However, I know that most small companies I have pitched this to tend to turn tail and run back to on-prem Hyper-V when we pull up the calculator and plug in two of every VM to qualify for the Azure SLA. It doesn’t help when we explain that, by the way, Virtual Machines in the cloud are really great, however they don’t do you too much good unless you can connect to them.

The “basic” Virtual Network provides a sad little VPN (that really just uses Windows RRAS in the background). You can improve this somewhat, but going to something like ExpressRoute adds more cost and isn’t always available.  But what you really want is probably Azure Remote App, rather than VPN (or in addition to VPN). So yes, you need to buy another product too.

I have a better idea–why don’t you just provide me with a separate trust barrier for that on-prem MFA provider?  Would that do the trick?

Nevertheless, until such a day arrives (it may never) there will probably be instances where we need to provide hybrid MFA–some for cloud-based resources such as Office 365, and also for on-premises applications such as Remote Desktop Services. So the ideal infrastructure to accommodate this scenario would be one of two options:

1. Office 365 with cloud-only authentication (no password sync + MFA Server on-prem), OR
2. Office 365 with AD FS, keeping a pair of AD/DNS/AD FS servers in an Azure Virtual Network, with basic VPN to your on-prem location(s).

Option 1 is free, and will not increase your monthly cost. But it does mean that your passwords will become separate. Option 2 allows you to keep using the same passwords on-prem and in the cloud, but adds ~$150.00 USD + per month to your cloud services bill (depending on options). If you are using Azure Backup or Azure Site Recovery (other additional costs associated with these services), then having this Virtual Network in Azure where you already run AD + AD FS will be of some benefit during a Disaster Recovery scenario. So you could potentially get that investment working for you in a couple of different directions.

*A word to the wise–don’t just go following everything you read on the blogosphere without cross-checking that information against primary sources.  Make sure that the conditions in your own environment line up with the assumptions being made in the articles you read–the real world is full of variables, so stay diligent.