Is there a way to configure the use of a SOCKS5 proxy for connection to RDP targets? Ideally on a per connection level as can be done with SSH?
I'm aware of the TS Gateway, Royal Server, and Secure Gateway options, but we have a requirement to pass connections through several proxy server to meet audit requirements. There are separate proxy servers for development and production environments, so we would like to configure this at the connection level, not the system level.
possibly you may use Royal Server in combination with Secure Gateway to securely tunnel your RDP connections? Basically the Secure Gateway is a SSH tunnel where active connections will get tunnel'ed through. Probably this may solve your audit requirements? Furthermore this is also possible on connection level, as you wrote (as you can have multiple Secure Gateways). May this help you in that case?
Probably not... In order to audit the connection we do not want the additional encryption. We are using a security product that acts as a man-in-the-middle for Remote Desktop connections... It supports connections via SOCKS5 for transparent encryption and decryption, but would probably not be able to decrypt the SSH tunnel to perform the audit.
Royal TS is using the Microsoft RDP ActiveX control which ships with Windows. We checked the API and it seems there's no SOCKS5 support or any other proxy support available in RDP except for Remote Desktop Gateway servers.
Correct me if I'm wrong, but to implement the Security Gateway functionality you probably create a tunnel that forwards a local port to the target, and then use the Microsoft RDP ActiveX control to connect to the local port. Implementing SOCKS5 support would work exactly the same... You would open a Socket via the proxy server to the target, open another socket on the localhost and forward all traffic from each Socket. For examples in C# see:
Note that I have purchased RoyalTS for my own personal use already... But I would like to convince my company to purchase the global license so that others can use it, and this would be key functionality.
I'm not sure that's correct. The links you provided are samples on how to create a proxy server. With our Royal Server as Secure Gateway / SSH tunnel you already have a SOCKS5 capable proxy (see Chrome web page connection's proxy support). The issue is that the RDP ActiveX control only accepts a server name and port. There's no way to specify which proxy to use and the TCP communication from the ActiveX control can not be changed as the ActiveX is a black box where we don't have the source code.
You are missing the point. The Secure Gateway does not meet the need because it adds an additional layer of encryption.
What I am suggesting doesn't require any changes to the ActiveX control.
We need support for a non-secure Gateway, i.e. a non-encrypted tunnel so that we can audit it for regulatory compliance. We have software in place that will decrypt both SSH and RDP protocols if they are passing through a specific software package that behaves as a SOCKS5 proxy server, but not if they are passing through a SSH tunnel or a different SOCKS5 proxy that is provided dynamically by a ssh connection. The auditing software is CryptoAuditor ( https://www.ssh.com/products/cryptoauditor/ ). There are several competing audit packages that provide similar functionality, they are very common in extremely large companies that are subject to regulatory compliance such as PCI-DSS, Sarbanes-Oxley, HIPAA, etc...
The links I sent do not show how to create a proxy server. They show how to use a SOCKS5 proxy server to create a non-encrypted tunnel from a local port to a remote server and port via a SOCKS5 proxy server.
You would set this up to listen on a random unused local port for each connection which would forward to the true target, and simply use the RDP ActiveX control to connect to the localhost and local port. Since the RDP ActiveX control doesn't support SSH tunnels either, I expect this is exactly what you are doing with the SSH tunnels in the Secure Gateway feature.
The difference, which is critical, is that the connection via the SOCKS5 proxy server isn't encrypted again, and it is using a SOCKS5 proxy server that we specify, not one that is created dynamically by SSH.
If this still doesn't make sense, I can probably mock up some code in C#.
I'm sorry, I'm now more confused than before. If you can hack some C# code to demonstrate how this would work, we can definitely take a look at it. Please send us the code and some instructions on how we can easily test the implementation to email@example.com