3.3.5.3.11 Processing Client Info PDU

  • Article

The structure and fields of the Client Info PDU are specified in section 2.2.1.11.

If Enhanced RDP Security (section 5.4) is in effect, the External Security Protocol (section 5.4.5) MUST be used to decrypt and verify the integrity of the entire PDU prior to any processing taking place.

The embedded length fields within the tpktHeader ([T123] section 8) and the mcsSDrq ([T125] section 7, parts 7 and 10) fields MUST be examined for consistency with the received data. If there is any discrepancy, the connection SHOULD be dropped.

The embedded channelId field within the mcsSDrq is used to route the PDU to the appropriate target channel.

The securityHeader field MUST always be present and it MUST contain at least a Basic Security Header structure (section 2.2.8.1.1.2.1). The embedded flags field of the securityHeader MUST contain the SEC_INFO_PKT (0x0040) flag (described in section 2.2.8.1.1.2.1). If this flag is not present then the packet cannot be interpreted as a Client Info PDU (section 2.2.1.11), and the connection SHOULD be dropped. If the SEC_ENCRYPT (0x0008) flag is present, then the data following the securityHeader field is encrypted and it MUST be verified and decrypted using the methods and techniques specified in section 5.3.6. If the Encryption Level (section 5.3.1) selected by the server (sections 5.3.2 and 2.2.1.4.3) is ENCRYPTION_LEVEL_NONE (0) the SEC_ENCRYPT flag MAY<47> be set incorrectly. In this case the Encryption Level setting MUST be respected and the value of the flag MUST be ignored. If the MAC signature is incorrect or the data cannot be decrypted correctly, the connection SHOULD be dropped.

Before reading the client settings fields, the format of the character data MUST be determined by testing for the presence of the INFO_UNICODE (0x00000010) flag (section 2.2.1.11.1.1). If the flag is present, all character data MUST be interpreted as Unicode; otherwise, it MUST be treated as ANSI characters.

All of the received client settings are stored in the Received Client Data store (section 3.3.1.1). When storing character data, the server SHOULD only save the maximum allowed sizes specified in section 2.2.1.11.1.1. For example, the maximum specified size for the AlternateShell field is 512 bytes. If received data is larger than this size, it SHOULD be truncated to 512 bytes in length (including the mandatory null terminator) when it is stored.

If there is not enough received data to completely read a variable-length field, the connection SHOULD be dropped. For example, if the cbAlternateShell field contains a value of 44 bytes, but only 30 bytes remain to be parsed, the connection SHOULD be dropped.

If an auto-reconnect cookie exists in the autoReconnectCookie field, the server SHOULD store the cookie in the Automatic Reconnection Cookie store (section 3.3.1.10)and use it to log on the user once the connection sequence completes (for a description of how automatic reconnection works, see section 5.5). If logon with the cookie fails, the credentials supplied in the Client Info PDU SHOULD be used, or alternatively the user MAY enter credentials at a server-side prompt remoted using RDP.

Once the server has successfully processed the Client Info PDU, it can enter the Licensing phase of the RDP Connection Sequence and carry out a licensing exchange with the client (see section 1.3.1.1 for an overview of the RDP Connection Sequence phases).