지금 지원 담당자와 채팅
지원 담당자와 채팅

One Identity Safeguard for Privileged Sessions 7.5 - 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

Connection backup

The connection backup, also known as data backup contains the audit files and connection metadata of a connection. It can be configured as a scheduled policy and is saved to a backup server.

For more information on how to perform a connection backup of a connection, see: Creating data backups. It is a three-step process:

  1. Configure a system backup. Restoring a data backup works only if a matching system configuration and metadata is available, that is, if a system backup is restored first.

  2. Create a backup policy at Policies > Backup & Archive > Backup policies.

  3. Navigate to Traffic Controls > Protocol name > Connections. Select the connection you want to back up. Select the previously created backup policy in the Backup policy field.

For more information on how to restore the configuration and data of One Identity Safeguard for Privileged Sessions (SPS) from a complete backup, for example, after a hardware replacement, see: Restoring SPS configuration and data.

The connection backup is used for

  • Saving the created audit trail files and indexing metadata of a connection to a remote share. This is a copy operation in terms of data files.

  • Recovery: In case of a hardware replacement, creating configuration export, system backup and connection backups is essential.

  • Migration: Creating a machine identical to another SPS machine.

The connection backup contains the following

  • The audit trails of the connection, that is, the .zat files storing the recorded activities of the administrators. For more information on audit trails, see Audit Policies.

  • The index of the audit trail that makes the content of the audit trail searchable. For more information on indexing audit trails, see Indexing audit trails.

NOTE: Audit trails and index files are large. This means that backing up a connection requires a significant amount of free hardware space. Make sure you have enough free hardware space for those connections that you want to back up.

Connection archive

The connection archive, also known as data archive contains the audit files and connection metadata of a connection. In terms of contents, it is similar to a connection backup. It can be configured as a scheduled policy and is saved to an archive server. Archiving transfers data from One Identity Safeguard for Privileged Sessions (SPS) to an external storage solution, cleanup removes (deletes) old files. Archived data can be accessed and searched, but cannot be restored (moved back) to the SPS appliance.

For more information on how to perform a connection archive of a connection, see: Archiving or cleaning up the collected data. It is a two-step process:

  1. Create an archive policy at Policies > Backup & Archive > Archive policies.

  2. Navigate to <Protocol name> Control > Connections. Select the connection you want to archive. Select the previously created archive policy in the Archive policy field.

 Caution:

Hazard of data loss Never delete an Archive Policy if data has been archived with it. This will make the already archived data inaccessible.

Do not "remake" an Archive Policy (that is, deleting an Archive Policy and then creating another one with the same name but different parameters). This will make data inaccessible, and identifying the root cause of the issue complicated.

If you want to change the connection parameters (that is when you perform a storage server migration), you must make sure that the share contents and file permissions are kept unmodified and there are no archiving or backup tasks running.

On the other hand, if you want to add a new network share to your archives, proceed with the following steps:

  1. Create a new empty SMB/NFS network share.

  2. Create a new Archive Policy that points to this network share.

  3. Modify your Connection Policy(es) to archive using the newly defined Archive Policy.

  4. Make sure to leave the existing Archive Policy unmodified.

It is also safe to extend the size of the network share on the server side.

The connection archive is used for

  • Moving the created audit trail files and indexing metadata of a connection to a remote share. This is a move operation in terms of data files. Archived data can be accessed and searched, but cannot be restored (moved back) to the SPS appliance.

  • Freeing up hardware space on SPS.

The connection archive contains the following

  • The audit trails of the connection, that is, the .zat files storing the recorded activities of the administrators. For more information on audit trails, see Audit Policies.

  • The index of the audit trail that makes the content of the audit trail searchable. For more information on indexing audit trails, see Indexing audit trails.

Support bundle

To track down support requests, the One Identity Support Team might request you to collect system-state and debugging information. This information is collected automatically, and contains log files, the anonymized excerpt of the configuration export file of One Identity Safeguard for Privileged Sessions (SPS), and various system-statistics. To generate a support bundle, navigate to Basic Settings > Troubleshooting > Create support bundle.

The exported file is a zip-compressed archive.

The name of the exported file is debug_info-<hostname>YYYYMMDDHHMM. Sensitive data like key files and passwords are automatically removed from the configuration files.

For details on how to create a support bundle, see: Collecting logs and system information for error reporting.

The support bundle is used for

  • Collecting a snapshot of the past week's system-state information for the One Identity Support Team for troubleshooting and debugging purposes.

  • Collecting information about a specific error by generating data for a defined time interval where the event that causes the error is reproduced. This is also used by the One Identity Support Team for troubleshooting and debugging purposes.

The support bundle contains the following

  • Debug logs, Connection logs and OS logs of the past week, one file per day. If there are too many events in a day, the log file in the support bundle only contains a truncated version of the connection logs. In this case, the complete log file is only accessible at /var/log/messages-<day>.

  • An excerpt of the configuration export file:

    • The anonymized version of the configuration XML file

    • Plugins, which include the complete plugin .zip file and the plugin source code.

  • System-state information, for example, version details, statistics, memory usage, system warnings, and so on.

  • List of core files. This list might indicate previous system crashes.

  • RAID controller information

  • Upgrade logs

  • Dashboard data

Debug logs

To increase the log level of the non-connection-related events, for example, to add the commands executed by the One Identity Safeguard for Privileged Sessions (SPS) web interface to the logs, enable debug level logging at Basic Settings > Management > Verbose system logs > Enable.

These logs are accessible at /var/log/scb-<day>.

The debug logs are used for

  • Our Support Team uses this to investigate the reasons behind a web user interface-related issue.

The debug logs contain the following

  • Logs generated by the SPS web interface.

  • System daemon logs.

  • Logs of periodic cron jobs.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택