Share via

3.2 Example 2: Connecting from an RDP Client to an RD Session Host Through a Remote Desktop Gateway

  • Article

This example demonstrates the process of connecting from an RDP client to an RD Session Host through a Remote Desktop Gateway as described in section 2.5.1.3

Prerequisites

  • A valid non-expired license exists for the client on the License Server.

  • The Remote Desktop Gateway is operational and listening for a connection request on a known port. The Remote Desktop Gateway is capable of making remote connections to the requested RD Session Host server. The RD Session Host is operational and listening for an RDP connect request. If the RDP client is using the IPv6 protocol, then Remote Desktop Gateway supports the IPv6 protocol.

Initial System State

The RDP client and RD Session Host are not connected.

Final System State

The RDP client is connected to the RD Session Host through the Remote Desktop Gateway. The RDP client can start sending mouse and keyboard input to the RD Session Host, and the RD Session Host can start sending graphics output to the RDP client.

 Sequence of Events

In the description of the connection sequence using an RD Gateway, steps 1-5 describe the process to create an RPC/HTTP tunnel. The data transfer phase referenced in [MS-TSGU] refers to steps 6-14.

Creating an RPC over HTTP (RPC/HTTP) tunnel

Figure 7: Creating an RPC over HTTP (RPC/HTTP) tunnel

Creating an RDP connection through an RD Gateway

Figure 8: Creating an RDP connection through an RD Gateway

A description of the connection sequence using an RD Gateway is as follows:

  1. The RDP client initiates the connection when an user provides the name of the remote desktop to connect to. The RDP client sends an RPC Connect HTTP Request to the RD Gateway. The RD Gateway responds with a RPC Connect Response. This sequence is described in [MS-TSGU] section 2.1.

  2. The RDP client sends a TSProxyCreateTunnel Request to the RD Gateway to request that a tunnel be created. The RD Gateway responds with a TSProxyCreateTunnel Response. This sequence is described in [MS-TSGU] section 1.3.

  3. The RDP client sends a TSProxyAuthorizeTunnel Request to the RD Gateway to authorize the tunnel from the previous step. The RD Gateway responds with a TSProxyAuthorizeTunnel Response. This sequence is described in [MS-TSGU] section 1.3.

  4. The RDP client sends a TSProxyCreateChannel Request to the RD Gateway to create a channel. The RD Gateway responds with a TSProxyCreateChannel Response. This sequence is described in [MS-TSGU] section 1.3.

  5. For each channel, the RDP client sends a TSProxySetupReceivePipe Request to the RD Gateway to establish a pipe for data transfer. The RD Gateway responds with a TSProxySetupReceivePipe Response. This sequence is described in [MS-TSGU] section 1.3.

  6. By proxy, The RDP client initiates a connection to the RD Session Host by sending an X.224 Connection Request protocol data unit (PDU), as described in [MS-RDPBCGR] section 1.3.1.1. The server responds with an X.224 Connection Confirm PDU. All subsequent data sent between the RDP client and RD server is wrapped in an X.224 Data PDU.

  7. By proxy, basic settings are exchanged between the RDP client and RD Session Host using the Multipoint Communication Service (MCS) Connect Initial PDU and MCS Connect Response PDU, as described in [MS-RDPBCGR] section 1.3.1.1.

  8. By proxy, the RDP client sends an MCS Erect Domain Request PDU, followed by an MCS Attach User Request PDU to attach the primary user identity to the MCS domain, as described in [MS-RDPBCGR] section 1.3.1.1. The server responds with an MCS Attach User Confirm PDU containing the user channel ID.

  9. By proxy, the RDP client proceeds to join the user channel, I/O channel, and all virtual channels by using multiple MCS Channel Join Request PDUs, as described in [MS-RDPBCGR] section 1.3.1.1. The RD Session Host confirms each channel with an MCS Channel Join Confirm PDU. All subsequent data sent from the RDP client to the RD Session Host is wrapped in an MCS Send Data Request PDU, while data sent from the RD Session Host to the RDP client is wrapped in an MCS Send Data Indication PDU. This is in addition to the data being wrapped by an X.224 Data PDU.

  10. If Standard RDP security mechanisms and encryption are being used, which they are for this example, the RDP client sends a Security Exchange PDU containing an encrypted 32-byte random number to the RD Session Host, by proxy, as described in [MS-RDPBCGR] section 1.3.1.1. All subsequent RDP traffic is then encrypted and a security header is included with the data if encryption is in force. The security header follows the X.224 and MCS Headers and indicates whether the attached data is encrypted.

  11. By proxy, the RDP client sends secure client data (such as username, password, and auto-reconnect cookie) to the server using the Client Info PDU, as described in [MS-RDPBCGR] section 1.3.1.1.

  12. By proxy, the RDP client and RD Server exchange licensing-related packets that are defined by the licensing mechanisms employed by the RD Session Host, as described in [MS-RDPBCGR] section 1.3.1.1. Different licensing scenarios are possible and are covered in [MS-RDPELE] section 1.3.3. For this scenario it is assumed that a valid, nonexpired, license exists for the client on the License Server.

  13. By proxy, the RD Session Host sends the set of capabilities it supports to the RDP client in a Demand Active PDU, as described in [MS-RDPBCGR] (section 1.3.1.1). The RDP client responds with its capabilities by sending a Confirm Active PDU.

  14. By proxy, the RDP client and RD Session Host send PDUs to finalize the connection details, as described in [MS-RDPBCGR] section 1.3.1.1. The PDUs exchanged can be sent concurrently as long as the sequencing in either direction is maintained. After the RDP client receives the Font Map PDU, it can start sending mouse and keyboard input to the RD Session Host. After the RD Session Host receives the Font List PDU, the RD Session Host can start sending graphics output to the RDP client.