| Summary: | NTML_MESSAGE_HEADER Invalid Signature - SEC_E_INVALID TOKEN | ||
|---|---|---|---|
| Product: | [Plasma] KRdp | Reporter: | Ash <ashleysommer> |
| Component: | general | Assignee: | Unassigned bugs <unassigned-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | ahiemstra, prahal |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.3 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Ash
2025-03-14 06:46:34 UTC
Sorry, can't edit my post. I just realized the first 11 lines are from testing a different client (that does not support NLA). Disregard the first 11 lines of the log output, the report should start from line 12, (at [16:10:38]) where the windows client connects. I'm confident this would be solved by moving to libfreerdp-server3. KRDP master was already ported to FreeRDP3, so in that case this should resolve itself once that's released with Plasma 6.4. Today I upgraded to the KRdp build from Neon-unstable, that is built against FreeRDP3. I'm getting a different error, but it is still not working. --- org.kde.krdp: Listening for connections on QHostAddress(QHostAddress::Any) 3389 org.kde.krdp: Initializing Freedesktop Portal Session org.kde.krdp: Session setup completed, start processing... org.kde.krdp: Started Freedesktop Portal session libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 kpipewire_vaapi_logging: VAAPI: Intel iHD driver for Intel(R) Gen Graphics - 24.1.0 () in use for device "/dev/dri/renderD128" libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 kpipewire_vaapi_logging: VAAPI: entrypoint 6 of profile 14 is not supported by the device "/dev/dri/renderD128" kpipewire_vaapi_logging: VAAPI: entrypoint 8 of profile 14 is not supported by the device "/dev/dri/renderD128" libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 kpipewire_vaapi_logging: VAAPI: entrypoint 6 of profile 14 is not supported by the device "/dev/dri/renderD128" kpipewire_vaapi_logging: VAAPI: entrypoint 8 of profile 14 is not supported by the device "/dev/dri/renderD128" libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 [20:13:19:022] [1685676:0019b8ce] [WARN][com.winpr.sspi] - [winpr_AcceptSecurityContext]: AcceptSecurityContext status SEC_E_INVALID_HANDLE [0x80090301] [20:13:19:022] [1685676:0019b8ce] [ERROR][com.freerdp.core.auth] - [credssp_auth_authenticate]: AcceptSecurityContext failed with SEC_E_INVALID_HANDLE [0x80090301] [20:13:19:022] [1685676:0019b8ce] [ERROR][com.freerdp.core.transport] - [transport_accept_nla]: client authentication failure [20:13:19:023] [1685676:0019b8ce] [ERROR][com.freerdp.core.peer] - [peer_recv_callback_internal]: CONNECTION_STATE_NEGO - rdp_server_accept_nego() fail [20:13:19:023] [1685676:0019b8ce] [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1] org.kde.krdp: Unable to check file descriptor org.kde.krdp: Closing session org.kde.krdp: Closing Freedesktop Portal Session --- I believe the relevant error is "AcceptSecurityContext status SEC_E_INVALID_HANDLE [0x80090301]" There is a new error displayed on the Windows side too, the message says "The token supplied to the function is invalid", which after a quick search usually indicates a password error. I don't know if this is a KRDP issue or a FreeRDP3 issue or a Windows 11 issue at this point. Okay, this is not a bug in KRDP. I tried the latest version of gnome-remote-desktop (that is built against the same version of FreeRDP3) and it gives exactly the same error. I think I'm seeing a version of this: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/162 I don't have permission on the Windows laptop to check the configured group policies, but there must be a setting that is preventing a connection to a non-whitelisted RDP endpoint. Weirdly, it seems like Windows implements this by still sending the connection, but without any security context attached, so FreeRDP errors at this line: https://github.com/FreeRDP/FreeRDP/blob/acf830946cb8358f03ac9bdaad61da4397fb58fc/winpr/libwinpr/sspi/NTLM/ntlm.c#L495 The next thing I can try is to borrow a different (non-organisation) Windows laptop from a friend and see if that can connect to KRDP. (In reply to Ash from comment #5) > Okay, this is not a bug in KRDP. I tried the latest version of > gnome-remote-desktop (that is built against the same version of FreeRDP3) > and it gives exactly the same error. > > I think I'm seeing a version of this: > https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/162 > > I don't have permission on the Windows laptop to check the configured group > policies, but there must be a setting that is preventing a connection to a > non-whitelisted RDP endpoint. > Weirdly, it seems like Windows implements this by still sending the > connection, but without any security context attached, so FreeRDP errors at > this line: > https://github.com/FreeRDP/FreeRDP/blob/ > acf830946cb8358f03ac9bdaad61da4397fb58fc/winpr/libwinpr/sspi/NTLM/ntlm.c#L495 > > The next thing I can try is to borrow a different (non-organisation) Windows > laptop from a friend and see if that can connect to KRDP. to me the error you point to about windows policy is a 0x0002000D transport error not the same as yours but [16:08:59:857] [296889:302985] [INFO][com.freerdp.core.connection] - Client Security: NLA:0 TLS:0 RDP:1 [16:08:59:857] [296889:302985] [INFO][com.freerdp.core.connection] - Server Security: NLA:1 TLS:0 RDP:0 [16:08:59:857] [296889:302985] [WARN][com.freerdp.core.connection] - server supports only NLA Security [16:08:59:857] [296889:302985] [ERROR][com.freerdp.core.connection] - Protocol security negotiation failure points at your client not supporting NLA authentification ( Client Security: NLA:0 TLS:0 RDP:1) only RDP auth. But your server only supportinjg NLA authentification (Server Security: NLA:1 TLS:0 RDP:0) (In reply to Alban BROWAEYS from comment #6) > (In reply to Ash from comment #5) > > Okay, this is not a bug in KRDP. I tried the latest version of > > gnome-remote-desktop (that is built against the same version of FreeRDP3) > > and it gives exactly the same error. > > > > I think I'm seeing a version of this: > > https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/162 > > > > I don't have permission on the Windows laptop to check the configured group > > policies, but there must be a setting that is preventing a connection to a > > non-whitelisted RDP endpoint. > > Weirdly, it seems like Windows implements this by still sending the > > connection, but without any security context attached, so FreeRDP errors at > > this line: > > https://github.com/FreeRDP/FreeRDP/blob/ > > acf830946cb8358f03ac9bdaad61da4397fb58fc/winpr/libwinpr/sspi/NTLM/ntlm.c#L495 > > > > The next thing I can try is to borrow a different (non-organisation) Windows > > laptop from a friend and see if that can connect to KRDP. > > to me the error you point to about windows policy is a 0x0002000D transport > error not the same as yours > > but > > [16:08:59:857] [296889:302985] [INFO][com.freerdp.core.connection] - Client > Security: NLA:0 TLS:0 RDP:1 > [16:08:59:857] [296889:302985] [INFO][com.freerdp.core.connection] - Server > Security: NLA:1 TLS:0 RDP:0 > [16:08:59:857] [296889:302985] [WARN][com.freerdp.core.connection] - server > supports only NLA Security > [16:08:59:857] [296889:302985] [ERROR][com.freerdp.core.connection] - > Protocol security negotiation failure > > points at your client not supporting NLA authentification ( Client Security: > NLA:0 TLS:0 RDP:1) only RDP auth. > But your server only supportinjg NLA authentification (Server Security: > NLA:1 TLS:0 RDP:0) Sorry I missed the latter: [16:10:38:453] [296889:304164] [INFO][com.freerdp.core.connection] - Client Security: NLA:1 TLS:1 RDP:0 [16:10:38:453] [296889:304164] [INFO][com.freerdp.core.connection] - Server Security: NLA:1 TLS:0 RDP:0 [16:10:38:453] [296889:304164] [INFO][com.freerdp.core.connection] - Negotiated Security: NLA:1 TLS:0 RDP:0 where the auth schemes are synced. INVALID TOKEN point to an auth issue. Then I might have the same issue as yours with my https://discourse.gnome.org/t/can-no-longer-login-to-gnome-remote-desktop-kerberos-error/32757 request for help. I did not have issue with freerdp 2 that had no kerberos support, but it seems my Samba AD kerberos client or something related messses up gnome-remote-desktop freerdp 3 because of freerdp3 kerberos support. |