| name | windows-rdp-login-troubleshooting |
| description | Diagnose and fix Windows Remote Desktop (RDP) login or connection failures, especially over Tailscale/VPN and especially for PCs signed in with a Microsoft account. Use this WHENEVER the user reports RDP trouble on Windows — "RDP 로그인이 안 돼요" / "remote desktop credentials rejected" / "자격 증명이 작동하지 않습니다" / "can't connect to my PC over Tailscale" / "Windows Hello only sign-in blocks remote login" / PIN-vs-password confusion / NLA failures / "remote desktop keeps disconnecting after a few seconds". Covers the read-only diagnostic sweep (RDP enabled, TermService, port 3389, firewall incl. localized rule names, NLA, account type/admin/lockout, Tailscale), the crucial "can't connect vs credentials rejected" fork, Microsoft-account gotchas (DevicePasswordLessBuildVersion / Windows-Hello-only toggle needing a reboot, username format, passwordless accounts, stale cached password), event-log forensics, and account-lockout confounders. Trigger even if the user doesn't say the word "RDP" but clearly can't remote into a Windows box. |
Windows RDP Login Troubleshooting (Tailscale / Microsoft account)
Why this skill exists
RDP failures split into two completely different problems that look similar to a
frustrated user but need opposite fixes:
- (A) Can't connect — the client times out / "can't reach the computer."
Root cause is network, firewall, service, or Tailscale.
- (B) Connects, but login is rejected — you reach a credential prompt and it
says "자격 증명이 작동하지 않습니다 / The credentials that were used to connect
did not work." Root cause is authentication/account, not the network.
Guessing wastes time and can lock the account. Gather read-only evidence
first, identify which branch you're in, then fix the root cause. Do not change
any system setting until the evidence points at it.
The single most common hard-to-spot root cause on modern Windows 11 is the
"Windows Hello sign-in only" toggle for Microsoft accounts — it rejects a
100%-correct password over RDP and needs a reboot after being turned off.
Keep it top of mind for branch (B).
Step 0 — Run the diagnostic sweep (read-only, safe)
Run the bundled script. It makes no changes and prints everything needed to
pick a branch:
powershell -ExecutionPolicy Bypass -File "<skill-dir>\scripts\diagnose-rdp.ps1"
If the current shell is not elevated, the Security event log section will be
unreadable — that's expected; note it and continue. Everything else works
unelevated.
Read the output, then map it against the checks below.
Step 1 — What "good" looks like (host side)
| Check | Healthy value | Meaning if wrong |
|---|
whoami | PC\user | confirms which account/computer you're on |
RDP enabled (fDenyTSConnections) | 0 | 1 = RDP turned off → enable it |
TermService | Running | stopped → start it / set to Manual+trigger |
| Port 3389 listening | 0.0.0.0 + :: | not listening → service/RDP off |
| Firewall RDP rule | Enabled, Allow, applies to the connecting profile | blocked → see Branch A |
| Edition | Pro/Enterprise/Education | Home cannot host RDP (no incoming) |
| Account | enabled, Administrator or in Remote Desktop Users | else not authorized |
Localization gotcha (important): never search firewall rules by the English
name "Remote Desktop" on a non-English Windows. On Korean Windows the rule is
원격 데스크톱 - 사용자 모드(TCP-In). Always match by port 3389, which is
language-independent (the script already does this). A "no rules found" result
from an English-name search is almost always a false negative.
Step 2 — Pick the branch: connect vs. credentials
Determine the exact client-side symptom (ask the user if unknown — it's the most
decisive single data point):
- "연결할 수 없습니다 / can't connect", never reach a password box → Branch A.
- "자격 증명이 작동하지 않습니다 / credentials did not work" after typing the
password → Branch B.
- "내부 오류 / internal error", or black screen then drops after a few
seconds → usually transport/NLA → start with Branch A (MTU/Tailscale), then B.
Confirm with the host event logs (the script pulls these):
TerminalServices-RemoteConnectionManager/Operational 261 = "listener
received a connection" → the client did reach this PC (rules out pure
network/firewall to the box).- 1149 in the same log = "user authentication succeeded." Its absence
across all attempts = no successful auth yet.
LocalSessionManager/Operational 21/25 = a session actually logged on.
Absent = no successful session.RdpCoreTS/Operational error 64 / 0x80070040 (ERROR_NETNAME_DELETED) =
the TCP socket dropped. With NLA this commonly appears as a side effect of a
credential rejection (client tears down the connection) — so error 64 +
"credentials did not work" still points to Branch B, not transport.
Branch A — Can't connect (network / transport)
Work outside-in:
- Tailscale up on both ends.
tailscale status — is this node online, and
is the client device online (not "offline, last seen …")? Connect to the
tailnet IP (e.g. 100.x.y.z) or MagicDNS name.
- Firewall allows inbound 3389 on the profile of the incoming interface.
Tailscale's adapter usually classifies as Private; the LAN/Ethernet may be
Public. Make sure the RDP rule covers that profile (
Profile = Any covers
all). Check Get-NetConnectionProfile.
- Port listening / service running (Step 1).
- MTU / large-packet drops over the tunnel. Symptom: connects then dies in a
few seconds, black screen, error 64, "internal error." Test plain reachability
Test-NetConnection <tailnet-ip> -Port 3389. If TCP connects but RDP stalls,
suspect MTU; try the RDP client option to use a lower connection quality, or
investigate Tailscale MTU.
Branch B — Connects but credentials rejected (Microsoft account)
This is where most real-world cases land. Check causes in this order — the
first ones are both common and invisible:
B1. "Windows Hello sign-in only" toggle (most common, sneaky)
Registry: HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device
→ DevicePasswordLessBuildVersion.
2 = the Settings toggle "보안 강화를 위해 이 장치에서 Microsoft 계정에
Windows Hello 로그인만 허용" / "For improved security, only allow Windows Hello
sign-in for Microsoft accounts on this device" is ON. Password auth for
the MS account is blocked, including over RDP → a correct password is
rejected and often no 4625/4776 is logged (policy blocks it before
validation).- Fix: Settings ▸ 계정 ▸ 로그인 옵션 → turn the toggle off (or set the
value to
0), then REBOOT. Turning it off without a reboot leaves the live
LSA policy still blocking password sign-in — the registry reads 0 but RDP
still fails. The reboot is the part people miss.
# elevated
Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device' -Name DevicePasswordLessBuildVersion -Value 0 -Type DWord
# then reboot
B2. Username format
For a Microsoft-account PC, do not use the display name (chris) or
PC\name. Use the account email, and if plain email fails,
MicrosoftAccount\email@domain. Wrong format → "credentials did not work" even
with the right password.
B3. PIN ≠ password
RDP (standard NLA) cannot use Windows Hello (PIN/face/fingerprint). The user must
type the actual Microsoft-account password. People who only ever use a PIN
often type the PIN, or have forgotten the real password (reset at
account.microsoft.com).
B4. Passwordless Microsoft account
If the online MS account is passwordless, there is no password to present over
RDP. Add a password to the account, or use the local-account fallback below.
(Get-LocalUser <name> showing PasswordLastSet populated suggests a password
exists locally, but the online account can still be passwordless.)
B5. Stale / changed cached password — decisive isolation test
The PIN is device-bound and survives an online password change, so the user may
not notice the password they "know" differs from what the device accepts.
Test: on the physical machine, Win+L, then unlock using the password
option (not PIN).
- Fails locally too → the password itself is wrong/stale (not an RDP problem).
- Works locally but RDP fails → it's RDP/policy (revisit B1/B2).
B6. Authorization
The account must be enabled and either an Administrator or a member of
Remote Desktop Users. Admins are allowed by default; an empty Remote Desktop
Users group is fine if the user is an admin.
The lockout confounder (check before retrying)
Default policy may lock the account after N failed attempts. The script prints
net accounts (e.g. threshold 10, duration 10 min, window 10 min). Repeated
testing trips this, after which even a correct password fails for the
duration. Symptoms of a fix that "still doesn't work" are often just an active
lockout. Guidance: between attempts, wait out the lockout window and try
exactly once, don't hammer it.
Pinpoint the exact reason (elevated)
To distinguish wrong-password vs locked vs policy-block definitively, read the
Security log right after one failed attempt, in an elevated shell:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4776,4625,4740} -MaxEvents 5 | Format-List TimeCreated, Id, Message
Interpret the status/sub-status code:
0x0 success · 0xC000006A wrong password · 0xC0000234 account locked ·
0xC0000064 no such user · 0xC000006D generic failure.- No 4625/4776 at all despite a rejected login → consistent with the B1
policy block (reboot needed) — provided the log is actually readable (an
unelevated shell can't read Security and will misleadingly report "no events").
Reliable fallback: use a local account for RDP
If the Microsoft account keeps fighting (passwordless, policy, 2FA), the
guaranteed-working path is a local account: set a password on an existing
local user (or create one), add it to Remote Desktop Users (or
Administrators), and RDP with PC\localuser. This sidesteps all MS-account
policy entirely. Offer this when B1–B5 stall.
Notes worth telling the user
- Single session: on Windows Pro, RDP-ing in as the same user who is logged
in at the console disconnects the local session and moves it to the remote
— normal, not an error.
- Security: re-enabling MS-account password sign-in (B1 fix) slightly lowers
the device's posture. Over Tailscale the exposure is limited to the tailnet;
for tighter control, restrict port 3389 to specific devices via a Tailscale
ACL rather than exposing it broadly.
Order of operations (summary)
- Run
diagnose-rdp.ps1 (read-only).
- Confirm host basics are green (RDP on, service up, port listening, firewall by
port, edition Pro+, account authorized).
- Get the client-side symptom → choose Branch A or B.
- Fix the identified root cause. For B1, set value 0 AND reboot.
- Mind the lockout window — try once, not many times.
- If MS-account auth stays broken, fall back to a local account.
