List of content you will read in this article:
- 1. What Does "Your Credentials Did Not Work" Mean When Using Remote Desktop?
- 2. Quick Diagnosis: Common Causes & Fix Summary (TL;DR)
- 3. Operational Steps: Quick, Step-by-Step Solutions
- 4. Client-side vs. Server-side
- 5. Advanced Troubleshooting and Technical Scrutiny
- 6. Security and Best Practices
- 7. Say Goodbye to RDP Errors
- 8. FAQ
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.
What Does "Your Credentials Did Not Work" Mean When Using Remote Desktop?
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.
Quick Diagnosis: Common Causes & Fix Summary (TL;DR)
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.
- 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.
- 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.
- 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.
Operational Steps: Quick, Step-by-Step Solutions
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:
- Open the Credential Manager from the Start menu or Run dialog.
- Go to Windows Credentials to view saved entries.
- Find the entries starting with TERMSRV/ followed by the server name or IP.
- Click each one and choose Remove or Delete.
- 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:
- open lusrmgr.msc or Computer Management.
- Navigate to Groups.
- 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:
- Open gpedit.msc.
- Go to:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections - Ensure Allow users to connect remotely is set to Enabled.
- 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.
Client-side vs. Server-side
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.
Advanced Troubleshooting and Technical Scrutiny
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:
- Open mmc.exe and add the Certificates snap-in for the Computer Account. Under Remote Desktop, locate and delete the expired self-signed certificate.
- 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).
Security and Best Practices
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.
Say Goodbye to RDP 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.
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.