On Wednesday, July 31st, 2024 at 00:43, Stuart Henderson <stu.lists@spacehopper.org> wrote:
> On 2024-07-30, Lévai Dániel leva@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
No comments:
Post a Comment