Hello
I was looking at separate NLA-related issue on RDM Android so I took some time to investigate this a little. What Alexis wrote is spot on; we need the FreeRDP logs showing the issue; because the problem is a little more complicated than your issue report suggests (I get a different behaviour than you when I test the same scenario). But contrary to what Alexis wrote, a single log run should be enough (you can .zip it and send directly to me by PM). Basically just reproduce the original error condition (which should be NLA enabled, and if you are using default settings, the SSPI module set to "Portable" and the authentication package set to "Negotiate").
Please let me know if something's not clear, because I can't go any further without that.
The problem is, that in my testing when I disable inbound NTLM as you did, the server does not actually reply with STATUS_NTLM_BLOCKED. I get an SSPI specified error ("Unsupported function") which maps out to "authentication failure" in the client. That's better than "password expired" but still not ideal. The CredSSP spec is a bit loose here; it says that the error code field should carry the NTSTATUS, but not that it must , so my server sending a raw SSP security status isn't necessarily wrong, but it is annoying.
On your side there's divergence; if you get "password certainly expired" that means you've taken a different code path, most likely that the actual TCP connection was closed before we received any structured error at all from the server. The password expired error seems like a guess base on what they've (FreeRDP) seen in the past, and I would classify that as bug, but without seeing actually what's happening it's hard to be precise.
As Alexis wrote, the Windows server version(s) is very relevant too.
So that's for the error mapping, but actually the problem is
In contrast, the new Windows App (mobile) and native desktop client manage to properly wrap authentication inside a TLS/CredSSP context without triggering this NTLM block error
Meaning, you can authenticate successfully using Windows App?
I'm wondering if you understand the internals of what's happening here; when you talk about a TLS/CredSSP context; are you talking about another mechanism than NTLM but still using CredSSP? e.g. Kerberos? I'm not so sure because you also mention the remote environment is a workgroup. Or, are you talking about TLS or RDP security? I need to understand if something other than NTLM is working over NLA (seems unlikely in a workgroup) or if the Microsoft client is seeing a certain error condition, and then retrying the connection from scratch as TLS (there's no direct fallback from NLA once negotiation has happened). When you connect with the Microsoft client, does it go through WinLogon or do you land directly on the remote machine's desktop?
Please, again, let me know if something isn't clear or you have further questions
Kind regards,
