Compartilhar via

5.5 Automatic Reconnection

  • Artigo

The Automatic Reconnection feature allows a client to reconnect to an existing session (after a short-term network failure has occurred) without having to resend the user's credentials to the server. A connection which employs Automatic Reconnection proceeds as follows:

  1. The user logs in to a new or existing session. As soon as the user has been authenticated, a Server Auto-Reconnect Packet (section 2.2.4.2) is generated by the server and sent to the client in the Save Session Info PDU (section 2.2.10.1). The Auto-Reconnect Packet (also called the auto-reconnect cookie) contains a 16-byte cryptographically secure random number (called the auto-reconnect random) and the ID of the session to which the user has connected.

  2. The client receives the cookie and stores it in memory, never allowing programmatic access to it.

  3. In the case of a disconnection due to a network error, the client attempts to reconnect to the server by trying to reconnect continuously or for a predetermined number of times. Once it has connected, the client and server can exchange large random numbers (the client and server random specified in section 5.3.4). If Enhanced RDP Security (section 5.4) is in effect, no client random is sent to the server (section 5.3.2).

  4. The client derives a 16-byte security verifier from the random number contained in the auto-reconnect cookie received in Step 2. This security verifier is wrapped in a Client Auto-Reconnect Packet (section 2.2.4.3) and sent to the server as part of the extended information (section 2.2.1.11.1.1.1) of the Client Info PDU (section 2.2.1.11).

    The auto-reconnect random is used to key the HMAC function ([RFC2104]), which uses MD5 as the iterative hash function. The security verifier is derived by applying the HMAC to the client random received in Step 3.

     SecurityVerifier = HMAC(AutoReconnectRandom, ClientRandom)

    When Enhanced RDP Security is in effect the client random value is not generated (section 5.3.2). In this case, for the purpose of generating the security verifier, the client random is assumed to be an array of 32 zero bytes. This implies that the derived security verifier will always have the same value for a given auto-reconnect random when auto-reconnecting with Enhanced RDP Security.

  5. When the server receives the Client Auto-Reconnect Packet, it looks up the auto-reconnect random for the session and computes the security verifier using the client random (the same calculation executed by the client). If the security verifier value which the client transmitted matches the one computed by the server, the client is granted access. At this point, the server has confirmed that the client requesting auto-reconnection was the last one connected to the session in question.

  6. If the check in Step 5 passes, then the client is automatically reconnected to the desired session; otherwise the client obtains the user's credentials to regain access to the session on the remote server.

The auto-reconnect cookie associated with a given session is flushed and regenerated whenever a client connects to the session or the session is reset. This ensures that if a different client connects to the session, then any previous clients which were connected can no longer use the auto-reconnect mechanism to connect. Furthermore, the server invalidates and updates the cookie at hourly intervals, sending the new cookie to the client in the Save Session Info PDU.