One Identity Safeguard for Privileged Sessions 6.0.12 - Release Notes

SSH connections fail when the SHA1-based ssh-rsa host key algorithm is disabled on the client or on the server.

SSH connections going through SPS 6.0.12 fail when the client or the server disables the SHA1-based ssh-rsa host key algorithm. The message "Unable to find a matching kex or host key algorithm" is logged in the system log. The cause of this issue was that the latest SSH software disabled the insecure ssh-rsa host key algorithm by default, which was the only algorithm supported by SPS. This issue has been fixed by adding support for the more secure SHA2-based rsa host key algorithms. SPS now offers the rsa-sha2-512, rsa-sha2-256 and ssh-rsa host key algorithms, in this order.

SPP detects that SPS is unavailable. The possible reason is that when SPP checks the "configuration_sync" field of the response from /api/cluster/status/<node-id> SPS does not fill out the "configuration_sync" field for the `central-management` node.

Now SPS fills out the "configuration_sync" field for the `central-management` node as an `up-to-date` node.

Due to an internal error, the local user could not change its own password.

Now the local user can change its own password.

Due to an unclean shutdown, the postgresql can not be upgraded.

Fixed issue by making the postgresql upgrade more robust.

Due to an unexpected side effect of a change in SPS versions 6.10.0 and 6.0.10, the AWS images were accidentally shipped with a hard-coded node ID. This prevented SPS nodes hosted on AWS from being able to join a cluster, and also the backup and the archival of the different nodes might have resulted in overwritten files.

Amazon images now come with a fixed node ID. The problem was fixed by changing the way the initial node ID was generated. Note that the node ID of existing installations are not changed, because the node ID change drops the node out of a management cluster and makes the previous archives and backups unavailable. Only the Amazon deployments were affected, the node ID on any other platforms has always been generated correctly on the first boot.

The validation of proxy settings name differed on the REST API and on the Web UI.

The validation has been synchronized and invalid proxy settings cannot be set anymore on the REST API. The cause of this issue was that REST API allowed '.' and '-' characters in the name of proxy settings, which resulted in an invalid configuration.

Incorrect handling of Remote Desktop Protocol (RDP) Dynamic Virtual Channels (DVCs). Due to the incorrect handling of DVCs which were rejected by the client or denied by policy, any of the following could occur, depending on the configuration:

• Allowing a DVC which should have been denied by policy

• Denying a DVC which should have been allowed by policy

• Recording a DVC in the audit trail which should not have been recorded

• Not recording a DVC which should have been recorded

• Recording a DVC with a wrong name in the audit trail

DVCs denied by policy or rejected by the client are now evaluated and recorded correctly. The Remote Desktop Protocol allows the use of DVCs, which may be opened and closed by the server anytime during an RDP connection, and the client is free to accept or reject such channels. In SPS, it is possible to define channel policy decisions for these DVCs. For example, it is possible to selectively allow or deny such channels based on their names, or to enable auditing for only some of them.