Converse agora com nosso suporte
Chat com o suporte

One Identity Safeguard for Privileged Sessions 6.0 LTS - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS) The Welcome Wizard and the first login Basic settings
Supported web browsers and operating systems The structure of the web interface Network settings Configuring date and time System logging, SNMP and e-mail alerts Configuring system monitoring on SPS Data and configuration backups Archiving and cleanup Forwarding data to third-party systems Joining to One Identity Starling
User management and access control Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing Safeguard for Privileged Sessions (SPS) clusters Managing a high availability One Identity Safeguard for Privileged Sessions (SPS) cluster Upgrading One Identity Safeguard for Privileged Sessions (SPS) Managing the One Identity Safeguard for Privileged Sessions (SPS) license Accessing the One Identity Safeguard for Privileged Sessions (SPS) console Sealed mode Out-of-band management of One Identity Safeguard for Privileged Sessions (SPS) Managing the certificates used on One Identity Safeguard for Privileged Sessions (SPS)
General connection settings HTTP-specific settings ICA-specific settings RDP-specific settings SSH-specific settings Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Searching session data on a central node in a cluster Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) RPC API The One Identity Safeguard for Privileged Sessions (SPS) REST API One Identity Safeguard for Privileged Sessions (SPS) scenarios Troubleshooting One Identity Safeguard for Privileged Sessions (SPS) Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help LDAP user and group resolution in SPS Appendix: Deprecated features

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.

Caution:

In Encryption, do NOT select Allow key exchange only with key encryption (key encipherment), because it will result in errors.

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.

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:

  9. Log out from the SPS web interface.

Caution:

If the primary IP address of your SPS or SPP changes, you must repeat this procedure to rejoin the clusters.

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação