Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 5.9.0 - Administration Guide

Preface Introduction The concepts of SPS The Welcome Wizard and the first login Basic settings User management and access control Managing SPS
Controlling SPS: reboot, shutdown Managing Safeguard for Privileged Sessions clusters Managing a high availability SPS cluster Upgrading SPS Managing the SPS license Accessing the SPS console Sealed mode Out-of-band management of SPS Managing the certificates used on SPS
General connection settings HTTP-specific settings ICA-specific settings RDP-specific settings SSH-specific settings Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search (classic) interface Using the Search interface Searching session data on a central node in a cluster Advanced authentication and authorization techniques Reports The SPS RPC API The SPS REST API SPS scenarios Troubleshooting SPS Configuring external devices Using SCP with agent-forwarding Security checklist for configuring SPS Jumplists for in-product help Third-party contributions About us

Cluster roles

You can assign any of the following roles to your nodes:

  • Central Management: There can be only one node with this role in the cluster.

    The purpose of having a Central Management node is to have a node with a central configuration, which can be synchronized to the other nodes of the cluster. Any changes that you make in the cluster's configuration on this node (for example, role changes, host address changes, and so on) are fetched by all the other nodes and merged into their configuration.

    The Central Management node also has status information about all the other nodes in the cluster, so you can check the health of the cluster on this node. Status information contains:

    • the result and time of the last attempt at configuration fetch and configuration update

    • errors and warnings that may have occurred during configuration fetch and configuration update

  • Managed Host: There can be several nodes with this role.

    Nodes with the Managed Host role synchronize their entire configuration from the Central Management node, not only those elements of the configuration that are related to the cluster.

    Managed Host nodes send their status information to the Central Management node every 10 seconds.

  • Search Master: There can be only one node with this role.

    The Search Master node is the one node in the cluster on which you can search all the session data recorded by other nodes in the cluster, provided that the other nodes have been assigned the Search Minion role.

    NOTE: An SPS node with the Search Master role cannot be used for monitoring network traffic, or for session recording and auditing purposes.

    This role can only be assigned to nodes that either have the Managed Host or Central Management role. This is required so that the configuration of Search Minion nodes and the Search Master node are always in sync.

    If there is no configuration synchronization between the node acting as the Search Master and the Search Minion nodes, then session data may show up on the Search interface of the Search Master that come from connections that do not match the connection policies set up on the Search Master (because they come from session data recorded by the Search Minions).

  • Search Minion: There can be several nodes with this role.

    Nodes with the Search Minion role send session data that they recorded to the Search Master for central search purposes. The session data recorded by a Search Minion node is not searchable on the node itself, only on the Search Master.

    This role can only be assigned to nodes that either have the Managed Host or Central Management role. This is required so that the configuration of Search Minion nodes and the Search Master node are always in sync.

    If there is no configuration synchronization between the node acting as the Search Master and the Search Minion nodes, then session data may show up on the Search interface of the Search Master that come from connections that do not match the connection policies set up on the Search Master (because they come from session data recorded by the Search Minions).

  • Search Local: There can be several nodes with this role.

    Nodes with the Search Local role keep the session data that they recorded for local searching. The session data recorded by a Search Local node is searchable on the node itself, but not on the Search Master (if there is one).

  • No role: Nodes without any role fetch only the cluster-related elements of the configuration from the Central Management node.

    Nodes with no roles send their status information to the Central Management node every 10 seconds.

Nodes keep their role in the cluster after a system restore.

For more information about configuration synchronization, see Configuration synchronization across nodes in a cluster.

For more information about central search, see Searching session data on a central node in a cluster.

Enabling cluster management

Purpose:

To enable cluster management, enable the cluster interface on all nodes that you want to be part of your Safeguard for Privileged Sessions cluster. Complete the following steps on each and every node of the cluster.

NOTE:

All nodes in a cluster must run the same version of SPS.

Prerequisites:

Nodes in the cluster connect to each other using IPsec, which requires UDP ports 500 and 4500 to be open in the firewalls between the nodes.

Steps:
  1. Navigate to Basic Settings > Local Services > Cluster Interface.

  2. Select Enabled.

    The Listening address field is displayed.

  3. Select a cluster interface for the node to listen on.

    Figure 86: Basic Settings > Local Services > Cluster Interface — Enabling cluster management

  4. Click Commit.

Building a cluster

Purpose:

Build a cluster by promoting a Safeguard for Privileged Sessions node to the role of the Central Management node, and then join other nodes to your cluster. To build a cluster, complete the following steps.

Prerequisites:

Enable the cluster interface on all nodes that you want to be part of your cluster. For details on how to do that, see Enabling cluster management.

Steps:
  1. Promote a node to be the Central Management node:

    1. Navigate to Basic Settings > Cluster management > Promote this node to the Central Management role.

      Figure 87: Basic Settings > Cluster management — Promote node to become Central Management node in cluster

    2. Click Promote.

      NOTE:

      This is an action that you cannot undo or modify.

    The Central Management node you have just added is displayed.

    Figure 88: Basic Settings > Cluster management \xe2\x80\x94 View Central Management node in cluster

    You can also promote a node through the REST API. For details, see REST API Reference Guide.

  2. Join additional nodes to your cluster:

    Caution:

    Configuration options (for example, any policies, protocol-specific settings) that you set on a node before joining it to the cluster will be overwritten by the configuration of the Central Management node once you assign the Managed Host role to the node. Managed Host roles periodically fetch the configuration of the Central Management node and merge it into their own. This is called configuration synchronization.

    To avoid the loss of policies, protocol-related settings, and so on that are specific to your Managed Host node, use a configuration synchronization plugin, which enables you to limit the scope of configuration synchronization.

    For more information, see Configuration synchronization across nodes in a cluster.

    1. On the node that you want to join to the cluster, navigate to Basic Settings > Cluster management.

      Figure 89: Basic Settings > Cluster management — Join node to cluster

    2. In the IP address of Central Management node field, enter the IP address of the Central Management node.

    3. Click Join.

      NOTE:

      This is an action that you cannot undo. After clicking Join, you will still be able to change the IP address. However, you will not be able to promote this node to be the Central Management node.

      A dialog box with the token of the node pops up.

      Figure 90: Token of node to join to cluster

    4. Copy the token, and click Ok.

    5. On the Central Management node, navigate to Basic Settings > Cluster management > Add new node.

    6. Paste the token in the Token field.

    7. Click Add.

      The node you have added is displayed in the list of nodes on the Central Management node.

      Figure 91: Basic Settings > Cluster management — Nodes added to cluster

      If you want to centrally manage the configuration of the node(s) you have joined to the cluster, assign the Managed Host role to them. For details on how to do that, see Assigning roles to nodes in your cluster.

    You can join additional nodes to your cluster through the REST API, too. For details, see REST API Reference Guide.

Assigning roles to nodes in your cluster

Purpose:

By default, nodes do not have any roles assigned to them. The only exception is the Central Management node, which you specifically promoted to fulfill that role. To assign a role to a node in the cluster, complete the following steps.

Steps:
  1. On the web interface of your Central Management node, navigate to Basic Settings > Cluster management. This page displays all nodes of a cluster.

  2. Click next to the node that you want to assign a role to. The available roles are displayed.

  3. Select the role that you want to assign to the node. For details on what each role means, see Cluster roles.

    Caution:

    Configuration options (for example, any policies, protocol-specific settings) that you set on a node before joining it to the cluster will be overwritten by the configuration of the Central Management node once you assign the Managed Host role to the node. Managed Host roles periodically fetch the configuration of the Central Management node and merge it into their own. This is called configuration synchronization.

    To avoid the loss of policies, protocol-related settings, and so on that are specific to your Managed Host node, use a configuration synchronization plugin, which enables you to limit the scope of configuration synchronization.

    For more information, see Configuration synchronization across nodes in a cluster.

    NOTE:

    Regarding search roles:

    • Ensure that each node has a search role and only one search role.
    • You must assign the Search Master role before you can assign Search Minion roles.

    Figure 92: Basic Settings > Cluster management — Assign role to node

  4. Click Commit.

    The role you assigned is now displayed next to the node, under Roles.

    Figure 93: Basic Settings > Cluster management — Role is assigned to node

    You can assign roles to your nodes through the REST API, too. For details, see REST API Reference Guide.

Related Documents