Fix Remote Desktop Credentials Did Not Work [6 Methods]

Struggling with ‘Remote Desktop Credentials Did Not Work’ error? Discover 6 simple methods to fix it quickly and regain access.

Updated: 29 Oct, 25 by Lisa P 15 Min

List of content you will read in this article:

If you regularly work remotely with Windows systems, you've probably encountered the error "Your Remote Desktop Credentials Did Not Work." This error usually doesn't mean you entered the wrong password, but rather indicates an authentication or permission issue. In this step-by-step guide, you'll learn how to find the exact cause of this error, fix it, and prevent it from happening again in the future.

Have you ever tried to access a distant computer and received the annoying "Your credentials did not work" error? This is common when using Remote Desktop Protocol (RDP) and can bother you. But what is this error? Actually, this message indicates that the server's security settings denied your login attempt. This could be due to an invalid account or password, expired credentials, or more complex network or security policy difficulties. In the following sections, we'll look at the most prevalent reasons of this issue and tell you how to fix remote desktop credentials did not work.

To better understand the basics of RDP, you can read What is Remote Desktop Connection

Based on experience, over 90% of “Your credentials did not work” errors come from three main causes. Identifying them quickly helps you save time and focus on the right fix.

  1. Cached or Outdated Credentials (Client-side): This is the most common cause. Windows stores your login details in Credential Manager. If your password has changed but the cached entry still holds the old one, the server will reject your credentials and show this error.
  2. Incorrect Username Format: The RDP protocol and Active Directory authentication are sensitive to how the username is written. Using the wrong format such as DOMAIN\user instead of user@domain.com or the other way around can cause login failure even with the correct password.
  3. Insufficient Server Permissions (Server-side): If the user is not a member of the Remote Desktop Users or Administrators group on the target computer, the server will deny the remote session.

For professionals troubleshooting urgent issues, the table below summarizes quick and prioritized fixes for each possible cause:

Possible Cause

Side

Quick Fix (Tool)

Priority

Cached or outdated credentials

Client

Remove TERMSRV/ entries from Credential Manager

High

Incorrect username format

Client

Use DOMAIN\Username or UPN format

High

Missing group membership

Server

Add user to "Remote Desktop Users" group (net localgroup)

Medium

Account locked out

Server

Check server Event Log (Event ID 4625)

High

Blocked Group Policy setting

Server

Review GPO and fDenyTSConnections registry key

Medium

These are the same shortcuts as the ones in the comprehensive guide "Troubleshooting RDP Connection on Windows VPS." Most users resolve the issue with one of these simple solutions. If the issue doesn't resolve after performing any of these steps, follow the next steps we've outlined below.

In this section, we start by addressing client-side issues, as they are usually the most common causes of RDP authentication errors.

Clear Cached Credentials in Credential Manager

As mentioned earlier, Windows Credential Manager is often the root cause of this issue. If your password has expired or changed but the old one remains stored, the RDP client keeps sending the outdated credentials, resulting in a failed login attempt. Here is How to clear cached credentials:

  1. Open the Credential Manager from the Start menu or Run dialog.
  2. Go to Windows Credentials to view saved entries.
  3. Find the entries starting with TERMSRV/ followed by the server name or IP.
  4. Click each one and choose Remove or Delete.
  5. Try connecting again Windows will now prompt for new login details.

If the connection works afterward, the issue was definitely on the client side.

Verify Correct Username Format

In domain-based networks, the way you write your username matters. Using the wrong format can cause the server to reject your credentials. Standard RDP login formats:

  • Down-Level (NetBIOS): Used in older domains, e.g. DOMAIN\Username (e.g. ITCORP\marysmith)
  • UPN (User Principal Name): Used in modern domains or Azure AD, e.g. Username@Domain.com (e.g. marysmith@itcorp.local)

If your device is joined to Azure AD, you usually need to log in using the UPN format or the *AzureAD* prefix.
It’s also best to match the exact capitalization (case) of the username as defined in the system to avoid authentication issues with intermediary services.

Check Server Access Permissions

If credentials are correct and the cache is cleared but login still fails, move to the server side.
For RDP access, the user must belong to the Remote Desktop Users or Administrators group.

How to add a user to the Remote Desktop Users group:

Method 1 – Using GUI:

On the target server do this:

  1. open lusrmgr.msc or Computer Management.
  2. Navigate to Groups.
  3. Open Remote Desktop Users, then add the desired user.

If you are more comfortable with CMD or PowerShell, the following method is for you.

Method 2 – Using Command Line (CMD or PowerShell):

In CMD (Run as Administrator): net localgroup "Remote Desktop Users" /add "DOMAIN\username"

In PowerShell (Run as Administrator): Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"

Important: If the user has an explicit “Deny” permission under Terminal Services Permissions, that setting overrides all group permissions and will still block RDP access.

Review Group Policy and Security Settings

Sometimes Remote Desktop is disabled or blocked by Group Policy.
To check:

  1. Open gpedit.msc.
  2. Go to: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections
  3. Ensure Allow users to connect remotely is set to Enabled.
  4. Also verify that the registry key fDenyTSConnections is set to 0: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

If the problem still persists, don't despair and continue reading.

Step Five: Check Network and Firewall

If all settings are correct but the issue persists, the problem may lie in the network connection.

  • Ensure the destination server is pingable.
  • Confirm that port 3389 (default RDP port) is open on the firewall or router.
  • If using a VPN, make sure RDP traffic isn’t being blocked.

For quick testing, run the following PowerShell command:

Test-NetConnection -ComputerName SERVER-IP -Port 3389

If you see TcpTestSucceeded: False, the issue is with network connectivity or firewall configuration.

If the problem still persists, don't despair and continue reading.

By this point, the initial credentials and permissions issues should have been resolved. If the error persists, this indicates that the problem is with the RDP protocol itself, the server's system settings (such as Group Policy), or the firewall layer.

Check the RDP Listener Status

In order for the RDP protocol to accept a connection, a component called the RDP Listener must be enabled on the server and listening on an incoming port. If this component is disabled, your connection will fail at the protocol level and the server will not be able to properly process the credentials sent by the client. Checking the Listener status should be done through another remote administrative session (such as PowerShell Remoting or a physical console) on the target server:

  • Open a Command Prompt or PowerShell session with administrative access.
  • Run this command: powershell qwinsta
  • Observe the output. In this list, you should see an entry called rdp-tcp with the STATE column set to Listen.

If rdp-tcp is not in the Listen state, this is a sure sign that the RDP service on the server is not running or has a protocol failure. In this case, you should check the registry settings and certificates (see Section 5).

Checking RDP Activation via Group Policy (GPO)

In domain environments, a Group Policy Object (GPO) can override and disable local RDP settings. If RDP is enabled locally but a conflicting GPO is applied, RDP will be disabled and the corresponding registry keys may also be changed.

To troubleshoot, you should check the root GPO paths for Remote Desktop Services in the Group Policy Management Editor (on the Domain Controller or GPO Management Tools) or Local Group Policy Editor (on the server itself):

1. Enable RDP service:

Path: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Connections

Required setting: "Allow users to connect remotely using Remote Desktop Services" must be set to Enabled.

2. Enable Firewall

 Even if the RDP service is enabled, the firewall can block inbound traffic.

Path: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Inbound Rules

Required rule: There must be an Inbound Rule of type "Allow" for the default RDP port, TCP 3389 (or your custom port).

After applying any changes to the GPO, you must run the gpupdate /force command on the destination server to apply the new policies immediately.

If you have gone through all the steps above and are still encountering credentials errors, you need to delve deeper into the RDP infrastructure in the registry and certificates.

Critical Registry Keys (Verifying RDP Active State)

Registry keys determine the final RDP state and Listener configuration.

1. RDP Enabled Status (fDenyTSConnections)

This key determines whether Remote Desktop connections are allowed or not.

Location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Value:

0: RDP is enabled.

1: RDP is disabled.

If this value is 1, RDP is disabled and you should change it to 0. If the value returns to 1 after manual change, this indicates that a Group Policy (GPO) is applying a conflicting setting that should have been checked in step 4.2.

2. RDP Port (PortNumber)

Check the path and value given below

  • Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
  • PortNumber Key Value: By default, it should be 3389 (in Decimal).

If you change any of these keys, you must restart the Remote Desktop Services (TermService) service for the changes to take effect.

RDP Certificate Issues

The RDP protocol uses a TLS certificate on the server side to encrypt communication and establish a secure channel. Windows typically generates a self-signed certificate, which should automatically renew when it expires. If the renewal fails due to permission errors or file corruption, the connection will fail during authentication.

Diagnosis:
If you see Event ID 1057 or 1058 from Microsoft-Windows-TerminalServices-RemoteConnectionManager in the System Log, it indicates that the self-signed certificate renewal has failed and manual intervention is needed.

To Fix this:

  1. Open mmc.exe and add the Certificates snap-in for the Computer Account. Under Remote Desktop, locate and delete the expired self-signed certificate.
  2. Restart the Remote Desktop Services (TermService). a new certificate should be generated automatically.

If no new certificate appears, the issue is likely with MachineKeys folder permissions. Take ownership of the RDP-related key file (found in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys), delete it, and restart the RDP service again. Windows will then recreate a valid self-signed certificate.

Checking Server Event Logs (Golden Clues for Failed Logins)

If you’re confident that the RDP protocol is functioning properly, the most reliable way to pinpoint the cause of the issue is by reviewing the server’s Security Log. This log reveals exactly why your authentication attempt was rejected.

Event ID 4625 (Audit Failure)

This event records unsuccessful login attempts. The key section is Failure Information, especially the Sub Status field, which explains the technical reason for the failure:

Sub Status

Hex Code

Failure Reason

Recommended Action

Wrong password

0xC000006A

Username is correct but password is incorrect

Verify password and clear saved credentials

Account locked

0xC0000234

Account locked due to failed attempts

Wait for unlock or contact admin

Account disabled

0xC0000072

The account is disabled

Enable the account via admin

Password expired

0xC0000071

Password has expired

Change the password

Logon right restriction

0xC000015B

User lacks RDP permission

Add user to Remote Desktop Users group

If you see code 0xC000006A and you’re certain the password is correct, the issue is likely caused by cached credentials on the client side (see section 3.1).

In addition to fixing the error, it is also a good idea to take security precautions to prevent it from happening again:

  • Use strong and complex passwords: Use strong, unguessable passwords for remote accounts. (For domain accounts, match the password complexity policy.)
  • Enable NLA: If possible, keep Network Level Authentication enabled so that only authenticated devices can connect to RDP.
  • Update your system: Keep Windows and your Remote Desktop Client up to date. Many security and authentication issues are fixed in updates.
  • Restrict access: Only allow RDP access to users who need it. Restrict direct logins to administrative accounts.
  • Use a firewall or VPN: Secure RDP connections for specific addresses or through a VPN. Block network ports and only direct RDP traffic to required resources.
  • Monitor logs: Check security and user login events in the server's Event Viewer to be notified immediately of suspicious failed attempts.

By following these steps, you will increase security and reduce the likelihood of encountering credential errors.

The “Your credentials did not work” error can be quite frustrating, but it’s usually solvable by following the steps outlined above. The key is to patiently check all settings related to your username, password, permissions, and network configuration. If you need a fast and reliable solution without the hassle, you can use managed RDP services from Buy RDP by MonoVM. These services simplify setup and configuration while ensuring enhanced security, stable connections, and 24/7 technical support for complete peace of mind.

Yes. On systems where you sign in with a Microsoft account (such as Outlook.com or Live.com), you must enter your username in the full email format (for example, user@outlook.com). In some versions of Windows, RDP connections using a Microsoft account are disabled by default. To fix this, you can either create a local account or enable Remote Credential Delegation.

Yes. this is a commonly overlooked issue. If the client and server clocks differ significantly (more than five minutes), security protocols like Kerberos will reject the connection. You can resynchronize the time using the following PowerShell command: w32tm /resync

Yes. When connecting through an RDP Gateway or VPN, intermediate servers participate in the authentication process. If the NPS configuration or SSL certificate on the Gateway is misconfigured, the final server may display the “Your credentials did not work” error. Reviewing Gateway logs and verifying the SSL certificate can help identify the issue.

Yes. If a password has expired, doesn’t meet complexity requirements, or is set to “User must change password at next logon,” the user will be unable to sign in via RDP. In such cases, logging in locally or changing the password through administrative tools is required.

In larger environments, you can use PowerShell Remoting or Group Policy Preferences to centrally check or reset Credential Cache, RDP permissions, and GPO settings on multiple systems. Tools like PsExec or Ansible for Windows are also effective for bulk management.

Lisa P

Lisa P

Hello, everyone, my name is Lisa. I'm a passionate electrical engineering student with a keen interest in technology. I'm fascinated by the intersection of engineering principles and technological advancements, and I'm eager to contribute to the field by applying my knowledge and skills to solve real-world problems.

user monovm

Mr. Tobin Wilkinson IV

2024, Sep, 24

Great read! Dealing with "Your credentials did not work" errors can indeed be frustrating, but this article does an excellent job breaking down why it happens and how to fix it. The step-by-step solutions are really detailed and practical. Looking forward to trying these methods next time I face this issue. Thanks for providing such a comprehensive guide!

user monovm

Mandy Sipes Jr.

2025, Mar, 25

This post is a fantastic resource for anyone struggling with the "Your credentials did not work" error on Remote Desktop. It’s clear that you’ve put a lot of effort into explaining not just the causes but also practical solutions that can be incredibly helpful, especially for those of us who aren't IT experts. I appreciate how you've broken everything down into manageable steps, making it easy to follow and apply. Thanks for sharing these insights!