One Identity Safeguard for Privileged Sessions 6.8.1 - Administration Guide

Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) using RDP

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:

   One Identity Safeguard for Privileged Sessions (SPS) compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. The first connection policy completely matching the connection request is applied to the connection.

   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 and cleanup.

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

Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) using an RD Gateway

The following describes what happens when a client connects a server through One Identity Safeguard for Privileged Sessions (SPS) using a Remote Desktop Gateway (or RD Gateway), and how the different configuration options and policies of SPS affect this process. For details on the configuration process, see Using One Identity Safeguard for Privileged Sessions (SPS) as a Remote Desktop Gateway.

1. The client connects to port 443 of the Remote Desktop Gateway configured in the Remote Desktop software. The address of the Remote Desktop Gateway is an alias IP address of SPS. To process the connection request, SPS must have a Connection policy that is configured to handle RDP connection requests on the alias IP, and that has the Act as a Remote Desktop Gateway option enabled.

2. The client authenticates on Remote Desktop Gateway (that is, on SPS). Technically, this is an inband gateway authentication on the Domain Controller of SPS's domain (SPS must be the member of a domain, for details, see Network Level Authentication (NLA) with domain membership). The username used in this authentication step is referred to as the Gateway username and is used to determine the Gateway group memberships of the user.

3. The client tries to connect to the server. From this point on, this connection is processed as described in Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) using RDP.

Archive and backup concepts

You can export, backup and save various types of data from One Identity Safeguard for Privileged Sessions (SPS), and it also creates log files, dumps and bundles to help the Support Team in troubleshooting errors.

Figure 12: Archive and backup concepts

The following sections describe these in detail:

• Configuration export

• System backup

• Connection backup

• Connection archive

• Support bundle

• Debug logs

• Connection logs

• Core dump files

Configuration export

The configuration of One Identity Safeguard for Privileged Sessions (SPS) can be exported to your local machine from the Basic Settings > System > Export configuration page. The configuration export in itself is always a one-time action that cannot be configured in policies. However, the system backup (System backup), that contains the configuration export in addition to other items, can be configured as a scheduled policy and is saved to a backup server.

The exported file is a gzip-compressed archive. On Windows platforms, it can be decompressed with common archive managers such as the free 7-Zip tool.

The name of the exported file is <hostname_of_SPS>-YYYMMDDTHHMM.config, the -encrypted or -gpg suffix is added for password-encrypted and GPG-encrypted files, respectively. Because the configuration export contains highly sensitive information, it is strongly suggested that you use encryption when generating the export.

For details on how to export the configuration of SPS, see: Exporting the configuration of SPS.