The following describes what happens when a client connects to a server through One Identity Safeguard for Privileged Sessions (SPS) and how the different configuration options and policies of SPS affect this process.

1. Client-side connection

   The client tries to connect to the server. SPS receives the connection request and establishes the TCP connection with the client.

2. SPS examines the connection request: it checks the IP address of the client and the IP address and port number of the intended destination server. If these parameters of the request match a connection policy configured on SPS, SPS inspects the connection in detail. Other connections are ignored by SPS, and simply forwarded on the packet level.

   The selected connection policy determines all settings and parameters of the connection.

   NOTE:

   SPS compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. SPS applies to the connection the first connection policy that completely matches the connection request.

   For details, see Configuring connections.

3. SPS selects the destination server based on the Target parameter of the connection policy. Network address translation of the target address can be performed at this step. For details, see Modifying the destination address.

4. SPS selects the source address used in the server-side connection based on the SNAT parameter of the connection policy. For details, see Modifying the source address.

5. If an AA plugin is configured in SPS, the client may be prompted to provide additional information when authenticating to the server. For details on the AA plugin, see Integrating external authentication and authorization systems. Note that if the plugin sets or overrides the username of the connection, a Usermapping policy needs to be configured and set in the Connection policy. For further information, see Configuring usermapping policies.

6. SPS checks if the client uses a version of the RDP protocol that is enabled in the Protocol settings of the Connection policy. Depending on the protocol version, different encryption is used in the connection, and different parameters are required in the Connection policy.

7. Before establishing the server-side connection, SPS can evaluate the channel policy to determine if the connection might be permitted at all, for example, it is not denied by a Time policy. SPS performs this check if the RDP Control > Settings > Enable pre channel check option is enabled. For details, see Creating and editing protocol-level RDP settings.

8. Server-side connection

   1. SPS establishes the TCP connection to the server.

   2. SPS checks the protocol parameters of the connection (for example, the version of the RDP protocol used ) according to the Protocol settings of the Connection policy. The RDP handshake is performed simultaneously on the server- and the client-side.

9. The server opens a Drawing channel for the user to perform authentication.

10. SPS authorizes the connection based on the Channel policy. It checks:

    • If the Channel policy includes a User List restriction for the Gateway group or Remote group, SPS checks if the user can access the server. If needed, SPS connects to the LDAP servers set in the LDAP Servers policy to resolve the group memberships of the user. For details, see Creating and editing user lists.

    • SPS consults the Time policy assigned to the channel policy. Channels may be opened only within the allowed period.

      TIP: Time policies are a good way to ensure that the server can be accessed only within the specified timeframe.

11. If the Gateway authentication option is set in the Connection policy, SPS pauses the connection until the user completes a gateway authentication on the SPS web interface. This is out-of-band authentication, since it is performed in an independent connection. For details, see The gateway authentication process.

    It is also possible to perform gateway authentication inband, without having to access SPS's web interface. For details, see Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) using an RD Gateway.

12. SPS performs the authentication on the server, using the data received from:

    • the client during the client-side authentication, or

    • a local or external Credential Store (for details, see Using credential stores for server-side authentication).

13. If the authentication fails for any reason, SPS terminates the client-side connection as well. This is required to verify the username of the client when it attempts to access the server again.

14. If 4-eyes authorization is set in the Channel policy, the RDP session of the client is paused until the authorizer permits the client to connect to the server. Who can authorize the session depends on the Access Control settings of the Connection policy. For details, see Four-eyes authorization.

15. The client starts to work on the server. Information about the connection is now available on the Search page.

    • SPS records the entire communication into digitally encrypted audit trails if auditing is enabled in the Channel policy, and encryption is configured in the Audit policy used in the Connection policy. For details, see Creating and editing channel policies and Audit policies.

    • If a Content policy is configured in the Channel policy, SPS monitors the connection in real time, and raises an alert or terminates the connection if the user performs an undesired action. For details, see Real-time content monitoring with Content Policies.

    If the user opens another channel within the same connection, SPS consults the Channel policy of the connection to see if the channel is permitted, and processes it accordingly.

16. Post-processing the connection

    Once the connection has been closed, the following post-processing steps take place:

    1. After the client closes the connection, or it is terminated for some reason (for example, it times out, or a Content policy or a 4-eyes auditor terminates it), SPS indexes the contents of the audit trail (if the Record audit trail option of the Channel policy, and the Enable indexing option of the Connection policy are enabled).

    2. SPS creates a backup of the data and the audit trail of the connection, and archives it to a remote server, if a Backup policy and an Archive policy is set in the Connection policy. For more information, see Data and configuration backups and Archiving.

    3. When the Delete search metadata from SPS after period expires, SPS deletes all data about the connection from its database.