One Identity Safeguard for Privileged Sessions 6.4.0 - Administration Guide

Managing Safeguard for Privileged Sessions (SPS) clusters

When you have a set of two or more Safeguard for Privileged Sessions (SPS instances in your deployment, you can join them into a cluster. This has several advantages. You can:

• Manage the nodes from one central location.

• Monitor their status and update their configuration centrally.

• Search all session data recorded by all nodes in the cluster on a single node.

• Scale the performance of the cluster by adding new nodes and joining them to the cluster easily.

• Extend auditing to other networks by adding new nodes to the cluster and joining them to the cluster.

This is achieved by assigning roles to the individual nodes in your cluster: you can set one of your Safeguard for Privileged Sessions nodes to be the Central Management node and the rest of the nodes are managed from this central node.

You can configure your SPS cluster in the following ways:

• Configuration synchronization without a central search.

  It allows you to perform your configuration settings on your Central Management node. Managed Host nodes periodically fetch and merge the settings into their own (configuration synchronization). Central search is not configured and you can search for sessions on each node, including the Central Management node.

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

• Central search with configuration synchronization.

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

  It 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, see Central search with configuration synchronization.

Topics:

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: A One Identity Safeguard for Privileged Sessions (SPS) node with the Search Master role cannot be used for monitoring network traffic, or for session recording and auditing purposes.

  Before assigning this role to a node, read the limitations that apply to Search Master nodes carefully: Searching session data on a central node in a cluster

  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.

Enabling cluster management

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

To enable cluster management

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 88: Basic Settings > Local Services > Cluster Interface — Enabling cluster management

   

4. Click .

Building a cluster

Build a cluster by promoting a Safeguard for Privileged Sessions (SPS) node to the role of the Central Management node, and then join other nodes to your cluster.

To build a cluster

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 89: 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 90: Basic Settings > Cluster management— View Central Management node in cluster

   

   You can also promote a node through the REST API. For details, see "Promote a Safeguard for Privileged Sessions node to be the Central Management node in a new cluster" in the REST API Reference Guide.

2. Join additional nodes to your cluster:

   Caution: Configuration options that you set on a node before joining it to the cluster will be overwritten by the configuration of the Central Management node. For example, policies and protocol-specific settings will be overwritten 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 and settings that are specific to your Managed Host node, use a configuration synchronization plugin. Such plugins enable 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 91: 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 92: 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 93: 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 "Join node(s) to the cluster" in the REST API Reference Guide.