Connection Sequence
The goal of the RDP Connection Sequence is to exchange client and server settings and to specifycommon 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 ofthe 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 mustbe 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.