Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 5.9.0 - Administration Guide

Preface Introduction The concepts of SPS The Welcome Wizard and the first login Basic settings User management and access control Managing SPS
Controlling SPS: reboot, shutdown Managing Safeguard for Privileged Sessions clusters Managing a high availability SPS cluster Upgrading SPS Managing the SPS license Accessing the SPS console Sealed mode Out-of-band management of SPS Managing the certificates used on 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 (classic) interface Using the Search interface Searching session data on a central node in a cluster Advanced authentication and authorization techniques Reports The SPS RPC API The SPS REST API SPS scenarios Troubleshooting SPS Configuring external devices Using SCP with agent-forwarding Security checklist for configuring SPS Jumplists for in-product help Third-party contributions About us

Maximizing the scope of auditing

In certain special scenarios, SPS may examine and audit network traffic with some limitations, depending on the configuration.

In the first scenario, your organization uses jump hosts to access remote servers or services. In this case, SPS ignores the connection between the target server and the remote server, as it does not go through SPS.

Figure 13: Connection to a remote server through a jump host

In the next scenario, a file operation is performed going from the target server to the client (for example, copying a file using SCP). In this case, the direction of the connection is switched, as compared to the initial client-to-server direction.

Figure 14: File operation in the "reverse" direction

In these scenarios, SPS may not:

  • Restrict channels allowed in the connection.

  • Audit file operations.

    When you wish to search for the audit files of these connections, there will be no results returned on the Search page.

  • Allow authentication on the remote server if the user authenticates to the target server using a Credential Store.

If you want all connections in these scenarios to be audited, make sure that you add a connection policy for:

  • The connection between the target server and any remote servers.

  • The connection going from the target server to the client.

IPv6 in SPS

SPS supports IPv6 for monitoring connections only. You can define both IPv4 and IPv6 addresses for its logical network interfaces, and configure connections between IPv4 and IPv6 networks (for example, from a client with an IPv4 address to a target with an IPv6 address). You can also use IPv6 addresses with inband destination selection.

NOTE:

IPv6 support in ICA connections is currently experimental only.

When configuring IPv6 addresses, SPS shortens the address to its canonical form (omitting leading zeroes, and replacing consecutive sections of zeroes with a double colon). Take the following address as an example:

2001:0db8:0000:0000:0000:ff00:0042:8329

SPS shortens the address to its canonical form:

[2001:db8::ff00:42:8329]

Additionally, where the IP address and the port is displayed together, IPv6 addresses are shown between brackets. For example, the same address with a port number of 443 is displayed as:

[2001:db8::ff00:42:8329]:443

You can search for both the initial (full) and the canonical form on the SPS Search page. For searches performed using the RPC API, you have to use the canonical form.

To provide the network range for IPv6 addresses, use network prefixes. Pay attention to the differences between IPv4 and IPv6 network ranges: for IPv4, you can limit the address range to a single address with a prefix of /32, but to achieve the same on an IPv6 network, you have to use set the prefix to /128.

SSH hostkeys

SSH communication authenticates the remote SSH server using public-key cryptography, either using plain hostkeys, or X.509 certificates. Client authentication can also use public-key cryptography. The identity of the remote server can be verified by inspecting its hostkey or certificate. When trying to connect to a server via SPS, the client sees a hostkey (or certificate) shown by SPS. This key is either the hostkey of SPS, or the original hostkey of the server, provided that the private key of the server has been uploaded to SPS. In the latter case, the client will not notice any difference and have no knowledge that it is not communicating directly with the server, but with SPS.

Authenticating clients using public-key authentication in SSH

Public-key authentication requires a private and a public key (or an X.509 certificate) to be available on SPS. First, the public key of the user is needed to verify the user's identity in the client-side SSH connection: the key presented by the client is compared to the one stored on SPS. SPS uses a private key to authenticate itself to the sever in the server-side connection. SPS can use the private key of the user if it is uploaded to SPS. Alternatively, SPS can generate a new keypair, and use its private key for the server-side authentication, or use agent-forwarding, and authenticate the client with its own key.

Caution:

If SPS generates the private key for the server-side authentication, then the public part of the keypair must be imported to the server, otherwise the authentication will fail. Alternatively, SPS can upload the public key (or a generated X.509 certificate) into an LDAP database.

Related Documents