Chatta subito con l'assistenza
Chat con il supporto

One Identity Safeguard for Privileged Sessions 6.0.14 LTS - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS) Cloud deployment considerations The Welcome Wizard and the first login Basic settings
Supported web browsers and operating systems 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 and cleanup Forwarding data to third-party systems Joining to One Identity Starling
User management and access control Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing 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 RDP-specific settings SSH-specific settings Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Searching session data on a central node in a cluster Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) RPC API 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) 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 Appendix: Deprecated features Glossary

Disabling controlled traffic permanently

 NOTE:

Disabling the traffic affects only the traffic configured in the Connection policies, other traffic can pass SPS even if the all traffic is disabled. For details on configuring Connection policies, see General connection settings.

To disable controlled traffic permanently

  1. Figure 87: <Protocol name> Control > Global Options — Disabling the controlled traffic persistently

    Navigate to the Global Options page of the traffic type you want to disable, for example to SSH Control > Global Options to disable SSH traffic.

  2. Set the Traffic > Service field to disabled.

  3. Click Commit.

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.

 NOTE:

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

 NOTE:

One Identity recommends managing not more than a few tens of instances from the Central Management node.

Nodes in the cluster connect to each other using IPsec.

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.

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

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.

 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.

Prerequisite

The nodes in the cluster must connect to each other using IPsec.

NOTE: IPsec requires UDP ports 500 and 4500 to be open bidirectionally in the firewalls between the nodes.

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 Commit.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione