You now have the option to configure connection policies with near real-time indexing priority, meaning that you can start indexing sessions while they are still ongoing. This requires that you configure your indexers with the appropriate settings and capabilities. For details, see "Configuring the internal indexer" in the Administration Guide and "Configuring the external indexer" in the Administration Guide.
The external indexers now support using Hardware Security Modules to process encrypted audit trails. For details, see "Configuring a hardware security module (HSM) or smart card to integrate with external indexer" in the Administration Guide.
One Identity Safeguard for Privileged Sessions is capable of analyzing the contents of the sessions it monitors to provide help analytics and speed up forensics investigations. This process is called indexing.
You can now select the depth of indexing: lightweight and full indexing.
Lightweight indexing is now enabled by default in case of a newly installed SPS or when you add new connection policies. If indexing was enabled for a connection policy it is converted to full indexing automatically during the upgrade.
Lightweight indexing is significantly faster than full indexing, but it extracts only the executed commands and the window titles that appear on the screen. It does not index any other screen content (for example, text that is displayed in a terminal or that appears in an RDP window).
For more information, see "Configuring the internal indexer" in the Administration Guide.
To make the text displayed in graphical sessions (for example, RDP) SPS uses optical character recognition. The way this is done has been greatly optimized. Depending on the exact scenario and the contents of the session, this can significantly decrease the time required to index the audit trails.
It is now possible to change the accuracy level of the Optical Character Recognition (OCR) analysis of graphical sessions. The accuracy level remains unchanged for existing indexer policies but the new default is the "balanced" setting that offers much improved performance with a minimal trade-off in accuracy.
For details, see "Configuring the internal indexer" in the Administration Guide.
The Safeguard Desktop Player application can now replay audit trails that contain graphical X11 sessions (the contents of the X11 Forward channel of the SSH protocol).
For further details, see "Replay X11 sessions" in the Safeguard Desktop Player User Guide.
It is now possible to install the Safeguard Desktop Player application on Mac.
For more information, see "Install Safeguard Desktop Player on Mac" in the Safeguard Desktop Player User Guide.
It is now possible to follow active connections in semi-real time using Safeguard Desktop Player. In case you notice some user action that poses a security risk, you have the option to terminate the session you are monitoring. For detailed information, see "Replay audit files in follow mode" in the Safeguard Desktop Player User Guide
|
Caution:
One Identity Safeguard for Privileged Sessions (SPS) 5 F4 and later versions use a new encryption algorithm to encrypt the recorded audit trails (AES128-GCM). This change has the following effects:
|
You can now manually re-encrypt your audit trails with a new encryption key. This is useful if you want to share encrypted audit trails with third parties — the data remains encrypted, but you do not have to share your encryption keys. For details, see "Sharing an encrypted audit trail" in the Safeguard Desktop Player User Guide.
You can now uniformly set the TLS security settings of HTTP, RDP, Telnet, and VNC connections, including the permitted ciphers and TLS versions on the <Protocol> Control > Settings pages.
To ensure the security of your sessions, SSL encryption is not supported anymore, only TLS 1.0 and later.
You can now use an Authentication Policy with GSSAPI and a Usermapping Policy in SSH connections. When an SSH Connection Policy uses an Authentication Policy with GSSAPI, and a Usermapping Policy, then SPS stores the user principal as the Gateway username, and the username used on the target as the Server username.
Note that this change has the following side effect: when using an Authentication Policy with GSSAPI, earlier versions of SPS used the client-username@REALM username to authenticate on the target server. Starting with version 5.9.0, it uses the client-username as username. Configure your servers accordingly, or configure a Usermapping Policy for your SSH connections in SPS.
SPS can now distinguish the audited HTTP requests and responses based on the session cookies of web applications. For details, see "Creating and editing protocol-level HTTP settings" in the Administration Guide.
SPS now provides a way to authenticate non-transparent HTTP/HTTPS connections on SPS to local and external backends (LDAP, Microsoft Active Directory, RADIUS). The client must support proxy authentication.
For more information, see "Creating a new HTTP authentication policy" in the Administration Guide.
SPS can now be configured to check out passwords from the built-in or external credential stores, such as One Identity Safeguard for Privileged Passwords, and play them in during a connection using the TN3270 protocol.
You can now display a banner to your clients in RDP sessions. For example, this banner can inform the users that the connection is audited. For details, see "Creating and editing protocol-level RDP settings" in the Administration Guide.
Figure 7: Graphical banner in RDP
The Authentication and Authorization plugins now can request information interactively from the user in a graphical window, for example, a ticket ID, or a one-type password. To request a plugin that interoperates with your authentication or authorization system, contact our Support Team.
If the server requires Network Level Authentication and the Allow me to save credentials option is not selected in the RDP client, SPS now automatically displays a graphical prompt where the users can enter their usernames and passwords.
Figure 8: Server-side login in RDP
When using inband destination selection, your users now do not have to encode any data in the username: SPS can display an interactive prompt in the RDP connection to request the address of the destination server, username, and other required information. For details, see "Inband destination selection in RDP connections" in the Administration Guide.
As a smaller improvement, SPS now supports using certificate chains in the signing CA used for RDP connections.
Enabling TLS-encryption in an RDP connection policy has been simplified. When the connection is encrypted, SPS has to show a certificate to the peer. You can define the type of certificate to show to the peers.
In case of compatibility issues, you also have the option to allow fallback to legacy RDP Security Layer (also known as: Standard RDP Security). However, it is not advised due to security reasons.
For more information, see "Enabling TLS-encryption for RDP connections" in the Administration Guide.
SPS now supports Windows 2019 Server as a client and server in RDP sessions.
It is now possible to configure the CRL that you generated using your Certificate Authority (CA) in your Public Key Infrastructure (PKI) solution. This is the CRL information that will be shown to clients connecting to SPS. For more information, see "Signing certificates on-the-fly" in the Administration Guide.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center