Welcome to One Identity Safeguard for Privileged Sessions (SPS) version 6.9.5 and thank you for choosing our product. This document describes the upgrade process from existing SPS installations to SPS 6.9.5. The main goal of this paper is to help system administrators in planning the migration to the new version of SPS.
|
|
Caution:
Read the entire document thoroughly before starting the upgrade. |
This document covers the One Identity Safeguard for Privileged Sessions 6.9.5 product.
The following release policy applies to One Identity Safeguard for Privileged Sessions (SPS):
One Identity Safeguard for Privileged Sessions customers choose between two paths for receiving SPS releases: Long Term Supported (LTS) release or feature release.
| LTS release | Feature release | |
| Release frequency |
Frequency: Typically, every 2 years Scope: Includes new features, resolved issues and security updates Versioning: First digit identifies the LTS and the second digit is a 0 (for example, 6.0, 7.0, and so on) |
Frequency: Typically, every 2 months Scope: Includes the latest features, resolved issues, and other updates, such as security patches for the OS Versioning: First digit identifies the LTS and the second digit is a number identifying the feature release (for example, 6.1, 6.2, and so on) |
| Maintenance release |
Frequency:Typically, every 2 months during full support Scope: Includes critical resolved issues Versioning: Third digit designates the LTS maintenance release (for example, 6.0.1) |
Frequency:Only for highly critical issues Scope: Includes highly critical resolved issue Versioning: Third digit designates the feature maintenance release (for example, 6.1.1) |
|
Support |
Typically 3 years after the original publication date or until the next LTS is published (whichever date is later) |
Typically 6 months after the original publication date or until the next feature or LTS release is published (whichever date is later) |
For a full description of long-term-supported and feature releases, open the SPS product page on the Support Portal and navigate to Self Service Tools > Product Support > Product Life Cycle & Policies > Product Support Policies > Software Product Support Lifecycle Policy.
|
|
Caution:
Downgrading from a feature release is not supported. If you upgrade from an LTS release (for example, 6.0) to a feature release (6.1), you have to keep upgrading with each new feature release until the next LTS version (in this case, 7.0) is published. |
This section describes the requirements and steps to perform before starting the SPS upgrade process.
General requirements:
You must have a valid software subscription to be able to download the new version of SPS.
You will need a support portal account to download the required ISO image. Note that the registration is not automatic, and might take up to two working days to be processed.
Back up your configuration and your data.
For more information on creating configuration and data backups, see "Data and configuration backups" in the Administration Guide.
Export your configuration.
For more information, see "Exporting the configuration of One Identity Safeguard for Privileged Sessions (SPS)" in the Administration Guide.
Verify that SPS is in good condition (no issues are displayed on the System Monitor).
Optional: If you have core dump files that are necessary for debugging, download them from Basic Settings > Troubleshooting > Core files. These files are removed during the upgrade process.
If you have a high availability cluster:
Verify that you have IPMI access to the slave node. You can find detailed information on using the IPMI in the following documents:
For Safeguard Sessions Appliance 3000 and 3500, see the X9 SMT IPMI User's Guide.
On the Basic Settings > High Availability page, verify that the HA status is not degraded.
If you are upgrading SPS in a virtual environment:
Create a snapshot of the virtual machine before starting the upgrade process.
Configure and enable console redirection (if the virtual environment allows it).
If you are using a plugin (for example, a Credential Store plugin, or a multi-factor authentication plugin):
You will need an updated version of the plugin you are using. Download it from Downloads page.
NOTE: Version 2.2.0 and later of the One Identity Starling Two-Factor Authentication plugin works only if you have joined your SPS deployment to Starling.
If you want use version 2.2.0 and later of the One Identity Starling Two-Factor Authentication plugin, complete the "Starling integration" in the Administration Guide procedure before upgrading the plugin.
The following is a list of important notes and warnings about the upgrade process and changes in SPS 6.9.5.
|
|
Caution:
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. |
|
|
Caution:
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. |
|
|
Caution:
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. |
|
|
Caution:
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. |
|
|
Caution:
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. |
NOTE: Version 2.2.0 and later of the One Identity Starling Two-Factor Authentication plugin works only if you have joined your SPS deployment to Starling.
If you want use version 2.2.0 and later of the One Identity Starling Two-Factor Authentication plugin, complete the "Starling integration" in the Administration Guide procedure before upgrading the plugin.
|
|
Caution:
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. |
|
|
Caution:
|
|
|
Caution:
Following the upgrade, support for less than 1024-bit SSH keys is lost. |
|
|
Caution:
When the client uses hostname in inband destination selections, the hostname must comply with RFC5890: Internationalized Domain Names for Applications (IDNA). For example, from the ASCII characters only letters, digits, and the hyphen character is permitted. Starting with version 6.1.0, SPS rejects connection requests where the hostname does not comply with RFC5890. |
NOTE: Due to legal reasons, installation packages of the external indexer application will be available only from the SPS web interface. After SPS versions 6.4 and 6.0.3 are released, the installation packages will be removed from our website.
|
|
Caution:
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. |
Starting from 6.8.0, the default protocol-level settings for RDP connections have changed and NLA is now enabled by default in the RDP setting policies.
Due to this change:
The default RDP setting is now default_nla, where NLA is enabled.
The RDP setting, which was previously called default has been renamed to legacy_default.
RDP 4-style authentication is now cleared by default.
NOTE: If you are upgrading from an SPS version earlier than 6.8.0, and you have an existing RDP setting named legacy_default or default_nla, you must rename it before upgrade.
Upgrading to SPS 6.9.5 is tested and supported using the following upgrade path:
The latest SPS 6 LTS maintenance version (for example, 6.0.x) -> SPS 6.9.5
Always upgrade to the latest available maintenance version of SPS 6 LTS before upgrading to SPS 6.9.5.
The latest maintenance versions of the previous three feature releases since the last LTS release (in this case, SPS 6.6 or later) -> SPS 6.9.5
Always upgrade to the latest available maintenance version of the feature release before upgrading to SPS 6.9.5.
From older releases, upgrade to 6 LTS first. For details, see How to upgrade to One Identity Safeguard for Privileged Sessions 6 LTS.
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center
