I have a Windows PC joined to Entra ID and need to connect to it through Remote Desktop using a local account. The account exists, is enabled, and has been added to the Remote Desktop Users group. However, the connection appears to authenticate against the Entra domain instead of the local computer. I have tried both .username and hostnameusername, but the login still fails with an invalid-credentials message and shows the Entra sign-in identity. I am using a custom .rdp file with settings such as authentication level:i:2, enablecredsspsupport:i:0, and prompt for credentials:i:0. Local security policies allowing network access and Remote Desktop logon appear to be configured correctly. What is the correct way to force RDP to use the local account?
3 Answers
Edit the .rdp file in a text editor and keep the authentication settings explicit, for example authentication level:i:2 and enablecredsspsupport:i:0. Then enter the username as .username or COMPUTERNAMEusername when prompted. If credentials are cached, remove the saved entry from Windows Credential Manager before testing again; otherwise the client may continue submitting the Entra account despite the username shown in the file.
Double-check the local security policy settings, especially Deny access to this computer from the network and Deny log on through Remote Desktop Services. Local accounts can be blocked by either policy even when they are members of Remote Desktop Users. Also verify that the account has permission through the local Remote Desktop Users group and is not being overridden by a domain or device policy.
Use the computer name followed by the local username, such as COMPUTERNAMEusername, rather than relying on the client to infer the account scope. Also check the Remote Desktop client's advanced settings and disable the option to use web or Entra credentials. That can cause the client to keep presenting the Entra identity even when a local username was entered. Confirm that the account is in Remote Desktop Users and that it has a nonblank password.
I tried COMPUTERNAMEusername already, but the client still presents the Entra identity. Disabling web credentials may be the part I was missing.
Those deny policies are already clear, so the remaining issue appears to be the client forcing the Entra credential provider rather than a permissions problem.