Chat now with support
Chat mit Support

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

Managing a cluster with configuration synchronization without central search

You can configure your One Identity Safeguard for Privileged Sessions (SPS) cluster in the following ways:

  • Configuration synchronization without a central search: This method allows you to perform your configuration settings on your Central management node. Managed host nodes periodically fetch and merge the settings into their own: this is called "configuration synchronization". Central search is not configured in this method, so you can search for sessions on each node, including the Central management node.

    For more information on this method, see Configuration synchronization without a central search.

  • Central search with configuration synchronization: This method allows you to use a Central management node with a Search master role to view session data recorded by the minion nodes of your cluster, as well as manage all the nodes in the cluster from one central location.

    For more information on this method, see Central search with configuration synchronization.

    IMPORTANT: One Identity does not recommend having a central search configuration without configuration synchronization.

The following figure shows a cluster with configuration synchronization without central search.

Figure 132: Configuration synchronization without central search

The figure above is an example of an SPS cluster configured as follows:

  • There is a Central management node.
  • There are two Managed host nodes (Managed host node 1 and 2).
  • The Central Management node is connected to the two Managed host nodes.
  • The Managed host nodes fetch their configuration from the Central management node, and merge it into their own configuration.
  • The Managed host nodes send their status information to the Central management node every 10 seconds.

The Central management node and the connected Managed host nodes require different configuration settings as described in the table below:

Table 8: Managing a configuration synchronization without a central search
Role Use and configuration settings

Central management node

  • Use it as a node with a central configuration, which is synchronized to the other nodes of the cluster.

  • Perform your configuration settings on this node. Managed host nodes periodically fetch and merge these configuration settings into their own (configuration synchronization).

  • For backup and archive, configure a backup and archive server on your minion node, as well as on your Central management node.

  • Ensure that you configure high availability (HA) for each node (for both your Central management node and the Managed host nodes). Also ensure that the Central management node has a system backup configured.

  • You can search for all the sessions recorded on this node.

Managed host node

  • Use it to record sessions and send status information to the Central management node.

  • Do not perform configuration settings on the minion. These are overwritten during configuration synchronization.

    NOTE: All configuration settings that you make on the minions are overwritten during configuration synchronization except the node specific configuration.

  • Set external and internal indexers.

  • For backup and archive, configure a backup and archive server on your minion node, as well as on your Central management node.

  • Ensure that you configure high availability (HA) for each node (for both your Central management node and the Managed host nodes). Also ensure that the Central management node has a system backup configured.

  • You can search for all the sessions recorded on this node.

For more information on each role, see Cluster roles.

Managing a cluster with central search configuration and configuration synchronization

You can configure your One Identity Safeguard for Privileged Sessions (SPS) cluster in the following ways:

  • Configuration synchronization without a central search: This method allows you to perform your configuration settings on your Central management node. Managed host nodes periodically fetch and merge the settings into their own: this is called "configuration synchronization". Central search is not configured in this method, so you can search for sessions on each node, including the Central management node.

    For more information on this method, see Configuration synchronization without a central search.

  • Central search with configuration synchronization: This method allows you to use a Central management node with a Search master role to view session data recorded by the minion nodes of your cluster, as well as manage all the nodes in the cluster from one central location.

    For more information on this method, see Central search with configuration synchronization.

    IMPORTANT: One Identity does not recommend having a central search configuration without configuration synchronization.

The following figure shows a cluster configured for central search with configuration synchronization.

Figure 133: Central search with configuration synchronization

The figure above is an example of an SPS cluster configured as follows:

  • There is a Central management node, which has a Search master role.
  • There are two Managed host nodes (Managed host node 1 and 2), each configured with a Search minion role.
  • The Central management node is connected to the two minion nodes.
  • The minion nodes record sessions, which are displayed on the Search interface of the Central management node.
  • The minion nodes fetch their configuration from the Central management node, and merge it into their own configuration.

The Central management node with a Search master role and the connected Managed host nodes with Search minion roles require different configuration settings as described in the table below:

Table 9: Managing a central search configuration
Role Use and configuration settings

Central management node, Search master
  • Use it for viewing session data recorded by minions as well as managing all the nodes in the cluster.

  • Perform your configuration settings on this node. Managed host nodes periodically fetch and merge these configuration settings into their own (configuration synchronization).

  • For backup and archive, configure a backup server on your Central management node and an archive server on your minion node.

  • Ensure that you configure high availability (HA) for each node (for both your Central management node and the Managed host nodes). Also ensure that the Central management node has a system backup configured.

  • This node cannot be used to record sessions.

Managed host node, Search minion
  • Use it to record sessions and store audit trail files.

  • Do not perform configuration settings on the minion. These are overwritten during configuration synchronization.

    NOTE: All configuration settings that you make on the minions are overwritten during configuration synchronization except the node specific configuration.

  • Set external and internal indexers.

  • For backup and archive, configure an archive server on your minion node, and a backup server on your Central management node.

  • Ensure that you configure high availability (HA) for each node (for both your Central management node and the Managed host nodes). Also ensure that the Central management node has a system backup configured.

For more information on each role, see Cluster roles.

Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster

The goal of HA clusters is to support enterprise business continuity by providing failover.

In High Availability (HA) mode, two One Identity Safeguard for Privileged Sessions (SPS) units with identical configurations are operating simultaneously. These two units are the primary node and the secondary node (previously also referred to as the master node and the slave node). The primary node shares all data with the secondary node, and if the primary node stops functioning, the other one becomes immediately active, so the servers are continuously accessible.

NOTE: To ensure the stability of the connection, One Identity recommends a direct physical connection between the nodes in the HA cluster. Gratuitous ARP requests are sent to inform hosts on the local network that the MAC addresses behind these IP addresses have changed.

The primary node shares all data with the secondary node using the HA network interface (labeled as 4 or HA on the SPS appliance). The disks of the primary and the secondary node must be synchronized for the HA support to operate correctly. Interrupting the connection between running nodes (unplugging the Ethernet cables, rebooting a switch or a router between the nodes, or disabling the HA interface) disables data synchronization and forces the secondary node to become active. This might result in data loss. You can find instructions to resolve such problems and recover a SPS cluster in Troubleshooting a One Identity Safeguard for Privileged Sessions (SPS) cluster.

NOTE: HA functionality was designed for physical SPS units. If SPS is used in a virtual environment, use the fallback functionalities provided by the virtualization service instead.

The Basic Settings > High Availability page provides information about the status of the HA cluster and its nodes.

Figure 134: Basic Settings > High Availability — Managing a High Availability cluster

The following information is available about the cluster:

The active (that is, primary) SPS node is labeled as This node. This unit inspects the SSH traffic and provides the web interface. The SPS unit labeled as Other node is the secondary node that is activated if the primary node becomes unavailable.

The following information is available about each node:

  • Node ID: The MAC address of the HA interface of the node. This address is also printed on a label on the top cover of the SPS unit.

    For SPS clusters, the IDs of both nodes are included in the internal log messages of SPS. Note that if the central log server is a syslog-ng server, the keep-hostname option should be enabled on the syslog-ng server.

  • Node HA state: Indicates whether the SPS nodes recognize each other properly and whether those are configured to operate in High Availability mode. For details, see Understanding One Identity Safeguard for Privileged Sessions (SPS) cluster statuses.

  • Node HA UUID: A unique identifier of the cluster. Only available in High Availability mode.

  • DRBD status: The status of data synchronization between the nodes. For details, see Understanding One Identity Safeguard for Privileged Sessions (SPS) cluster statuses.

  • RAID status: The status of the RAID device of the node. If it is not Optimal, there is a problem with the RAID device. For details, see Understanding One Identity Safeguard for Privileged Sessions (SPS) RAID status.

  • Firmware version: Version number of the firmware.

  • HA link speed: The maximum allowed speed between the primary node and the secondary node. The HA link's speed must exceed the DRBD sync rate limit, else the web UI might become unresponsive and data loss can occur.

  • Interfaces for Heartbeat: Virtual interface used only to detect that the other node is still available. This interface is not used to synchronize data between the nodes (only heartbeat messages are transferred).

    You can find more information about configuring redundant heartbeat interfaces in Redundant heartbeat interfaces.

  • Next hop monitoring: IP addresses (usually next hop routers) to continuously monitor both the primary node and the secondary node by using ICMP echo (ping) messages. If any of the monitored addresses becomes unreachable from the primary node while being reachable from the secondary node (in other words, more monitored addresses are accessible from the secondary node), then it is assumed that the primary node is unreachable and a forced takeover occurs – even if the primary node is otherwise functional. For details, see Next-hop router monitoring.

HA cluster configuration and management options

This section is about the available configuration and management options for HA clusters.

Topics:
Setting up a High Availability cluster

For detailed instructions about setting up a HA cluster, see .

Adjust the DRBD (primary-secondary) synchronization speed

You can change the limit of the DRBD synchronization rate. Note that this does not change the speed of normal data replication. For details, see Adjusting the synchronization speed.

Configure redundant heartbeat interfaces

You can configure virtual interfaces for each HA node to monitor the availability of the other node. For details, see Redundant heartbeat interfaces.

Configure next-hop monitoring

You can provide IP addresses (usually next hop routers) to continuously monitor both the primary node and the secondary node by using ICMP echo (ping) messages. If any of the monitored addresses becomes unreachable from the primary node while being reachable from the secondary node (in other words, more monitored addresses are accessible from the secondary node), then it is assumed that the primary node is unreachable and a forced takeover occurs – even if the primary node is otherwise functional. For details, see Next-hop router monitoring.

Reboot the HA cluster

To reboot both nodes, click Reboot Cluster. To prevent takeover, a token is placed on the secondary node. While this token persists, the secondary node halts its boot process to make sure that the primary node boots first. Following reboot, the primary node removes this token from the secondary node, allowing it to continue with the boot process.

If the token still persists on the secondary node following reboot, the Unblock Slave Node button is displayed. Clicking the button removes the token, and reboots the secondary node.

Reboot a node

This option reboots the selected node.

When rebooting the nodes of a cluster, reboot the other node (that is, the secondary node) first to avoid unnecessary takeovers.

Shutdown a node

This option forces the selected node to shut down.

When shutting down the nodes of a cluster, shut down the other node (that is, the secondary node) first. When powering on the nodes, start the primary node first to avoid unnecessary takeovers.

Manual takeover

To activate the other node (that is, the secondary node) and disable the currently active node, click Activate slave.

Activating the secondary node terminates all connections of One Identity Safeguard for Privileged Sessions (SPS) and might result in data loss. The secondary node becomes active after about 60 seconds, during which the protected servers cannot be accessed.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen