One Identity Safeguard for Privileged Sessions 6.9.2 - Upgrade Guide

After SPS 6.5, CentOS 6 operating systems will not be supported for external indexers. This means that after upgrading to SPS 6.5, or the LTS maintanance release in that cadence, you will not be able to use your external indexers that are running on CentOS 6. Make sure that you prepare your affected systems for this change and upgrade to CentOS 7 or later.

According to recent cryptographic research, SHA-1 algorithm cannot be trusted as secure anymore, because signatures can be forged with reasonable costs. As a result, SHA-1 algorithm is not supported in SPS for X.509 certificate chains. Starting from SPS versions 6.0.4 and 6.5.0, certificates with SHA1-based signatures are no longer trusted for Active Directory or LDAP authentication, and future versions might refuse to validate SHA-1 signatures altogether.

Note that Root CA certificates may still contain SHA-1 signatures, because the signature is not validated for self-signed certificates. It is expected that other software such as clients and servers connected to SPS might reject SHA-1 signatures in a similar fashion.

Signing CAs in SPS generate certificates with SHA-256 since versions 4.3.4 and 5.0.0.

SPS checks if the certificate revocation list (CRL) has expired and that the CRL has been signed by the same certificate authority (CA).

CAUTION: Upgrading to SPS 6.8 changes authenticating the users of the web interface with X.509 client certificates: certificates are validated against a trust store instead of a trusted CA list. During the upgrade, the trusted CA list formerly used for authentication is copied to a trust store that has revocation check disabled by default.

If you enabled revocation check for your trusted CA list and added the URLs of certificate revocation lists (CRL) before or you would like to enable revocation check, you have to edit the settings of the trust store manually. Navigate to Basic Settings > Trust Stores, select revocation check type Leaf or Full for the trust store and make sure you add a CRL URL for each root and intermediate CA.

For more information about trust stores and how to configure them, see "Verifying certificates with Certificate Authorities using trust stores" in the Administration Guide.

Make sure to check the value configured in Disk space fill-up prevention before starting the upgrade process. From SPS version 6.4, the value range of Disconnect clients when disks are: x percent used field in Basic Settings > Management > Disk space fill up prevention is limited to 50-98 percent. If your configured value is outside this range, you cannot start upgrading.

Upgrading to SPS 6.3.0 and later versions involves a reorganization in the internal data storage of SPS. As a result, several files are moved to new location during the upgrade process. Depending on the amount of data (logs, index files, reports, and so on) stored on the appliance, this can take a long time, usually at least 30 minutes. When you activate the new firmware file, an estimate will be displayed.

To avoid data loss, the appliance will not boot if this step of the upgrade fails. In this case, contact our Support Team.

Upgrading to SPS requires at least 10% free disk space.

Increase the amount of free disk space. For details, read Increasing the amount of available free disk space.

If increasing the amount of free disk space fails, or you encounter a different issue, contact our Support Team.

If you are authenticating your SPS users to an LDAP/Active Directory server, make sure that the response timeout of the LDAP/Active Directory server is at least 120 seconds.

• For SSH connections, X.509 host certificates are not supported, the related options have been removed from the product. One Identity recommends using public keys instead.

• For SSH connections, DSA keys are not supported, the related options have been removed from the product. One Identity recommends using RSA or Ed25519 keys instead.

• The log ingestion feature of SPS has been removed from the product.

Following the upgrade, support for less than 1024-bit SSH keys is lost.

It is no longer possible to search for screen contents indexed by the old Audit Player on the search UI and the REST interface. Searching in session metadata (such as IP addresses and usernames) and in extracted events (such as executed commands and window titles that appeared on the screen) remains possible.

As the old Audit Player was replaced and deprecated as an indexing tool during the 4.x versions, this should only affect very old sessions. Sessions that were processed by the new indexing service will work perfectly. If you wish to do screen content searches in historical sessions, contact our Support Team.