RDP Proxy Technical Notes

Overview

Delinea's RDP Proxy is a feature of Secret Server that allows protection of secret credentials when launching or connecting to remote servers with privileged credentials. The RDP Proxy simulates the RDP connection handshake process when a client connects to retrieve the short-lived temporary credentials that are generated by Secret Server. When it retrieves these credentials, it then queries Secret Server to find the mapped to real secret or privileged credentials to connect to the remote host and begin proxying the data back and forth between the remote host and the client machine.

Requirements

Because of the way in which the RDP proxy expects to retrieve the temporary credentials, there are a few requirements which must be met in order to use the RDP proxy:

  • The RDP Proxy only supports TCP as a transport, not UDP. Client machines must be able to negotiate using the CredSSP external security provider in the RDP protocol. Client machines must be able to use NTLMv2 to connect to the RDP proxy.
  • Client machines must be able to negotiate using the CredSSP external security provider in the RDP protocol. They must have enabled network-level authentication, Microsoft recommends the NLA.
  • Client machines must be able to use NTLMv2 to connect to the RDP proxy. The RDP proxy needs to retrieve the temporary credentials from the client machine in order to validate them, which is only possible using the NTLMv2 protocol and not Kerberos.
  • Because the RDP Proxy is pretending to be an RDP host, the certificate that is served from the actual remote host must be trusted. Otherwise, the configuration setting "Validate Remote Certificates" must be disabled. The certificate that is served to the client is the configured "RDP Server Certificate."
  • The RDP Proxy is currently unable to support certain niche protocol features. These include: Extended Client Data, DYVNC Graphics Pipeline, Restricted Administrative Mode, and Redirected Authentication.
  • The RDP Proxy does not support Windows XP.
  • For gateway mode, the client must use an RDP client that implements the remote desktop gateway protocol. The Microsoft remote desktop connection client on a currently supported Windows release is the validated configuration.
  • For gateway mode, client machines must trust the full chain of the gateway certificate. Unlike target-host validation, there is no client-side bypass option.
  • Clients authenticate to the gateway using a short-lived signed bearer token issued by Secret Server at launch time. NTLM is not used on the client-to-gateway leg. Target-host authentication continues to use CredSSP with NTLMv2 as before.
  • Each distributed engine that serves gateway sessions must advertise the RD gateway capability. Older engines continue to serve direct RDP proxy sessions but cannot accept gateway connections.

Connection Sequence

Figure: RDP Proxy Connection Sequence

image-20200326113129450

Performance Testing

The RDP Proxy has undergone performance testing with the following results:

  • Infrastructure: We ran the proxy on one Secret Server Web node with 4 vCPUs, 16 GB RAM, Azure D4s_v3 VMs with CPU Intel Xeon 8171M at 2.1 GHz.
  • Concurrent sessions: 50 sessions. There was no degradation of performance as the session count rose.
  • Session activity: Medium to high. Simulation watched videos and windows screensavers, both of which are graphically intensive and require large amounts of data transfer.
  • CPU results: 15-25% CPU usage fluctuation during the 50 concurrent sessions with no observed large spikes.
  • Bandwidth results: All sessions collectively used 100-125 Mbps. This will vary wildly based on the type of connecting client and in-session activity.

Gateway Mode

Protocol Surface

Gateway mode implements the subset of the Terminal Services Gateway protocol required to serve the Microsoft Remote Desktop Connection client (mstsc.exe). Data is carried as RDP over an HTTPS tunnel. The UDP datagram transport is not implemented.

Authentication

Clients authenticate to the gateway using a short-lived signed bearer token issued by Secret Server at launch time, carried as a token in the gateway connection request. This removes NTLM from the client-to-gateway leg, which is the compliance outcome of gateway mode. The gateway then establishes a separate connection to the target host using the existing CredSSP and NTLMv2 sequence to the Windows target — unchanged from direct RDP Proxy.

TLS

The gateway listener accepts client connections over TLS 1.2. Other TLS versions are not offered on the gateway listener. The direct RDP proxy listener, by contrast, accepts TLS 1.0, 1.1, or 1.2.

The operating system's TLS configuration on the engine host can further restrict the protocols offered but cannot enable versions beyond those listed.

Reconnect

The gateway preserves the session binding for a short window after a client-side disconnect so that a brief network interruption that triggers an mstsc auto-reconnect does not produce a new session record. Administrative end-session operations from active sessions take precedence over any pending reconnect.

Clients

Any RDP client that implements the remote desktop gateway protocol can connect. Delinea validates gateway mode against the Microsoft Remote Desktop Connection client (mstsc.exe) on currently supported Windows desktop and server releases. Other compliant clients may work but are not part of Delinea's validated configuration.

Performance

Gateway mode adds a TLS handshake and tunnel setup per session. In internal testing, a 4 vCPU / 16 GB Distributed Engine sustains 50 concurrent gateway sessions with CPU and throughput within 5% of direct-mode figures.