RDP error Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C) after latest update

Hello

I'm sorry for the inconvenience. Can you please enable session logging as described here; reproduce the problem and send me the log by PM?

Please let me know if something isn't clear

Thanks and kind regards,

Hello

I'm sorry for the inconvenience. Can you please enable session logging as described here; reproduce the problem and send me the log by PM?

Please let me know if something isn't clear

Thanks and kind regards,

@Richard Markiewicz
Hi Richard,

Thanks for the quick reply,
I have reproduce the problem and the logs have been sent to support.

Hello

It fails very early - is it just one server you can't connect to, or many? Are you able to connect with the Microsoft client (Windows App)?

Thanks and kind regards,

Hello

It fails very early - is it just one server you can't connect to, or many? Are you able to connect with the Microsoft client (Windows App)?

Thanks and kind regards,

@Richard Markiewicz
Hi Richard,

I have 4 Windows VM configured as RDP, all of them fail to connect with the same error.

I tried connecting to them using console and also a Royal TSX and those work fine.

Hello

This is really strange. Since these are VMs I assume they're on your local network?

Can you check that Remote Desktop Manager has "Local Network Access" in System Settings > Privacy and Security > Local Network? In conjunction with that, try disabling the sandbox mode if not disabled already (RDM > Settings > Types > Remote Desktop (RDP) > Advanced > "Active Sandboxing" > "No".

Finally, if you try with the previous version, does it work? You can downloaded 2025.3.9.2 here. No need to install it, just close the currently running RDM and launch the old version direct from the .dmg.

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

Kind regards,

Hello

This is really strange. Since these are VMs I assume they're on your local network?

Can you check that Remote Desktop Manager has "Local Network Access" in System Settings > Privacy and Security > Local Network? In conjunction with that, try disabling the sandbox mode if not disabled already (RDM > Settings > Types > Remote Desktop (RDP) > Advanced > "Active Sandboxing" > "No".

Finally, if you try with the previous version, does it work? You can downloaded 2025.3.9.2 here. No need to install it, just close the currently running RDM and launch the old version direct from the .dmg.

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

Kind regards,

@Richard Markiewicz


Hi There,

I tried setting the Active sandbox to NO and it did not work.
Yes, these VMs are in a local network where I'm connected to.
I just tried from the old version 2025.3.9.2 from link provided, and it does work like this!

Hello

Thanks for your patience. This ie extremely strange. It looks really similar to a regression we had recently on RDM Linux, but with a good understanding of the code I can't see a possible reason for the same thing to occur on a macOS system.

I will take a detailed look at this next week and come back with some more information. In the meantime, please stay on 2025.3.9.2 since that is working well for you.

Sorry for the inconvenience

Kind regards,

Hi, I'm in the same situation, posted here https://forum.devolutions.net/topics/52144/not-able-to-connect-via-rdp-to-windows-server-2022-from-rdm-installed- about the problem, but that thread is for windows, my bad.
Posting here to stay updated. I also rolled back one version to 3.9 and the problem is gone.

Hello

As I wrote before this is really strange. It looks very similar to an issue we had on RDM Linux in certain environments, but I can't see how the same problem could occur on macOS. So I'd like some more information, if possible.

I've attached a shell script to this post. It's zipped, so you'll need to unzip it. Assuming you unzipped it to your desktop, please do the following:

• Open Terminal.app
• Make the script executable
  • chmod +x ~/Desktop/rdm-env.sh
• Launch Remote Desktop Manager if not already running (can be any version)
• Back in Terminal.app, execute the script and redirect the output to a file
  • ~/Desktop/rdm-env.sh /Applications/Remote\ Desktop\ Manager.app > ~/Desktop/env.sh.out 2>&1
• This will create a file on your desktop "env.sh.out"
• Please send it to me by PM or to service@devolutions.net, mentioning this forum thread

You can study the contents of the shell script before you run it, but in summary what we are doing here;

• Capture basic user and system information (your username and user ID, your home directory, your macOS version)
• Verify the path to your documents folder (typically ~/Documents) and the permissions on that directory
• Call a macOS API to ask the system where your documents folder is
• Capture session and launch context (the logged-in console user, whether it's a remote login)
• Shows code-signing and entitlement information for RDM and list any related running processes

Please let me know if you have any questions or comments

Kind regards,

Hello

As I wrote before this is really strange. It looks very similar to an issue we had on RDM Linux in certain environments, but I can't see how the same problem could occur on macOS. So I'd like some more information, if possible.

I've attached a shell script to this post. It's zipped, so you'll need to unzip it. Assuming you unzipped it to your desktop, please do the following:

• Open Terminal.app
• Make the script executable
  • chmod +x ~/Desktop/rdm-env.sh
• Launch Remote Desktop Manager if not already running (can be any version)
• Back in Terminal.app, execute the script and redirect the output to a file
  • ~/Desktop/rdm-env.sh /Applications/Remote\ Desktop\ Manager.app > ~/Desktop/env.sh.out 2>&1
• This will create a file on your desktop "env.sh.out"
• Please send it to me by PM or to service@devolutions.net, mentioning this forum thread

You can study the contents of the shell script before you run it, but in summary what we are doing here;

• Capture basic user and system information (your username and user ID, your home directory, your macOS version)
• Verify the path to your documents folder (typically ~/Documents) and the permissions on that directory
• Call a macOS API to ask the system where your documents folder is
• Capture session and launch context (the logged-in console user, whether it's a remote login)
• Shows code-signing and entitlement information for RDM and list any related running processes

Please let me know if you have any questions or comments

Kind regards,

@Richard Markiewicz
Richard, shared the results 1:1

Hello

Thanks @tonynupe for sharing the results, unfortunately it doesn't give me any clue.

Here's where I'm at with this: when we initialize FreeRDP, we need to provide it a path to store files. When FreeRDP bootstraps TLS (needed for basically 99% of RDP servers), it evaluates the path we gave it and if it's not valid for some reason, the connection gets terminated very early. It's only checking that the path "looks" like a valid path, not that it actually exists or is writeable etc.

in RDM Linux we had some changes here that exposed a problem: we're asking .NET for the path to the user's documents directory and handing it to FreeRDP. On Linux, that path is calculated based on the current environment. In FlatPak deployments, .NET was not able to resolve that path (I think that's actually a bug on the .NET side or at least a mis-documentation on their part), so we ended up handing on empty string to FreeRDP, which rejected that (sensibly) as an invalid path, which meant TLS could not be bootstrapped.

This issue has identical symptoms, but I cannot logically explain it as the same thing. Because on macOS, .NET asks the OS where the documents path is (it's not calculated from the user environment) and I can't find any reasonable scenario where that path would be empty or invalid. Actually I can think of a few, but the output of the script I asked you to run shows that, at least in the general case, this is working properly on your side.

However I have to assume that this is all related in a way that I don't see right now, as we have identical symptoms and this is one of the only code paths that can affect this. This thread is the only 2 reports I've had of this problem which implies something unexpected in your respective environments.

What I've done is modify the code in RDM Mac to always fallback to a valid path, even if the system gives us something unexpected. The resolved value is also logged. I think these changes should fix the issue and if they don't, they'll provide enough information to troubleshoot further. Unfortunately there won't be any more 2025.3 builds, but 2026.1 is due to be released on March 2nd and will contain these changes.

In the meantime please stay with 2025.3.9.2 and once 2026.1 is released, this should either be fixed or we'll have more information to take it further. I am sorry for the inconvenience and thank you for your patience

Kind regards,

Hello

Thanks @tonynupe for sharing the results, unfortunately it doesn't give me any clue.

Here's where I'm at with this: when we initialize FreeRDP, we need to provide it a path to store files. When FreeRDP bootstraps TLS (needed for basically 99% of RDP servers), it evaluates the path we gave it and if it's not valid for some reason, the connection gets terminated very early. It's only checking that the path "looks" like a valid path, not that it actually exists or is writeable etc.

in RDM Linux we had some changes here that exposed a problem: we're asking .NET for the path to the user's documents directory and handing it to FreeRDP. On Linux, that path is calculated based on the current environment. In FlatPak deployments, .NET was not able to resolve that path (I think that's actually a bug on the .NET side or at least a mis-documentation on their part), so we ended up handing on empty string to FreeRDP, which rejected that (sensibly) as an invalid path, which meant TLS could not be bootstrapped.

This issue has identical symptoms, but I cannot logically explain it as the same thing. Because on macOS, .NET asks the OS where the documents path is (it's not calculated from the user environment) and I can't find any reasonable scenario where that path would be empty or invalid. Actually I can think of a few, but the output of the script I asked you to run shows that, at least in the general case, this is working properly on your side.

However I have to assume that this is all related in a way that I don't see right now, as we have identical symptoms and this is one of the only code paths that can affect this. This thread is the only 2 reports I've had of this problem which implies something unexpected in your respective environments.

What I've done is modify the code in RDM Mac to always fallback to a valid path, even if the system gives us something unexpected. The resolved value is also logged. I think these changes should fix the issue and if they don't, they'll provide enough information to troubleshoot further. Unfortunately there won't be any more 2025.3 builds, but 2026.1 is due to be released on March 2nd and will contain these changes.

In the meantime please stay with 2025.3.9.2 and once 2026.1 is released, this should either be fixed or we'll have more information to take it further. I am sorry for the inconvenience and thank you for your patience

Kind regards,

@Richard Markiewicz
Good day Richard,
Thanks for the feedback, I will proceed as suggested and stay on the working version while a new version is release.
Thanks again!

Hello

Just an update that 2025.3.9.2 is still available from this link.

We've had a few reports of this problem for 2025.3.10.x and now 2026.1.x and clearly my earlier fix hasn't resolved things.

If someone in this thread is able to try with with the current 2026.1.8.6 (and this may not be an option if you use a shared data source), reproduce the issue with session logging enabled in Help > Session Logs and send me the resulting log file, that would be greatly helpful.

Thanks and kind regards,