got security negotiation failed (0x0002000C) when RDP via RD Gateway

Hi Eric

Sorry for the trouble.

In the first case, to see if it unblocks you; in the RDP session that's using the Gateway try going to Authentication and changing the SSPI Module setting to "System". Does it help?

Otherwise, please send me a session log. Please follow the steps precisely as they have changed in 2026.2:

1. Close RDM completely
2. Open RDM
3. Before doing anything else, go to Help > Session Logs and Enable session logs
4. Try the connection via the problematic Gateway, it will fail
5. Locate the corresponding log back in the Help > Session Logs window and send it to me by PM (you may need to zip the file to attach it to the message)
6. I will take a look at a high priority

Even if changing the setting I mentioned originally helps, the session log (with the default / bad value) will still be really helpful so we can check the issue and prevent it happening in future.

Please let me know if something isn't clear, and thank you for your patience

Kind regards,

Hi Richard,

Appreciate the prompt response. Unfortunately, I am unable to reproduce the error on next day. There is no change on RDM and the problematic RD gateway, but no error on next day. I observe the case for a few days and all are good so far. I guess we can close this issue until it happens again.

Regards,
Eric

Hello

Is it possible this was just a transient network error, and you got (un)lucky that Windows App worked?

The way the RDP protocol works; the client first sends a security negotiation message telling the server what types of security it supports. The server is supposed to answer with a corresponding message, and then security negotiation can proceed. If that first reply was not received from the server (maybe because the network had a transient issue in an unexpected way), that would lead to this error.

Anyway - since the issue has not come back, I suppose things are fine. But if it does reoccur please follow the steps in my post above and let me know, and we will take a look straight away.

Thanks and kind regards,

Hi Richard,

After upgraded to RDM Mac ver.2026.2.3.2, it gets worst. I can reproduce the error on several RD gateway servers.
I tried to enable session log, but none of session was logged. Let's schedule an online troubleshooting. Would you please send the calendar link for scheduling?

Regards,
Eric

Hi Eric

Sorry for the trouble. I've asked my colleague in the support team to reach out to you and set up a session; please let me know if you don't hear anything in the next day or two.

Thanks and kind regards,

Hello,

Just a quick update I have just sent you a scheduling link via private message so we can arrange a remote troubleshooting session.

Please choose the time that works best for you, and we'll investigate the issue together.

Looking forward to speaking with you.

Kind regards,

Hi, I am getting RDP Security Negotiation Failed on any windows Server RDP connection attempt.
This started happening after upgrading to latest RDM versions. I had upgraded to a recent version last week and even today on the latest still the same issue.
Currently on 2026.2.3.2 MacOS version
Before with older version of RDM - RDP connections were working to the same windows server hosts with same accounts/passwords.

I see in Application logs errors
Security negotiation failed ( 0x0002000C)

Not sure if that is related, but we get a security negotiation failed with the Android version 2026.2.1.6 as well
I will pull some application logs shortly

Helli @ipetkov and @pawo

Indeed the problem you report sounds at least related to OP. In his specific case he's using an RD Gateway - is that true on your side? Or it's a direct / regular RDP connection?

We did have a session with Eric today but were unable to reproduce the problem due to separate environmental issues. I'm waiting for feedback from him.

In the meantime, @ipetkov can you please send me a session log. Please follow the steps precisely as they have changed in 2026.2:

1. Close RDM completely
2. Open RDM
3. Before doing anything else, go to Help > Session Logs and Enable session logs
4. Try the connection via the problematic Gateway, it will fail
5. Locate the corresponding logs (they may be more than one) back in the Help > Session Logs window and send it to me by PM (you may need to zip the file to attach it to the message)

Let me know if something isn't clear.

@pawo If you can provide any application logs that you have it would be helpful.

Please let me know if something isn't clear or you have other questions

Kind regards,

I have issues with direct RDP connection. I am not using any gateway. I will try to get some session logs

@Richard Markiewicz I PM-ed you my session log with the issue reproduction

Helli @ipetkov and @pawo

Indeed the problem you report sounds at least related to OP. In his specific case he's using an RD Gateway - is that true on your side? Or it's a direct / regular RDP connection?

We did have a session with Eric today but were unable to reproduce the problem due to separate environmental issues. I'm waiting for feedback from him.

In the meantime, @ipetkov can you please send me a session log. Please follow the steps precisely as they have changed in 2026.2:

1. Close RDM completely
2. Open RDM
3. Before doing anything else, go to Help > Session Logs and Enable session logs
4. Try the connection via the problematic Gateway, it will fail
5. Locate the corresponding logs (they may be more than one) back in the Help > Session Logs window and send it to me by PM (you may need to zip the file to attach it to the message)

Let me know if something isn't clear.

@pawo If you can provide any application logs that you have it would be helpful.

Please let me know if something isn't clear or you have other questions

Kind regards,

@Richard Markiewicz
My issue has been sorted out. There were licensing issues on the RDP server (no gateway involved)
Your Android software showed this missleading message, the licensing message came when I connected with a Windows RDP software.

Thanks for your help
Wolfgang

Hi Richard,

I've sent you the new session log.
Change SSPI module to system also works as workaround.

Hello

I'll try to answer everyone in one post, although the issues are different.

@pirate585 Thanks again for your time yesterday Eric. I've looked at the log you sent and indeed this looks like a regression in our authentication provider. I have someone looking at it right now; in the meantime using the System SSPI is a good workaround. The only problem it might cause in the future is if you need to Kerberos authentication for one or more servers. In any case, if that becomes a problem, please let us know; otherwise I will post back here once the core problem is fixed.

@ipetkov Thanks for the log file. The server is complaining because RDM is not using NLA and the server requires it. In the RDP session "Authentication" tab can you check "Enable Network Level Authentication (NLA)" and try again? Let me know if it helps. Older versions of RDM used to automatically retry the connection with this setting toggled, but it was causing issues and generally considered a legacy behaviour so I remove that capability. If this resolves the issue for you, I'll try to improve the error message in this case.

@pawo Sorry for the inconvenience. See my comment to @ipetkov above; RDM traditionally would retry a failed connection after toggling the Network Level Authentication setting. I removed that behaviour on Mac for precisely this reason - it rarely helps, and it actually masks the real error returned by the server. I will talk to the mobile team about removing this behaviour on their side too.

Please, as always, let me know if something isn't clear or you have other questions

Kind regards,

@Richard Markiewicz - thank you for your support - enabling/checking the box "Enable Network Level Authentication (NLA)" fixed my issue for the host in question.

Error message content improvement hopefully will shed some more light on the root cause and help users figure this out on their own in the future.

Thank you again!

Hi Richard,

Thank you for your prompt support. The workaround works fine and we are looking forward to have core problem fixed.

Regards,
Eric