Recently I decided to write up a couple of articles on how to set up MFA for a highly available RD Gateway. Why? Because so much information on the internet is fragmented and as such incomplete. So I wanted a reference document for myself. As I was making that document I realized I needed to explain the why and not just the how. The “why” is what helps people support and troubleshoot the solution during its life cycle.
The above, in combination with me being a verbose son of * led to 44 pages of information. So, I decided to publish it as a two-part article series.
If you have RD Gateway running and you have no MFA solution set up for it, I highly recommend you head over to read these two articles. That is especially true when your RD Gateways solution is a high availability (HA) deployment with an RD Gateway farm behind a load balancer. In that case, you want your MFA components to be HA as well! For some reason, so many guides on the internet ignore or brush over HA very cavalierly. That is one thing I hope these two articles remediate.
Next to that, it has many details on every aspect of the deployment to make sure you get it up and running successfully and correctly.
Finally, I present you with a collection of troubleshooting information and tools to help you figure out where the problem is so you can find a way to fix it.
That’s it. I really think it can help many of you out there. I hope it does.
Recently in a talk with a pen tester I was demoing an end-user security risk that is relatively new on the scene. Apps that automatically confirm MFA push notifications. This effectively bypasses conscious user interaction and approval of any login attempt secured with a push notification. Hence the Darwin award with MFA push notifications phrase was born.
The Darwin award with MFA push notifications
Just when some security people worried more about the people with push notification suffering from security fatigue as being the biggest risk we go step further. Never mind people accepting any notification like Pavlov’s dog in a semi-unconscious, conditioned action. They have even grown tired of this an turn to MFA bypass apps to handle this for them.
More then ever it seems that disabling any kind of self-service for device registration with MFA is key. On top of that, it is a sobering reminder that a strong password and conscious user actions are still very much key to providing security via MFA. I am not bashing DUO here. This was just the one I tested and it worked shockingly well.
I think for some people and organizations one or more FIDO2 keys will be the better option. Unless mobile device management can prevent people from installing auto-responder apps for push notifications you might have an issue. Or, they need to find a way to block such tools. Whatever I can come up with breaks the ease of use of push notifications but there are smarter and more knowledgeable people out there than me, so who know what they come up with. Microsoft Authenticator seems to have some capabilities to prevent this. I don’t know if you can enforce it 100% and if this cannot be bypassed in code as well.
This, however, does nothing against conditioned responses of pushing a button or scanning a fingerprint on a FIDO2 key. So, remain vigilant. The sobering fact is that the adoption of MFA is disappointingly low. And no matter how many scary MFA bypass stories your read MFA is a key aspect of securing access today. It puts you far ahead of the curve. If done well and with well thought out procedures it is a formidable barrier for but the most determined attackers. Actually MFA bypass attacks are very rare still. Most of us are not that interesting targets but it can help keep out the majority of casual or professional thieves looking for quick wins on easy targets.