Today could be a red-letter day for me. I’ve finally figured out how to use an MSA (Microsoft Account) to login to RDP on certain “problem” PCs. I even now understand what made them problematic, and how to fix things. And in the process, my odd MSA RDP login issue resolved itself. Hooray!

Let me explain an odd combination of circumstances that caused this situation to show up on certain laptops. Buckle up: it’s a bit convoluted.

How the MSA RSP Login Issue Resolved Itself

One of the more outstanding online sources of esoteric admin wisdom is a website named SuperUser.com. I found a reference to an item therein entitled Windows 10 Remote Desktop Credentials at another of my favorite haunts, ElevenForum. That item Unable to Access w/Remote Desktop until a Local Logon w/Password is Performed pretty much summed up what I was struggling to resolve.

Here’s the deal: for RDP to be able to use an account/password combination for remote access, that hashed data must be in the target PC’s password cache. If one only logs into that PC directly using a PIN, Windows Hello (or other biometrics), or a security token, that data never hits the cache. If that data isn’t cached, the remote login can’t authenticate and you can’t get into the PC that way. The local account technique works because it does have that data available, and thus it can serve to let the remote user in.

Where Things Get Interesting…

There’s a high-security Account setting in Windows 10 and 11 that falls under Settings → Accounts → Sign-in options that reads “For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device (Recommended).” If you elect this option, you cannot login to that PC using a password. If you can’t login to the PC using a password, that info can’t make it into the cache. And then, as a side-effect, you can’t use that account to login to RDP.

So I had to disable the option,  and use the password to login locally for my chosen MSA. After a restart, I was indeed able to use that same MSA and its associated password to login to a remote session using RDP. Then I re-enabled the option and proceeded on my merry way. Problem FINALLY solved!

Just goes to show: if it ain’t one thing in Windows, it’s almost always something else. And this was “something else” indeed. Glad to have it fixed, and somewhat better understood…