Last Friday, I packed up the tiny but nifty Lenovo ThinkCentre Neo 50q to ship it back to North Carolina. Then, I stood the small but mighty ThinkStation P3 Ultra Gen2 up in its place. When I tried to RDP into that machine to catch it up with changes since it went dark in early January, it wouldn’t let me log in with my usual MSA. “I’ve seen this before,” I thought, as I recalled my Feb 19 blog on this very topic. That previous fix had changed the folder name for my user account and I wanted to avoid that on the P3Ultra2 if possible. So, I took another take on failed RDP login fix and came up with something better. Let me explain…

Details: Another Take on Failed RDP Login Fix

The P3 Ultra2 had been healthy after its identity‑stack cleanup, TPM reseal, and scheduled‑task repairs. Local login worked. The system was stable. Nothing in the logs suggested trouble. But RDP refused to authenticate. Every attempt failed with the same unhelpful message: “The credentials did not work.” The username was correct. The password was correct. The account was enabled. The SID matched. The machine was healthy. Yet RDP would not accept the credentials under any circumstances.

When this kind of failure presents, there’s usually some mismatch between the local Windows identity and the identity info RDP uses for remote validation. TL;DR version: that was exactly what went wrong.

Why Correct Credentials Failed RDP Validation

The key understanding requires knowing how RDP handles MSAs. When a user signs into a Windows PC locally, her or she can use Windows Hello, a PIN, or security tokens. That said, RDP cannot use any of these for remote login validation. Indeed, RDP requires a local NT password hash stored in the SAM on the target PC. If no such hash exists, RDP can’t validate user login input, even if the supplied password for an MSA is correct and current.

Here’s what went wrong on P3Ultra2: the MSA acccount had never generated a local password hash. From the first login, Windows 11 used Hello-based authentication. Alas, that means the SAM never got a password hash for that account. Locally, things worked as expected (because Hello could — and did — work with cloud based authentication). RDP could find no password hash and thus could not authenticate.

The Fix Is In, and Dead Easy

All I had to do was to sit down in front of the P3Ultra2 and force it to use the password for a single login. I did so at the lock screen by clicking the password icon (middle position in lead-in graphic) and then typing in the account password.

As soon as I did that, Windows automatically generated the NT password hash for that MSA. With that value now available, RDP immediately opened its remote access doors on my next try to get into P3Ultra2 through the Remote Desktop Connection App. Problem solved.

Sometimes, problems in Windows-World are huge and hairy. Sometimes, they’re astoundingly simple — as long as you can figure out what’s really going on. This particular RDP thing fell into the latter category. I’m glad I now understand, and gladder still it’s fixed.

Every so often, I run into Windows 11 behavior odd enough to make me scratch my head. Occasionally, I’ll observe that my Microsoft Account (MSA) logins work perfectly at the local console. But they fail constantly if used within Remote Desktop Connection. The error? A familiar one: ‘Your credentials did not work. The logon attempt failed.’ Today, I’ll explain what worked for me when fixing failed MSA remote login.

In the meantime, I’d been working around this issue by setting up a Local account named “LocalOnly.” You can see it mentioned in the lead-in graphic for this blog post. If my upcoming technique doesn’t restore your MSA’s remote access as it did mine, you can use a local account to remote into a balky remote host if your MSA won’t work.

Refusal of Known, Good, Working Login

You may see this message while trying to RDP into a Windows 11 machine using an MSA. If so, you know how frustrating it is. Especially when you know those credentials are correct, and you can use them locally, no problem. What gives?

As it turns out, the answer lies in a complex and sometimes fragile identity stack that underpins Windows 11’s user authentication . Let’s unpack what’s going on under that hood.

Windows 11’s identity model for MSAs is built on three interdependent layers:

1. SAM (Security Account Manager) – The local account database. It stores user SIDs (Security Identifiers) & basic account metadata.
2. WAM (Web Account Manager) – The token broker that handles cloud authentication for MSAs. It’s responsible for storing and refreshing tokens so services like RDP can validate your identity.
3. Ngc (Next Generation Credentials) – This layer handles Windows Hello and TPM-tied credentials, like PINs & biometric logins.

When all these layers are working and cooperating, things go swimmingly. Sometime though, particularly on Insider builds where MS is messing with this identity stack, things can get weird. Over time changes can mean an MSA works locally but not remotely.

A Swicheroo Is Key to Fixing Failed MSA Remote Login

Here’s what was happening on my ThinkPad X380 Yoga. I could log in locally using my MSA. But RDP logins would consistently get refused with the error message that serves as the lead-in graphic. After ruling out more obvious causes (e.g. network issues, RDP settings, firewall rules) I thought about the situation. Because local login worked, SAM and Ngc layers were probably OK. That presented WAM as a likely cause.

The fix, then, was simple. I rebuilt the WAM token cache, to make sure all pieces harmonized. Here’s what I did:

1. Log in locally using MSA
2. Visit Settings > Accounts > Your info
3. Change to “Sign in with a local account instead”
4. Sign out, or Reboot PC
5. Login locally using local account name/pwd
6. Visit Settings > Accounts > Your info
7. Change to “Log in with a Microsoft account”
8. Reboot PC

The switcheroo undid the link between the MSA and the account, made it local, then re-established a new connection. That completely rebuilds the whole infrastructure, including the WAM.

After that switcheroo (MSA > Local > MSA) RDP worked fine from my Flo6 primary desktop into the X380. The odds are good this technique will work for you, if you get caught in this situation. Here in Windows-World, a switcheroo sometimes works wonders. It did here, anyway!

Yesterday was Patch Tuesday. This morning, I checked over the fleet to make sure all had gone well. With one exception — the Lenovo ThinkPad P16 Gen1 — it had. But the P16 showed me a restart behavior I’d never seen before.  Indeed, I can only observe this machine experienced an odd restart following KB5074109. Let me explain what happened…

Delineating Odd Restart Following KB5074109

Some of this oddity is no doubt self-induced. I fired off the restart command in Windows Update through an RDP session. That closed the remote desktop session on the client. On the P16 host, the logged-in Windows session kept running. The desktop stayed visible, and the Start menu popped up in response to the usual cursor activity. But apps didn’t work, and I couldn’t open settings to fire off the restart command again. Even more interestingly, the power button in the Start menu didn’t work either. How to force a restart?

WinKey-X let me open an administrative Windows Terminal session. From there I used shutdown /r /f /t 0, where /r tells Windows to restart, /f summarily kills any open apps that might otherwise block restart (seemed like a good idea to me, given circumstances), and /t 0 tells shutdown to do its thing right away (in 0 seconds, that is).

That did the trick! The P16 transitioned into an “Updates underway” screen that let me know the pending updates were being applied. Then it restarted, finished the post-GUI update process, and took me to the desktop.

How do I know it worked? Edge popped up the now-customary post update browser window as the P16 finished booting to the desktop:

Problem solved, I guess. I’m not sure what caused this strange behavior. I didn’t see this on any of my other updated PCs or VMs, But then I didn’t have RDP sessions open into them at the time, either. Just another niggling little mystery here in Windows-World. Just another normal day…

I’m not sure when the change I’m about to document happened, but I just noticed it this morning. Last night before heading off to bed, I put my production desktop to sleep. At the time, I had 3 RDP sessions running elsewhere on my LAN. When I logged in this morning, instead of finding 3 Remote Desktop Connection prompts to re-establish those sessions, I found login prompts on lock screens into those sessions instead. This is a welcome RDP session handling change, as far as I can tell. I’m glad to see it.

Why Say: Welcome RDP Session Handling Change

As you can see, the lock screen snippet in the lead-in graphic shows my LocalOnly account. That’s a — you guessed it — purely local Windows account I use to establish RDP sessions into Windows 11 PCs that won’t let me log in using my preferred Microsoft Account (MSA).

When I saw that show up inside a Remote Desktop Connection session window (or three) this morning, I knew what it meant. It meant that MS kept the remote session ready to re-start, even though the client half of that session (my production desktop) had been asleep. That’s both good and convenient.

Copilot Sheds More Light

Copilot says that recent builds like 26200.6901 (what I’m running on the Flo6 right now) offer persistent RDP sessions across sleep/wake cycles. Instead of summary disconnection — the way things used to work — they now lock open RDP sessions (which is why I had to log back into them) and preserve memory state and open windows.

Good to know! This is what I call a nice surprise in Windows-World. Glad to see that MS has made this change: it makes my job easier.