Export (0) Print
Expand All

5.5 Automatic Reconnection

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 may 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 (see 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 (see 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 (see [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)

    The one-way HMAC transformation prevents an unauthenticated server from obtaining the original auto-reconnect random and replaying it for the purpose of connecting to the user's existing session.

    When Enhanced RDP Security is in effect the client random value is not generated (see 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 16 zero bytes, that is, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }. This effectively means that the derived security verifier will always have the same value when carrying out auto-reconnect under the Enhanced RDP Security. Hence, care must be taken to authenticate the identity of the server to which the client is reconnecting, ensuring that the identity has not changed in the period between connections.

  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 must obtain 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.

 
Show:
© 2015 Microsoft