Confirming on Ubuntu 24.04.5 (noble), amd64, gnome-remote-desktop 46.3-0ubuntu1.2 (user-mode desktop sharing, NLA username/password) with Microsoft Windows App 11.3.8 on macOS.
With libfreerdp3-3 / libfreerdp-server3-3 / libwinpr3-3 3.32.0+dfsg-0ubuntu0.24.04.1, Windows App sits at "Securing connection to remote PC" forever. Downgrading only those three packages to 3.31.0+dfsg-0ubuntu0.24.04.1 fixes it immediately. Root cause: this is upstream FreeRDP issue https://github.com/FreeRDP/FreeRDP/issues/13549, fixed on master by https://github.com/FreeRDP/FreeRDP/pull/13552 (merged 2026-09-29). The fix is NOT in any release yet; 3.32.1 was tagged a day earlier and is still affected. 3.32.0 made the server negotiate HYBRID_EX by default (ExtSecurity=TRUE). It then sends the Early User Authorization Result PDU right after the server's pubKeyAuth TSRequest, before it has received the client's TSCredentials. MS-RDPBCGR requires the PDU after the CredSSP handshake completes. Windows App then never sends MCS Connect Initial, and the server waits in CONNECTION_STATE_MCS_CREATE_REQUEST until the client gives up. The nla.c hunk of PR #13552 moves nla_send_early_user_auth() to after the auth- info stage. FreeRDP debug log from the failing server (WLOG_LEVEL=DEBUG), in order: RDP_NEG_REQ: RequestedProtocol: [SSL|HYBRID|HYBRID_EX] -> Negotiated EXT:1 [nla_send]: ----->> public key auth [59 bytes] [nla_send_early_user_auth]: ----->> sending AUTHZ_SUCCESS [4 bytes] [nla_decode_ts_request]: <<----- auth info [rdp_server_transition_to_state]: CONNECTION_STATE_NEGO --> CONNECTION_STATE_MCS_CREATE_REQUEST (no further data from the client; ~10 s later: transport_read_pdu() - -1) A packet capture shows the same thing: the server ACKs the client's 104-byte TSCredentials record and never sends anything else. Why this is easy to miss: a running gnome-remote-desktop keeps the old libraries mapped. RDP keeps working after the unattended upgrade and only breaks at the next login or service restart, sometimes days later, so it's hard to connect the failure to the update. Upstream workaround, from the FreeRDP maintainer in https://github.com/FreeRDP/FreeRDP/issues/13579: create /etc/FreeRDP/FreeRDP/HKLM.reg containing [HKEY_LOCAL_MACHINE\Software\FreeRDP\FreeRDP\Server] "ExtSecurity"=dword:00000000 and restart gnome-remote-desktop. I confirmed that WinPR on noble resolves its system HKLM.reg to that path and reads the value as DWORD 0. I haven't tested the workaround on 3.32.0 myself; I went back to 3.31.0. Suggested fix: as a security-regression update, cherry-pick the nla.c change from PR #13552 into the noble (and resolute) freerdp3 packages, or restore the server's ExtSecurity default to FALSE. LP: #2168823 looks like the same bug on 26.04. ** Bug watch added: freerdp-issues #13549 https://github.com/FreeRDP/FreeRDP/issues/13549 ** Bug watch added: freerdp-issues #13579 https://github.com/FreeRDP/FreeRDP/issues/13579 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2168870 Title: FreeRDP 3.32 regression breaks GNOME Remote Desktop connections from macOS on Ubuntu 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freerdp3/+bug/2168870/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
