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

Configuration synchronization across nodes in a cluster

Nodes fetch their configuration from the Central Management node, and merge it into their own configuration. Depending on their role, nodes may merge the whole configuration into their own (Managed Host nodes), or only the cluster-specific parts (nodes with no roles assigned). Whenever a configuration change is made on the Central Management node and the change is committed, it is synchronized to all nodes in the cluster as soon as the nodes fetch the latest configuration from the Central Management node.

Configuration synchronization has some implications for the SSH keys (if any) that have been recorded on your nodes before they were joined to the cluster. For details, see Configuration synchronization and SSH keys.

In some cases, you may want to keep certain parts of the configuration on your nodes outside the scope of configuration synchronization. In that case, use a configuration synchronization plugin. For more information, see Using a configuration synchronization plugin.

The following configuration settings are never overwritten by configuration synchronization, even when not using a configuration synchronization plugin:

  • settings related to networking (Basic Settings > Network)
  • settings related to local services (Basic Settings > Local Services)
  • settings related to the management of SPS (Basic Settings > Management)
  • settings related to the license of SPS (Basic Settings > System > License)

Configuration synchronization and SSH keys

The only SSH keys present on Managed Host nodes will always be the ones that have been recorded by the Central Management node. This is because the SSH keys stored on the Central Management node get synced to the Managed Host nodes during configuration synchronization. This means that the SSH keys recorded on the Managed Host nodes before they were joined to the cluster are overwritten by the keys stored on the Central Management node.

The Central Management records new SSH keys in the following cases:

  • The Central Management node is configured to Accept key for the first time and a new key is automatically recorded when the Central Management node interacts with a server for the first time.
  • A new key is recorded on the Central Management node on the SSH Control > Server Host Keys page and this change is committed.

These are the keys that get synced to your Managed Host nodes.

Using a configuration synchronization plugin

Purpose:

When synchronizing the central configuration across nodes, you may want to:

  • Keep certain parts in the configuration of individual nodes as-is.

  • Tailor certain parts of the central configuration to specific needs of individual nodes in the cluster (for example, your nodes may access external services at different network addresses).

You can achieve all of these by using a configuration synchronization plugin that contains transformations for the problematic parts. The plugin only runs on nodes that have the Managed Host role.

Customizing certain parts or features of a node using a configuration synchronization plugin has the same limitations as configuring SPS through the REST API. In other words, whatever you can configure through the REST API, you can configure the exact same settings using the plugin. One notable difference between the REST API and the plugin is that using the REST API, you can only read certain types of data (such as keys and passwords), while using the configuration synchronization plugin, you can write these types of data as well.

For details on how to configure SPS using the REST API, see REST API Reference Guide.

Data structures in the plugin are represented as nested JSON objects. For object references, the plugin uses keys.

The plugin works with the following key parameters:

  • local_config: The current configuration of a Managed Host node (those parts that can be configured through the REST API).
  • merged_config: The configuration of the Central Management node that is about to be synced to the Managed Host node (those parts that can be configured through the REST API), with settings related to networking, local services, management, and the license of SPS whitelisted. These settings are never overwritten by configuration synchronization.
  • node_id: The unique ID of the Managed Host node in the cluster (you can retrieve this identifier by querying the /api/cluster/nodes endpoint through the REST API).
  • plugin_config: The configuration of the plugin provided as free-form text. Specifying the configuration of the plugin is optional. It enables you to run configuration synchronization on each cluster with different parameters if you have multiple clusters.
Example: Customizing an IP address in a connection policy

For example, an RDP connection policy on a Managed Host node specifies the following client and target addresses:

$ curl ... https://<url-of-Central-Management-node>/api/configuration/rdp/connections/<id-of-the-connection-policy>

{
    "body": {
        "network": {
            "clients": [
                "0.0.0.0/0"
                ],
            "ports": [
                3389
                ],
           "targets": [
               "10.30.255.28/24"
               ]
        },
    },
    ...
}

Let's suppose that on the Central Management node, an RDP connection policy is configured with these details:

$ curl ... https://<url-of-Managed-Node>/api/configuration/rdp/connections/<id-of-the-connection-policy>

{
    "body": {
        "network": {
            "clients": [
                "0.0.0.0/0"
                ],
            "ports": [
                3389
                ],
           "targets": [
               "10.30.255.8/24"
               ]
        },
    },
    ...
}

To ensure that the details of the connection policy on the Managed Host node are kept as-is after configuration synchronization, add the following lines to the plugin main.py file:

$ cat main.py
def merge(local_config: dict, merged_config: dict, node_id: str, plugin_config: str, **kwargs):
    merged_config['rdp']['connections'][<id-of-the-connection-policy>]['network']['targets'][0] = "10.30.255.8/24"
    return merged_config

Due to possible new (as yet undefined) parameters, it is good practice to close the parameter list of the merge function with **kwargs.

In case you need assistance with writing customized transformations, contact professionalservices@balabit.com, and a One Identity Service Delivery Engineer will be able to help you.

NOTE:

Configuration settings related to networking (Basic Settings > Network), local services (Basic Settings > Local Services), the management of SPS (Basic Settings > Management), and the license of SPS (Basic Settings > System > License) are not overwritten on the nodes by configuration synchronization even when not using a plugin.

To use a configuration synchronization plugin, complete the following steps.

Steps:
  1. Upload a configuration synchronization plugin:

    1. Navigate to Basic Settings > Plugins.

    2. Browse for the file, and click Upload.

      NOTE:

      It is not possible to upload or delete plugins if SPS is in sealed mode.

  2. Enable the plugin:

    1. Navigate to Basic Settings > Cluster management > Configuration synchronization plugin.

    2. Select the plugin you have uploaded.

      Figure 94: Basic Settings > Cluster management — Select configuration synchronization plugin

  3. Optional: Enter the configuration of the plugin in the Configuration free-form text field. Specifying the configuration of the plugin enables you to run configuration synchronization on each cluster with different parameters if you have multiple clusters.
  4. Click Commit.

You can also upload and enable the configuration synchronization plugin through REST. For details, see REST API Reference Guide.

Monitoring the status of nodes in your cluster

Purpose:

To monitor the status of nodes in your 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.

    Figure 95: Basic Settings > Cluster management — Monitor status of nodes

    The following status information is displayed for each node:

    • Last seen: The last time the node sent status information to the Central Management node, in ISO 8601 format.

    • Last updated: The last time the node's configuration was synchronized, in ISO 8601 format.

    • Configuration status: Indicates the status of configuration synchronization. It has the following values:
      • UP-TO-DATE: The node has fetched the latest configuration from the Central Management node, and has applied it. It is in sync with the Central Management node.
      • PENDING: There has been a configuration change on the Central Management node, and the change has not been synchronized yet to the node.
      • OUTDATED: There has been some error on the node and therefore it is running an old configuration.
      • N/A: This can mean the following:
        • The node has not fetched any configuration yet.
        • The node is the Central Management node, so it is not fetching its configuration from any other node.
    • Status: Indicates whether any issues occurred during configuration synchronization. It has the following values:

      • OK: Configuration synchronization was successful, no issues occurred.

      • ISSUES: While synchronizing configuration, some issue(s) occurred. Click ISSUES to find out the details.

      • OFFLINE: Indicates that status information was sent by the node longer than 60 seconds ago.

    You can monitor the status of your nodes through the REST API, too. For details, see REST API Reference Guide and REST API Reference Guide.

Related Documents