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

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

Encrypting configuration backups with GPG

You can encrypt the configuration file of SPS during system backups using the public-part of a GPG key. The system backups of SPS contain other information as well (for example, databases), but only the configuration file is encrypted. Note that system backups do not contain audit-trail data.

When exporting the configuration of SPS, or creating configuration backups, always use encryption. Handle the exported data with care, as it contains sensitive information, including credentials. For details on encrypting the configuration, see "Encrypting configuration backups with GPG" in the Administration Guide.

For details on restoring configuration from a configuration backup, see Restoring One Identity Safeguard for Privileged Sessions (SPS) configuration and data to the same SPS appliance.

NOTE: It is not possible to directly import a GPG-encrypted configuration into SPS, it has to be decrypted locally first.

Prerequisites

You have to configure a backup policy before starting this procedure. For details, see Data and configuration backups.

You need a GPG key which must be permitted to encrypt data. Keys that can be used only for signing cannot be used to encrypt the configuration file.

To encrypt the configuration file of SPS during system backup

  1. Navigate to Basic Settings > Management > System backup.

  2. Select Encrypt configuration.

  3. Click .

    • To upload a key file, click Browse, select the file containing the public GPG key, and click Upload. SPS accepts both binary and ASCII-armored GPG keys.

    • To copy-paste the key from the clipboard, copy it, paste it into the Key field, then click Set.

  4. Click .

Archiving

Archiving transfers data from SPS to an external storage solution. Archived data can be accessed and searched, but cannot be restored (moved back) to the SPS appliance. Only those closed audit-trail files are archived where the retention time has already elapsed.

To configure archiving, you first have to create an archive policy. Archive policies define the retention time, the address of the remote backup server, which protocol to use to access it, and other parameters. SPS can be configured to use the SMB/CIFS and NFS protocols to access the archive server:

 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 different protocols assign different file ownerships to the files saved on the remote server. The owners of the archives created using the different protocols are the following:

  • SMB/CIFS: The user provided on the web interface.

  • NFS: root with no-root-squash, nobody otherwise.

 Caution:

SPS cannot modify the ownership of a file that already exists on the remote server.

Once you have configured an archive policy, assign it to the connection you want to archive. For details, see Archiving the collected data.

Data about archived connections can be automatically deleted from the connection database. For details, see Configuring cleanup policies.

Creating an archive policy using SMB/CIFS

The Move data to a remote server using SMB/CIFS archive method connects to a share on the target server with Server Message Block protocol. SMB/CIFS is mainly used on Microsoft Windows Networks.

NOTE: Backup and archive policies only work with existing shares and subdirectories.

If a server has a share at, for example, archive and that directory is empty, when the user configures archive/scb1 (or similar) as a backup/archive share, it will fail.

When deployed from the Azure Marketplace, you can use Azure File storage shares for Backup and Archive Policies. This is very useful as you can change the quota for the file storage dynamically, so the cumulative size of the audit trails is not limited to the OS disk size. You can set up this share as normal SMB shares in your Backup and Archive policies. You can obtain the parameters for the policy from the Azure portal.

 Caution:

When you try to create backups and archives from SPS to NetApp devices using the CIFS protocol, the operation may fail with a similar error message: /opt/scb/mnt/14719217504d41370514043/reports/2010": Permission denied (13) '2010/day/' rsync: failed to set times on.

To overcome this problem, grant the SPS user "Full Control" access rights to the CIFS share on the NetApp device.

 Caution:

When using the CIFS protocol to backup or archive files to a target server running Windows 2008 R2 that uses NTLMv2 authentication, the operation may fail with a similar error message:

CIFS VFS: Unexpected SMB signature
Status code returned 0xc000000d NT_STATUS_INVALID_PARAMETER
CIFS VFS: Send error in SessSetup = -22
CIFS VFS: cifs_mount failed w/return code = -22
CIFS VFS: Server requires packet signing to be enabled in /proc/fs/cifs/SecurityFlags.
CIFS VFS: cifs_mount failed w/return code = -95
CIFS VFS: Server requires packet signing to be enabled in /proc/fs/cifs/SecurityFlags.
CIFS VFS: cifs_mount failed w/return code = -95

To overcome this problem, do one of the following:

  • Use the NFS protocol to access your Windows 2008 R2 servers.

  • Edit the registry of the Windows 2008 R2 server or apply a hotfix. For details, see Article 957441 in the Microsoft Support site.

  1. Navigate to Policies > Backup & Archive and click in the Archive policies section to create a new archive policy.

  2. Enter a name for the archive policy.

  3. Enter the time when the archive process should start into the Start time field in HH:MM format (for example 23:00).

    You can add the start time for additional archive processes.

    		 Caution:

    When specifying an additional start time, ensure that the previous archive process finishes before the new archive process starts.

  4. To archive the data collected on more than once a day, click . You can schedule multiple archive times.

    NOTE: In case an archive process is not finished before the next one would start, the next archive process waits for the previous process to be completed.

  1. Fill the Delete data from SPS after field. Data older than this value is archived to the external server.

    NOTE: The archived data is deleted from SPS.

  1. Select Move data to a remote server using SMB/CIFS from the Before deleting data from PSM radio buttons.

    Figure 71: Policies > Backup & Archive — Configuring archiving

  2. Enter the username used to log on to the remote server into the Username field, or select the Anonymous login option.

    Usernames can contain space.

  3. Enter the password corresponding to the username into the Password field.

    NOTE: SPS accepts passwords that are not longer than 150 characters and supports the following characters:

    • Letters A-Z, a-z

    • Numbers 0-9

    • The space character

    • Special characters: !"#$%&'()*+,-./:;<>=?@[]\^-`{}_|

  4. Enter the name and directory path of the share into the Share field. Use the following format:

    share_name/path/to/directory

    You can use backslashes and forward slashes as well.

    SPS saves all data into this directory, automatically creating the subdirectories. Archives of audit-trails are stored in the data, configuration backups in the config subdirectory.

  5. Enter the domain name of the target server into the Domain field.

  1. Select which SMB protocol to use when SPS connects to the server in the Protocol version field. Servers are usually backwards compatible with earlier protocol versions (for example, a server that supports version 2.1 supports versions 2.0 and 1.0 as well).

  1. SPS organizes the audit trails into directories based on the date or the protocol. The subdirectories are created directly into the archive directory. Select one of the following directory structures:

    • Protocol/Connection/Archive Date/

    • Archive Date/Connection/Protocol/

    • Connection Date/Protocol/Connection/

    • Archive Date/

    • Connection Date/

    For example, the Protocol/Connection/Archive Date template will have create subdirectories for the audited protocols (that is, ssh, rdp, telnet, vnc), for the name of the connection policy, and finally, for the date (YEAR-MONTH-DAY in YYYY-MM-DD format).

    NOTE: Connection Date refers to the time the connection started, while Archive Date to the time it was archived. The difference between the two dates depends on the retention time set for the archiving policy.

  2. When your SPS instance is a node in a cluster, select Include the Cluster Node ID in the path. This ensures that the node ID is included in the path of the relevant directory, which is required to prevent cluster nodes from archiving data to the same location. Archiving data to the same location would result in data loss. In addition, including the node ID in the directory name also enables easy identification.

    		 Caution:

    Hazard of data loss

    If you configured configuration synchronization across your cluster nodes, unchecking Include the Cluster Node ID in the path when your SPS is a node in a cluster can result in data loss.

  3. To receive e-mail notifications, select the Send notification on errors only or the Send notification on all events option. Notifications are sent to the administrator e-mail address set on the Management tab, and include the list of the files that were backed up.

    NOTE: This e-mail notification is different from the one set on the Alerting & Monitoring tab. This notification is sent to the administrator's e-mail address, while the alerts are sent to the alert e-mail address (see Configuring system monitoring on SPS).

  4. Click Commit.

  5. To assign the archive policy to the connection you want to archive, see Archiving the collected data.

Creating an archive policy using NFS

The Move data to a remote server using NFS archive method connects to a shared directory of the target server with the Network File Share protocol.

NOTE: Backup and archive policies only work with existing shares and subdirectories.

If a server has a share at, for example, archive and that directory is empty, when the user configures archive/scb1 (or similar) as a backup/archive share, it will fail.

The version of NFS used is automatically detected. All versions of NFS, up to and including NFS version 4 protocol, are supported.

  1. Navigate to Policies > Backup & Archive and click in the Archive policies section to create a new archive policy.

  2. Enter a name for the archive policy.

  3. Enter the time when the archive process should start into the Start time field in HH:MM format (for example 23:00).

    You can add the start time for additional archive processes.

    		 Caution:

    When specifying an additional start time, ensure that the previous archive process finishes before the new archive process starts.

  4. To archive the data collected on more than once a day, click . You can schedule multiple archive times.

    NOTE: In case an archive process is not finished before the next one would start, the next archive process waits for the previous process to be completed.

  1. Fill the Delete data from SPS after field. Data older than this value is archived to the external server.

    NOTE: The archived data is deleted from SPS.

  1. Select Move data to a remote server using NFS from the Before deleting data from PSM radio buttons.

    Figure 72: Policies > Backup & Archive —Configuring archiving

  2. Enter the domain name of the remote server into the Target server field.

  3. Enter the name of the NFS export into the Export field.

    SPS saves all data into this directory, automatically creating the subdirectories.

  4. The remote server must also be configured to accept connections from SPS.

    Add a line that corresponds to the settings of SPS to the /etc/exports file of the remote server. This line should contain the following parameters:

    • The path to the archive directory as set in the Export field of the SPS archive policy.

    • The IP address of the SPS interface that is used to access the remote server. For more information on the network interfaces of SPS, see Network settings.

      Use an IPv4 address.

    • The following parameters: (rw,no_root_squash,sync).

    Example: Configuring NFS on the remote server

    For example, if SPS connects the remote server from the 192.168.1.15 IP address and the data is saved into the /var/backups/SPS directory, add the following line to the /etc/exports file:

    /var/backups/SPS 192.168.1.15(rw,no_root_squash,sync)

  5. On the remote server, execute the following command:

    exportfs -a

    Verify that the rpc portmapper and rpc.statd applications are running.

  1. SPS organizes the audit trails into directories based on the date or the protocol. The subdirectories are created directly into the archive directory. Select one of the following directory structures:

    • Protocol/Connection/Archive Date/

    • Archive Date/Connection/Protocol/

    • Connection Date/Protocol/Connection/

    • Archive Date/

    • Connection Date/

    For example, the Protocol/Connection/Archive Date template will have create subdirectories for the audited protocols (that is, ssh, rdp, telnet, vnc), for the name of the connection policy, and finally, for the date (YEAR-MONTH-DAY in YYYY-MM-DD format).

    NOTE: Connection Date refers to the time the connection started, while Archive Date to the time it was archived. The difference between the two dates depends on the retention time set for the archiving policy.

  2. When your SPS instance is a node in a cluster, select Include the Cluster Node ID in the path. This ensures that the node ID is included in the path of the relevant directory, which is required to prevent cluster nodes from archiving data to the same location. Archiving data to the same location would result in data loss. In addition, including the node ID in the directory name also enables easy identification.

    		 Caution:

    Hazard of data loss

    If you configured configuration synchronization across your cluster nodes, unchecking Include the Cluster Node ID in the path when your SPS is a node in a cluster can result in data loss.

  3. To receive e-mail notifications, select the Send notification on errors only or the Send notification on all events option. Notifications are sent to the administrator e-mail address set on the Management tab, and include the list of the files that were backed up.

    NOTE: This e-mail notification is different from the one set on the Alerting & Monitoring tab. This notification is sent to the administrator's e-mail address, while the alerts are sent to the alert e-mail address (see Configuring system monitoring on SPS).

  4. Click Commit.

  5. To assign the archive policy to the connection you want to archive, see Archiving the collected data.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택