Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 7.1.1 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS)
The philosophy of One Identity Safeguard for Privileged Sessions (SPS) Policies Credential Stores Plugin framework Indexing Supported protocols and client applications Modes of operation Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) Archive and backup concepts Maximizing the scope of auditing IPv6 in One Identity Safeguard for Privileged Sessions (SPS) SSH host keys Authenticating clients using public-key authentication in SSH The gateway authentication process Four-eyes authorization Network interfaces High Availability support in One Identity Safeguard for Privileged Sessions (SPS) Versions and releases of One Identity Safeguard for Privileged Sessions (SPS) Accessing and configuring One Identity Safeguard for Privileged Sessions (SPS)
Cloud deployment considerations The Welcome Wizard and the first login Basic settings
Supported web browsers The structure of the web interface Network settings Configuring date and time System logging, SNMP and e-mail alerts Configuring system monitoring on SPS Data and configuration backups Archiving Cleaning up audit data Using plugins Forwarding data to third-party systems Starling integration
User management and access control
Login settings Managing One Identity Safeguard for Privileged Sessions (SPS) users locally Setting password policies for local users Managing local user groups Managing One Identity Safeguard for Privileged Sessions (SPS) users from an LDAP database Authenticating users to a RADIUS server Authenticating users with X.509 certificates Authenticating users with SAML2 Managing user rights and usergroups Creating rules for restricting access to search audit data Displaying the privileges of users and user groups Listing and searching configuration changes
Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing One Identity Safeguard for Privileged Sessions (SPS) clusters Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster Upgrading One Identity Safeguard for Privileged Sessions (SPS) Managing the One Identity Safeguard for Privileged Sessions (SPS) license Accessing the One Identity Safeguard for Privileged Sessions (SPS) console Sealed mode Out-of-band management of One Identity Safeguard for Privileged Sessions (SPS) Managing the certificates used on One Identity Safeguard for Privileged Sessions (SPS)
General connection settings HTTP-specific settings ICA-specific settings MSSQL-specific settings RDP-specific settings SSH-specific settings Using Sudo with SPS Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) REST API One Identity Safeguard for Privileged Sessions (SPS) scenarios Troubleshooting One Identity Safeguard for Privileged Sessions (SPS)
Network troubleshooting Gathering data about system problems Viewing logs on One Identity Safeguard for Privileged Sessions (SPS) Changing log verbosity level of One Identity Safeguard for Privileged Sessions (SPS) Collecting logs and system information for error reporting Collecting logs and system information of the boot process for error reporting Support hotfixes Status history and statistics Troubleshooting a One Identity Safeguard for Privileged Sessions (SPS) cluster Understanding One Identity Safeguard for Privileged Sessions (SPS) RAID status Restoring One Identity Safeguard for Privileged Sessions (SPS) configuration and data VNC is not working with TLS Configuring the IPMI from the BIOS after losing IPMI password Incomplete TSA response received Using UPN usernames in audited SSH connections
Using SPS with SPP Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help Configuring SPS to use an LDAP backend Glossary

Uploading plugins

To upload a plugin to SPS

  1. Navigate to Basic Settings > Plugins and click Upload plugin.

  2. Browse for the plugin .zip file and click Open.

    NOTE: It is not possible to upload or delete plugins if SPS is in sealed mode.

Verifying the integrity of a plugin

To verify the integrity of the plugin archive (that is, that the .zip file has officially been issued by One Identity and has not been tampered with before its extraction and uploading the plugin), complete the following steps. These also verify whether the plugin has been modified after upload or not.

This procedure only applies to plugins downloaded from the official repositories.

Prerequisites

  • Make sure that you have already uploaded a plugin.

    For more information on uploading plugins, see Uploading plugins.

To verify the integrity of a plugin

  1. Navigate to Basic Settings > Plugins.

  2. Select the plugin that you want to verify.

  3. Under Plugin details > Plugin integrity, click Check integrity.

    Figure 75: Basic Settings > Plugins > Plugin details — Verifying plugin integrity

    There are three integrity checks:

    • Plugin offline integrity > Zip checksum check

      This check verifies whether the recalculated checksum is the same as the checksum that has been stored in the configuration after uploading plugin.

    • Plugin offline integrity > Zip content check

      This check verifies whether the plugin runtime files are the same since you have uploaded the plugin .zip.

    • Online integrity check

      This check verifies whether the plugin .zip checksums match with the .zip checksums stored online.

      NOTE: The online integrity check works only if you have joined to Starling.

      For more information, see Starling integration

To verify the integrity of a plugin manually

  1. Under Plugin details > Plugin integrity > SHA256 checksum, click Copy.

  2. To verify the integrity of the plugin, compare this checksum with the checksum on the official download sites. You might find your plugin version under a previous product version.

    On the support portal:

    1. Navigate to the product page on the Support Portal that you have downloaded the plugin from. Click on the name of the plugin.

    2. Next to the sha256 section, you will see the checksum of the official One Identity plugin.

    On GitHub:

    1. Navigate to the GitHub plugin repository that you have downloaded the plugin from. Click on the name of the plugin.

    2. Navigate to the releases tab.

    3. Scroll to the specific release that you use.

    4. Under the SHA256 checksum section, you will see the checksum of the official One Identity plugin.

  3. Compare the checksum of the official One Identity plugin with the one you have copied from Plugin details > Plugin integrity > SHA256 checksum.

Forwarding data to third-party systems

SPS can forward session data to Splunk, ArcSight, or other third-party systems that enable you to search, analyze, and visualize the forwarded data.

NOTE: Since SPS version 5.11, the universal SIEM forwarder supports Splunk easier than in previous versions. If you want to integrate your SPS with Splunk, One Identity recommends using the universal SIEM forwarder instead of the Splunk forwarder (which has been deprecated as of SPS version 6.4).

Using the universal SIEM forwarder

The universal SIEM forwarder can automatically send data about the audited sessions to Splunk, ArcSight, or other third-party systems. The messages are standard syslog messages in RFC3164 format (also called legacy-syslog or BSD-syslog format). The body of the syslog message (the MESSAGE part) can be formatted as JavaScript Object Notation (JSON), Common Event Format (CEF), or JSON-CIM format. For information about the details of the messages that the universal SIEM forwarder sends to the external SIEM network elements, see "Message format forwarded to SIEMs" in the Administration Guide.

One of the main advantages of the universal SIEM forwarder is that it has a lower impact on network and performance.

Each message contains the minimal information relevant to the event. Use the built-in correlation feature of the SIEM to combine events by session ID and view all information in one place.

Use the universal SIEM forwarder if you need a less resource-heavy solution. For more information, see Using the universal SIEM forwarder.

Universal SIEM Forwarder

The universal SIEM forwarder can automatically send data about the audited sessions to Splunk, ArcSight, or other third-party systems. The messages are standard syslog messages in RFC3164 format (also called legacy-syslog or BSD-syslog format). The body of the syslog message (the MESSAGE part) can be formatted as JavaScript Object Notation (JSON), Common Event Format (CEF), or JSON-CIM format. For information about the details of the messages that the universal SIEM forwarder sends to the external SIEM network elements, see "Message format forwarded to SIEMs" in the Administration Guide.

One of the main advantages of the universal SIEM forwarder is that it has a lower impact on network and performance.

Each message contains the minimal information relevant to the event. Use the built-in correlation feature of the SIEM to combine events by session ID and view all information in one place.

Prerequisites and restrictions

  • SPS version 5 F9 or later

  • Splunk version 6.5 or later

  • The CEF format is supported on all currently supported versions of ArcSight ESM, IBM QRadar and Microsoft Azure Sentinel.

  • SPS does not send historical data, only data from the sessions started after you complete this procedure.

To use the universal SIEM forwarder

  1. Log in to SPS and navigate to Basic Settings > Management > Universal SIEM forwarder.

    Figure 76: Basic Settings > Management > Universal SIEM forwarder — Sending session data to SIEM

  2. Enter the IPv4 address or hostname of your third-party system, into the Address field.

  3. Enter the port number where your third-party system is accepting connections into the Port field. For example, if you use Splunk, use port 1999.

  4. Select the appropriate TLS setting:

    • If your third-party system accepts unencrypted connections, select TLS > Disabled.

      Because the data forwarded contains sensitive information, One Identity recommends to use TLS encryption between SPS and your SIEM.

    • To use TLS encryption between SPS and your third-party system, select TLS > Without certificate validation.

    • To use TLS encryption between SPS and your third-party system and also verify the identity of your third-party system server, select TLS > With certificate validation, then select the trust store you want to use to validate the certificate of the third-party system in the Trust Store field.

      NOTE: You can only select a trust store with None or Full revocation check type.

      For more information on creating trust stores, see Verifying certificates with Certificate Authorities using trust stores.

  5. Select the format of the message:

    • JSON-CIM: if using Splunk.

    • CEF: if using CEF-compatible SIEMs, for example, Microsoft Azure Sentinel.

    • JSON: for general use.

  6. (Optional) You can specify a prefix to make the data more readable. Enter the prefix you want to use into the Prefix field.

    The prefix is added to each JSON key. For example, if you use sps_ as a prefix, in the forwarded JSON message the {"protocol": "ssh"} key changes to {"sps_protocol": "ssh"}, which allows you to identify the forwarded data more easily.

    Other formats ignore the Prefix option.

  7. Click . From now on, SPS forwards session data to your third-party system.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating