On Wednesday, July 31st, 2024 at 00:43, Stuart Henderson <stu.li...@spacehopper.org> wrote: > On 2024-07-30, Lévai Dániel l...@ecentrum.hu wrote: > > > Hi all, > > > > I'm noticing that xfreerdp and remmina fails to connect to a Windows 11 > > machine while using NLA: [...] > > I'm able to connect to a W2022 DC using "xfreerdp /u:username > /d:somedomain /v:xx.xx.xx.xx:3389 /sec:nla" and typing the password at > the Password: prompt. I'm not sure how to tell if it's really using NLA > but I suspect that non-NLA logins are probably disabled on the Windows > side.
Well, a pretty good indication - as far as I know - is freerdp sending the credentials while connecting. Anything else is the legacy logon screen where you're greeted with a Windows logon screen and typing in the user name + password. > Have you tried the same freerdp version on e.g. Linux to see how that > works? I haven't, admittedly. 2.11.7 fails to build here on arch, there's an issue reported for the compilation error but upstream treats 2.x as oldstable and would only provide security fixes. What I also wanted to try was building 2.11.7 linked with OpenSSL on OpenBSD but couldn't figure out the magic build option combination, yet. There's a -DWITH_LIBRESSL flag in 3.x, but it's 3.x and I'm afraid it works the other way around (i.e. forcing LibreSSL instead of disregarding it). > (Better to compare the same version if possible otherwise there is an > extra complication - the old workaround for lack of posix timers is > no longer enough, we cannot update to freerdp 3.x, so maybe missing > upstream fixes - it's possible they may have fixed something for newer > versions of Windows). Got it; noticed this in the Makefile, that's why I didn't even try to update the port. Thanks anyway, will just going to work around it by not using NLA for the time being. Daniel
