Processing Confirm Active PDU

The structure and fields of the Confirm Active PDU are described in section

If Enhanced RDP Security (section 5.4) is in effect, the External Security Protocol (section 5.4.5) being used to secure the connection 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 conditions mandating the presence of the securityHeader field, as well as the type of Security Header structure present in this field, are explained in section If the securityHeader field is present, the embedded flags field MUST be examined for the presence of the SEC_ENCRYPT (0x0008) flag (section, and if it is present the data following the securityHeader field MUST be verified and decrypted using the methods and techniques described in section 5.3.6. If the MAC signature is incorrect or the data cannot be decrypted correctly, the connection SHOULD be dropped.

The shareControlHeader field (which contains a Share Control Header as described in section MUST be examined to ensure that the PDU type (present in the pduType field) has the value PDUTYPE_CONFIRMACTIVEPDU (3).

The remaining PDU fields and capability data MUST be interpreted and processed according to sections and 2.2.7. The capabilities received from the client MUST be stored in the Client Capabilities store (section and MUST be used to determine what subset of RDP to send to the client.

After successfully processing the Confirm Active PDU, the server MUST send the Synchronize PDU (section to the client. If processing of the Confirm Active PDU was unsuccessful, the connection SHOULD be dropped.