Can't login via RDP with my @live.com account

Hi Greg Hawthorne,

By default, Windows 11 forces "Windows Hello" (PIN/biometrics) for Microsoft accounts and disables standard password authentication. RDP, however, requires a standard password to authenticate over the network. Chrome RD bypasses this because it operates completely differently at the application layer.

Here is the practical way to fix this without messing with security policies:

1. Disable the Windows Hello restriction: On the host PC, go to Settings > Accounts > Sign-in options. Scroll down to "Additional settings" and turn OFF the toggle for: "For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device".

2. Cache your password locally (Crucial Step): Lock the host PC (Win + L). On the lock screen, click "Sign-in options" and choose the Password icon (not the PIN icon). Log in using your @live.com password. This forces Windows to cache the actual password hash needed for RDP.

3. Use the correct RDP username format: When connecting from the client machine, do not just type your email or local account name. Enter the username exactly like this to force the Microsoft Account provider: MicrosoftAccount\******@live.com

Do this, and your RDP should connect immediately. If this resolves your issue, please click "Accept Answer".

Tracy Le.

Hi Greg Hawthorne,

It almost always happens because Windows temporarily drops the Wi-Fi connection on the lock/login screen, meaning it literally cannot reach Microsoft's servers to verify your password hash for the first time. Here is how to get past it:

1. The Quick Fix (Force the network): While you are on the lock screen, look at the bottom right corner. Click the Network icon and manually force it to connect to your Wi-Fi (or temporarily plug in an Ethernet cable). Once you visually confirm it has an active internet connection on that specific screen, try entering the password again.

2. The IT Pro Alternative (Bulletproof RDP): Honestly, using a Microsoft Account for RDP is notoriously fragile precisely because of NLA and Hello conflicts. The most stable, headache-free way to handle this is to create a dedicated Local Admin account just for remote access.

Open Command Prompt as Admin and run: net user LocalRDP YourSecurePassword! /add net localgroup Administrators LocalRDP /add

Now, just RDP into the machine using .\LocalRDP as the username. It completely bypasses all Microsoft Account sync issues.

Try forcing the network on the lock screen first, but keep the Local Admin route in your back pocket.

The most likely cause is that the Microsoft account–based admin user doesn’t have the required Remote Desktop logon rights, or is being blocked by local or domain security policy.

Check and fix the RDP logon rights on the Windows 11 Pro machine:

1. Add the account to Remote Desktop Users
   1. Press Win + R, type lusrmgr.msc, press Enter.
   2. Go to Groups.
   3. Open Remote Desktop Users.
   4. Add the account that corresponds to the admin profile (for a Microsoft account this may appear as the local mapped name rather than ******@live.com).
2. Verify local security policy for logon rights
   1. Press Win + R, type secpol.msc, press Enter.
   2. Go to Local Policies > User Rights Assignment.
   3. Ensure the account (or a group it belongs to, such as Administrators or Remote Desktop Users) is included in:
      • Access this computer from the network
      • Allow log on locally
      • Allow log on through Remote Desktop Services
   4. Ensure the account (or its groups) is not included in:
      • Deny access to this computer from the network
      • Deny log on locally
      • Deny log on through Remote Desktop Services
3. If joined to a domain, check Group Policy If the PC is domain-joined, domain GPOs can override local settings:
   1. On a domain controller, open Group Policy Management.
   2. Edit the relevant GPO (for example, Default Domain Controllers Policy or another applied GPO).
   3. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment and confirm the same allow/deny settings as above.
   4. In Active Directory Users and Computers, confirm the user or group is a member of Remote Desktop Users and that GPO inheritance is as expected.
   5. On the client, run:

            gpupdate /force
      

      and then test RDP again.
4. Check effective policy Generate an RSoP report to confirm what’s actually applied:

      gpresult /h report.html
   

   Open report.html and verify the logon rights under Computer Details.
5. Network Level Authentication (NLA) If the client or account has issues with NLA, temporarily disable NLA on the remote machine to test:

      Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "UserAuthentication" -Value 0
   

   Then try connecting again. If it works with NLA disabled, review account credentials and client version, then re-enable NLA once resolved.

These steps address the common causes where an account (including one originally created from a Microsoft account) cannot sign in via RDP even though it works locally.

References:

• "The system administrator has restricted the types of logon" error when connecting to a computer
• Troubleshooting access denied and user not authorized issues in Microsoft Remote Desktop Services