RDP Overviewe - Message Flows

Connection Sequence 

The goal of the RDP Connection Sequence is to exchange client and server settings and to specify 
common settings to use for the duration of the connection so that input, graphics, and other data 
can be exchanged and processed between client and server. The RDP Connection Sequence is 
described in following figure. All of the message exchanges in this diagram are strictly sequential, 

except where noted in the text that follows.

Table 1. Remote Desktop Protocol (RDP) connection sequence 

Type	Request/Respond Command	Direction
Connection Initiation	X.224 Connection Request PDU	C -> S
	X.224 Connection Confirm PDU	S <- C
Basic Settings Exchange	MCS Connect Initial PDU with GCC Conference Create Request	C -> S
	MCS Connect Response PDU with GCC Conference Cteate Response	S <- C
Channel Connection	MCS Erect Domain Request PDU	C -> S
	MSC Attach User Request PDU	C -> S
	MCS Attach User Confirm PDU	S <- C
	MCS Channel Join Request PDU(s)	C -> S
	MCS Channel Join Confirm PDU(s)	S <- C
RDP Security Commencement	Security Exchange PDU	C -> S
Security Exchange	Client Info PDU	C -> S
Licensing	License Error PDU - Valid Client	S <- C
Capabilities Exchange	Demand Active PDU	C -> S
	Confirm Active PDU	S <- C
Connection Finalization	Synchronize PDU	C -> S
	Control PDU - Cooperate	C -> S
	Persistent Key List PDU(s)	C -> S
	Font List PDU	C -> S
	Synchronize PDU	S <- C
	Control PDU - Granted Control	S <- C
	Font Map PDU	S <- C

Notes: The connection sequence can be broken up into eight distinct phases: 

1.  Connection Initiation: The client initiates the connection by sending the server a Class 0 X.224 

Connection Request PDU (section 2.2.1.1). The server responds with a Class 0 X.224 Connection 
Confirm PDU (section 2.2.1.2). 
From this point, all subsequent data sent between client and server is wrapped in an X.224 Data 
Protocol Data Unit (PDU). 
2.  Basic Settings Exchange: Basic settings are exchanged between the client and server by using 
the MCS Connect Initial PDU (section 2.2.1.3) and MCS Connect Response PDU (section 2.2.1.4). 
The Connect Initial PDU contains a Generic Conference Control (GCC) Conference Create 
Request, while the Connect Response PDU contains a GCC Conference Create Response.

These two GCC packets contain concatenated blocks of settings data (such as core data, security 
data, and network data) which are read by client and server. 

3.  Channel Connection: The client sends an MCS Erect Domain Request PDU (section 2.2.1.5), 
followed by an MCS Attach User Request PDU (section 2.2.1.6) to attach the primary user 
identity to the MCS domain. The server responds with an MCS Attach User Confirm PDU (section 
2.2.1.7) containing the User Channel ID. The client then proceeds to join the user channel, the 
input/output (I/O) channel, and all of the static virtual channels (the I/O and static virtual 
channel IDs are obtained from the data embedded in the GCC packets) by using multiple MCS 
Channel Join Request PDUs (section 2.2.1.8). The server confirms each channel with an MCS 
Channel Join Confirm PDU (section 2.2.1.9). (The client only sends a Channel Join Request after 
it has received the Channel Join Confirm for the previously sent request.)  
From this point, all subsequent data sent from the client to the server is wrapped in an MCS Send 
Data Request PDU, while data sent from the server to the 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. 
4.  RDP Security Commencement: If Standard RDP Security mechanisms (section 5.3) are being 
employed and encryption is in force (this is determined by examining the data embedded in the 
GCC Conference Create Response packet) then the client sends a Security Exchange PDU (section 
2.2.1.10) containing an encrypted 32-byte random number to the server. This random number is 
encrypted with the public key of the server as described in section 5.3.4.1 (the server's public 
key, as well as a 32-byte server-generated random number, are both obtained from the data 
embedded in the GCC Conference Create Response packet). The client and server then utilize the 
two 32-byte random numbers to generate session keys which are used to encrypt and validate 
the integrity of subsequent RDP traffic.  
From this point, all subsequent RDP traffic can be encrypted and a security header is included 
with the data if encryption is in force. (The Client Info PDU (section 2.2.1.11) and licensing PDUs 

([MS-RDPELE] section 2.2.2) are an exception in that they always have a security header). The 
Security Header follows the X.224 and MCS Headers and indicates whether the attached data is 
encrypted. Even if encryption is in force, server-to-client traffic may not always be encrypted, 
while client-to-server traffic must always be encrypted (encryption of licensing PDUs is optional, 
however). 
5.  Secure Settings Exchange: Secure client data (such as the username, password, and auto-reconnect cookie) is sent to the server by using the Client Info PDU (section 2.2.1.11). 
6.  Licensing: The goal of the licensing exchange is to transfer a license from the server to the client. 
The client stores this license and on subsequent connections sends the license to the server for 
validation. However, in some situations the client may not be issued a license to store. In effect, 
the packets exchanged during this phase of the protocol depend on the licensing mechanisms 
employed by the server. Within the context of this document, it is assumed that the client will 
not be issued a license to store. For details regarding more advanced licensing scenarios that 
take place during the Licensing Phase, see [MS-RDPELE] section 1.3. 
7.  Capabilities Exchange: The server sends the set of capabilities it supports to the client in a 
Demand Active PDU (section 2.2.1.13.1). The client responds with its capabilities by sending a 
Confirm Active PDU (section 2.2.1.13.2).  
8.  Connection Finalization: The client and server exchange PDUs to finalize the connection details. 
The client-to-server PDUs sent during this phase have no dependencies on any of the server-to-client PDUs; they may be sent as a single batch, provided that sequencing is maintained. 

2. Security-Enhanced Connection Sequence 

The RDP Connection Sequence does not provide any mechanisms which ensure that the identity of 
the server is authenticated, and as a result it is vulnerable to man-in-the-middle attacks (these 
attacks can compromise the confidentiality of the data sent between client and server). 
The goal of the Security-Enhanced Connection Sequence is to provide an extensible mechanism 
within RDP so that well-known and proven security protocols (such as Secure Socket Layer (SSL) or 
Kerberos) can be used to fulfill security objectives and to wrap RDP traffic. There are two variations 
of the Security-Enhanced Connection Sequence. The negotiation-based approach aims to provide 
backward-compatibility with previous RDP implementations, while the Direct Approach favors more 
rigorous security over interoperability.  
Negotiation-Based Approach: The client advertises the security packages which it supports (by 
appending a negotiation request structure to the X.224 Connection Request PDU) and the server 
selects the package to use (by appending a negotiation response structure to the X.224 Connection 
Confirm PDU). After the client receives the X.224 Connection Confirm PDU the handshake messages 
defined by the negotiated security package are exchanged and then all subsequent RDP traffic is 
secured by using the cryptographic techniques specified by the negotiated security package. 
Direct Approach: Instead of negotiating a security package, the client and server immediately 
execute a predetermined security protocol (for example, the CredSSP Protocol) prior to any RDP 
traffic being exchanged on the wire. This approach results in all RDP traffic being secured using the 
hard-coded security package. However, it has the disadvantage of not working with servers that 
expect the connection sequence to be initiated by an X.224 Connection Request PDU. 

3. Deactivation-Reactivation Sequence 

After the connection sequence has run to completion, the server may determine that the client must 
be connected to an existing session. To accomplish this task the server signals the client with a 
Deactivate All PDU. A Deactivate All PDU implies that the connection will be dropped or that a 
capability re-exchange will occur. If a capability re-exchange is required, then the Capability 
Exchange and Connection Finalization phases of the connection sequence (section 1.3.1.1) are re-executed.