Windows 11 25H2 RDP fails only from one client to one target

Welcome to Microsoft Q&A!

Thank you for the detailed troubleshooting information. The event sequence you captured is particularly helpful in narrowing down where the connection is failing.

Based on the information provided, this does not appear to be a typical credential rejection. With NLA, CredSSP establishes the secure connection before the user's credentials are authenticated. Since the target receives the RDP connection, but no Event ID 1149 or Security Event ID 4625 is generated, the failure appears to occur during the RDP security/TLS negotiation stage, before Windows processes the user's credentials.

The message “The logon attempt failed" can therefore be somewhat misleading in this situation. Client Event ID 226 with RDPClient_SSL, TsSslEventHandshakeContinueFailed, and 0x80004005 is consistent with the RDP client encountering a problem while establishing the TLS-based connection.

Because the same client can connect to other RDP targets and the same target accepts connections from other clients, I would focus on a configuration or compatibility difference that affects this specific client-target combination.

The possible areas include:

• A TLS cipher-suite mismatch caused by local or domain policy.
• Different TLS protocol settings between the two devices.
• An incomplete or corrupted Schannel/cipher-suite configuration.
• Endpoint security, VPN, TLS inspection, or another network filtering component affecting this specific connection.
• Different cumulative update levels or security baselines, even though both devices are running Windows 11 25H2.

There have been similar RDP scenarios where TLS negotiation failed because no acceptable cipher suite could be found between the client and server. An RDP case involving a missing or corrupted Schannel cipher-suite configuration under:

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

This does not confirm that the same condition is causing your issue, but given the symptoms, a TLS/cipher-suite configuration mismatch is worth investigating.

Recommended next steps

1. Compare the complete Windows build and update level

Run winver on both devices and compare the complete OS build number, rather than only confirming that both are Windows 11 25H2.

I would also make sure both devices have the latest applicable cumulative updates installed and restart them after updating.

This helps rule out differences in the servicing level or security components between the two systems.

2. Compare the effective TLS and RDP policies

On both devices, generate a Group Policy report:

gpresult /h C:\Temp\gpresult.html

Compare the effective settings under:

• Computer Configuration > Administrative Templates > Network > SSL Configuration Settings
• Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
• Computer Configuration > Administrative Templates > System > Credentials Delegation

I would also compare the following registry locations:

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

In particular, compare values such as:

• Functions
• SecurityLayer
• MinEncryptionLevel
• fAllowSecProtocolNegotiation
• SSLCertificateSHA1Hash / SSLCertificateSHA1HashValue

This is a recommendation checking the RDP certificate binding and security protocol negotiation when investigating security-negotiation failures. I would not recommend copying or replacing the entire RDP-Tcp registry key from another computer. Some of these settings may be configured through Group Policy, and copying the complete key could introduce additional certificate or security configuration issues.

3. Compare the available TLS cipher suites

From an elevated PowerShell window on both computers, run:

Get-TlsCipherSuite |

Select-Object Name |

Out-File C:\Temp\TlsCipherSuites.txt

Compare the resulting lists.

If SSL Cipher Suite Order is configured through Group Policy on either device, also verify that the configured list is complete and correctly formatted.

4. Enable Schannel logging temporarily

Since the failure appears to occur around TLS negotiation, Schannel logging may provide a much more specific error than the generic client-side 0x80004005.

On both devices, check/configure:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EventLogging = 7 (DWORD)

Restart both devices, reproduce the failure once, and then check:

Event Viewer > Windows Logs > System

Look for Schannel events generated at the exact time of the failed connection, particularly events related to certificate/private-key access, TLS credential creation, cipher negotiation, certificate validation, or fatal TLS alerts.

It is specifically identifies Schannel events such as 36870, 36871, and 36872 as useful when investigating TLS-related RDP failures.

After troubleshooting, restore the Schannel logging value to its previous setting to avoid unnecessary event logging.

5. Rule out third-party filtering components

If applicable, test after temporarily disabling the relevant component according to the vendor's supported procedure, such as:

• Endpoint security network filtering
• VPN software
• TLS/SSL inspection
• Web filtering
• DLP network drivers
• Third-party credential providers

A clean boot can also help determine whether a client-side service or filter driver is interfering with the TLS exchange.

6. Collect simultaneous traces if the issue remains

If Schannel logging does not reveal the cause, the next useful step would be to collect diagnostics simultaneously from the affected client and target while reproducing the problem.

The client-side 0x80004005 is generic and usually isn't enough by itself to identify which part of the TLS negotiation failed.

A simultaneous trace can help determine:

• Which cipher suites the client offers.
• Which cipher suite the target selects, if any.
• Whether a TLS alert is returned.
• Whether certificate-chain or private-key validation fails.
• Whether CredSSP negotiation is actually reached.
• Which side terminates the connection.

Microsoft's TSS tooling can also be useful for collecting comprehensive Windows troubleshooting data. It is a recommendation collecting diagnostic information from both endpoints when investigating RDP/CredSSP-related connection failures.

Based on the evidence so far, I would treat this primarily as a TLS/RDP security-negotiation issue occurring before Windows processes the user's credentials, rather than as an incorrect username/password issue.

I would also avoid weakening CredSSP security, permanently disabling NLA, or enabling obsolete TLS protocols as a workaround. Since disabling NLA did not change the behavior, those changes are unlikely to address the underlying problem and could unnecessarily reduce security.

The most useful next step would be to compare the TLS/cipher-suite policies on the two machines and capture the corresponding Schannel events during one failed attempt. If that does not reveal the cause, a simultaneous trace from both endpoints should provide the evidence needed to identify exactly where the handshake is breaking.

If the issue can also be reproduced on a clean, fully updated Windows 11 25H2 installation without domain policies or third-party security/network components, I would recommend reporting the behavior through Feedback Hub under the most relevant Windows/Remote Desktop category and, if possible, opening a Microsoft Support case so that the diagnostic traces can be reviewed in more depth.

References:

CredSSP protocol sequence

Enable Schannel event logging in Windows

Schannel events

Troubleshooting RDP client connection problems

An internal error has occurred when connecting to a remote machine

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Note: This is the עברית‏ (he-il) forum. I kindly recommend posting your question in עברית‏, as this will make it easier for other forum members and subject matter experts to engage with your inquiry. If you prefer to post in English, you may also consider using the Microsoft Q&A English forum, where a larger English-speaking audience can review and respond to your question. Thank you for your understanding.