NLA Error 0x0002000F (STATUS_PASSWORD_EXPIRED) on Android client when RestrictReceivingNTLMTraffic = 2 (Workgroup)

Hello,

Thank you for the detailed report and for the root cause analysis, it is very helpful.

We have not been able to confirm yet that the server is returning STATUS_NTLM_BLOCKED and that the app is translating it into "password expired" (0x0002000F). To check that and to understand why the connection fails, we need a few details:

1. The exact RDM Android version and the Windows Server version of the target machine.
2. Whether you sign in with a local account or with a Microsoft account.
3. The RDP log from the Android app. To get it, go to the application settings (not the entry), Sessions, RDP, and enable logging. Then reproduce the issue and open Tools, Private Storage Explorer, Logs folder. You can share the file from there.
4. The result of these tests on the entry, one at a time:
  a. Untick NLA in the entry, if your server allows connections without NLA.
  b. In the Authentication tab, set the Authentication Package to NTLM.
  c. In the Authentication tab, set the SSPI Module to System, then to Portable.

Please keep in mind that in a workgroup there is no Kerberos, so NLA can only authenticate with NTLM. With RestrictReceivingNTLMTraffic set to 2, the server rejects that exchange, so we need to confirm how the Windows App behaves in your environment (for example, whether it connects without NLA) before we can say whether anything can be done on the RDM side.

Once we have this information, we will review it and come back to you.

Best regards,

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,

Hello

In RDM Android 2026.3.1, if NTLM is blocked on the server the error message reported should now be accurate. The workaround in this scenario (which should now be clear) is to disable NLA in the authentication settings of the RDP session.

I'm still not sure what you mean by "Update the FreeRDP/CredSSP implementation in the RDM mobile app to support TLS-wrapped authentication contexts". This is supported, as above by disabling NLA; but are you saying that the Microsoft client automatically falls back from an NLA failure in this case? Or are you talking about another mechanism than NTLM that still uses CredSSP (I can only think of Kerberos, but that doesn't apply in workgroups).

Thanks and kind regards,

Hello,

Thank you for your patience while our team looked into the issue you reported.

I'm happy to let you know that the latest version of Remote Desktop Manager for Android (2026.3.1.3) includes a fix for this problem.

Please note that this version is being released gradually (phased rollout), so it may not be displayed in Google Play right away. As soon as you see the new version available, please install it.

Once you have installed the update, could you please test it in your environment and confirm that everything now works as expected? If the issue persists or if you notice anything unusual related to the same original problem, just reply to this message with a few details, and we will be glad to look into it further.

Thank you for your collaboration.

Best regards,