One Identity Safeguard for Privileged Sessions 6.0 LTS - Administration Guide

Incomplete TSA response received

When using a TSA certificate generated with Windows Certificate Authority, you might see a similar error message:

Incomplete TSA response received, TSA HTTP server may be responding slowly; errno='Success (0)', timeout_seconds='30'

When generating the certificate, make sure that you do the following:

Optional Key Usage: If Key Usage is present, it must be digitalSignature and/or nonRepudiation. Other values are not permitted. Make sure that in Encryption, Allow key exchange without key encryption (key agreement) is selected.

For details, see Generating TSA certificate with Windows Certificate Authority on Windows Server 2008 or Generating TSA certificate with Windows Certificate Authority on Windows Server 2012.

Using UPN usernames in audited SSH connections

When you specify user names in a User Principal Name (UPN) format (e-mail address as username) for an SPS-audited SSH connection, the connection is unsuccessful.

The connection is unsuccessful because SPS uses the '@' character in the username as inband destination selection. If this happens, the username is stripped from the domain part and the UPN suffix is interpreted as inband target. For example, if using test@ema.il as username, the username for the connection will be 'test' and the inband destination is 'ema.il'. SPS interprets the last two '@' characters from the connection string, for example, username@my-inband-target@SPS.

To avoid this, you must use inband destination selection. By specifying the target host explicitly, you can prevent SPS to misinterpret the '@' character from UPN usernames.

• For more information, see the How to use UPN usernames in audited SSH connections Knowledge Base article.
• For more information about inband destination selection, see Using inband destination selection in SSH connections.

Configuring external devices

This section describes scenarios about configuring external devices to redirect selected traffic to One Identity Safeguard for Privileged Sessions (SPS).

Topics:

Join One Identity Safeguard for Privileged Sessions (SPS) to Safeguard for Privileged Passwords SPP

You can join your One Identity Safeguard for Privileged Sessions (SPS) deployment to your One Identity Safeguard for Privileged Passwords (SPP) deployment.

Prerequisites

• Your SPS deployment must be a SPS cluster (not a high-availability cluster, but a Central management cluster). Even if your SPS deployment consists of a single, standalone node, you must convert it to the Central management node of its own single-node cluster. For details, see Managing Safeguard for Privileged Sessions (SPS) clusters.

  Configuration synchronization must be enabled between the nodes of the SPS cluster. This is required so SPP entitlements work properly for each SPS node.

  NOTE: If you have multiple standalone SPS appliances, consider joining them to a cluster before joining SPP. In general, One Identity recommends creating a cluster if the nodes can use a common configuration, or later you might want to centrally search the data of every node. Creating a cluster from the SPS nodes after joining SPP is problematic and should be avoided.

• You will need the primary IP address or the hostname of your SPP deployment that SPS can use to access SPP. Only IPv4 addresses are supported.

• You will need the username and password to an SPP account that has "Appliance" and "Operations" permissions.

• Verify that your SPS policies do not contain the safeguard_default string in their names. During the join process, SPS automatically creates and configures several policies and plugins. The name of these policies usually contains the string safeguard_default. Existing policies with such names will be overwritten.

• The SPP and SPS nodes must be able to communicate on the tcp 8649 port. If needed, update your firewall policies.

• During the join process, SPS must be able to access SPP using HTTPS on the tcp 443 port. This is required only once during the join process. If needed, update your firewall policies.

To join your SPS deployment to SPP

1. (Optional) Create a configuration backup of SPS. For details, see Creating configuration backups.

2. (Optional) Create a configuration backup of SPP. For details, see the Safeguard for Privileged Passwords Administration Guide, Backup and Retention settings.

3. Login to the Central management node of your SPS cluster. This node has Central management listed in the Basic Settings > Cluster management > Roles field.

   Figure 302: Basic Settings > Cluster management — Joining SPS to SPP

   

4. Navigate to Basic Settings > Cluster management > Join to SPP cluster and enter the primary IP address of SPP into the IPv4 address or hostname of SPP to join field. Only IPv4 addresses are supported.

5. Click Join. Wait until you are redirected to SPP.

6. Login to SPP. Wait until you are redirected to SPS.

7. Wait until SPS creates and configures the policies and plugins required for the joint operation of SPS and SPP. This step can usually take up to a minute.

8. You will receive a message:

   • If the join is unsuccessful, this message displays: Request failed. Check the credentials and the IP address you provided. For details on resolving errors, see SPP to One Identity Safeguard for Privileged Sessions (SPS) join issues and Safeguard for Privileged Passwords (SPP) to One Identity Safeguard for Privileged Sessions (SPS) join error resolution

   • If the join is successful, this message displays: SPS successfully joined to SPP. SPP automatically closes any open access requests.

9. Log out from the SPS web interface.