There was an internal discussion going on about folks getting too many MFA prompts when they're using RDP. I've danced around this topic quite a bit in past threads, but maybe let's take a look at it: how MFA works in Windows.

In Windows-land MFA comes in all sorts of flavors. Often what folks see is just a second field on the Windows logon screen to enter a one time password or send a request to their phone to approve before being taken to your desktop.

This is not MFA. I mean, it is MFA in the sense that you're providing two factors, but in fact it's not MFA because the authority you're communicating with only ever sees a password. This is a critical distinction.

See, in this scenario you're unlocking your device using the second factor. That's all well and good, but the majority of the things you're doing on your machine actually require communication with other services...not on your machine.

How were you authenticated to those services? If it's an internal service then that means Kerberos or NTLM. The only way you can authenticate to AD for either of those protocols is through password or certificate.

If it's an external service protected by AAD then you're using OAuth. AAD OAuth understands many credential types. Which one did we use?

That's bad.

Well, the logon screen asked for your password and you hit a button on your phone to approve the logon so chances are quite good that you're authenticating to AD or AAD with...just a password.

But, the thing is, Windows doesn't really care how you authenticated. I mean, it does, but the internal mechanics aren't doing authorization checks, yet.

What it boils down to is the authority that Windows trusts just blessed your logon, so you're now at the desktop doing stuff. Windows *then* limits access to things on your machine through authz rules that are driven by the contents of the ticket returned by the authority.

Put in more technical terms the ticket from AD contains a list of SIDs. Things in Windows are ACL'ed against SIDs, so when checking if you have access to stuff, Windows checks your SID list and gives a yay/nay. Other machines do the exact same thing when you connect to them.

These SIDs that are put into the ticket are derived from your group membership as well as derived from the credential you used to authenticate yourself. Password is the baseline and gives you nothing special, and there's no way to tell AD that you did password + superduperMFA.

Therefore in order to do MFA in Windows *and* have it represented to other services, you need to use a method that your authority understands.

Active Directory understands exactly one(-ish) other factor: certificates.

This means you can authenticate using smart cards or using Windows Hello.

AAD understands more. It understands certificates, FIDO, and the mobile authenticator. This means you can [sorta] use smart cards (sorta), Windows Hello, FIDO key, or push authentication to get the MFA blessing. Windows and AAD together understand just a subset of that though.

So back to the internal thread. Folks are working from home and need to RDP to their work machine from their home machine. The problem is that they're getting a bunch of MFA prompts on the remote machine whenever they do anything. What gives? They're using MFA, right?

The problem was that MFA was being enforced outside of Windows, before RDP kicked off so the machine they were remoting in to only ever saw a password.

But Steve, why weren't they using Windows Hello?? Well, because it was their home machine. You can't get an organization-stamped Windows Hello credential put onto your home machine. It just ain't working that way.

So they connect to a service that prompts for MFA and gives you an RD Gateway that can forward your request to the internal machine. To be clear: this is a secure process. To get to the gateway you need to MFA, there's no two ways about it.

But now that you've passed the MFA check you can securely use a password to RDP. Windows only ever sees the password, so AD never stamps your ticket with the certificate or Windows Hello SID (technically there is no SID for either, I'm glossing over part of this machinery).

It's a hybrid joined device so it reaches out to AAD to get a PRT. This process also sees its just a password so it doesn't stamp the PRT with the MFA claim. Then you try and access a resource that enforces MFA, so AAD checks the PRT for the MFA claim and whoops no claim. Prompt.

Ten minutes later you access another resource that enforces MFA, so AAD checks the PRT for the claim and whoops still no claim. Prompt.

Repeat ad infinitum.

This is why remote access is super difficult to get right, where you're balancing usability with security. Everything in the chain needs evidence the previous thing was authenticated to with MFA, otherwise everything further in the chain will prompt for it.

Obviously the answer then is to make Windows understand all the things. Well, which things? Which protocols? Which standards? Which vendor extensions to protocols?

Well, and then I guess make RDP understand them too. And all the RDP clients on Mac and Linux, and oh we have this HTML-based version too.

It's hard work.

So the goal then is to converge on only a couple standards and well known implementations and just try and get everyone to play nicely together. It's the only rational approach.

All of this adds up to the question: how do you do remote desktop securely then?

You need MFA, full stop. Protecting the gateway with MFA is a must. You need to also enforce MFA (or some derivative policy) on all the services you use.

At that point you need to ask if being inundated with MFA prompts is a great user experience or if its leads to prompt blindness?

You can solve that by transferring the MFA state from the client to the target machine by using a strong credential like smart card or Windows Hello.

Windows Hello is amazing technology that folks love to use and works beautifully on work machines connecting to work machines. But it's not suitable when you're on your home machine. Smart cards work great though.

FIDO is an amazing technology and it solves so many problems, but its not quite ready for RDP yet. We'll get there.

Anyway, remote access is hard. I have no other closing thought. Good luck.