One Identity Safeguard 2.7 - Release Notes

Appendix: Safeguard ports

Appendix C: SPP and SPS sessions appliance join guidance

CAUTION: The embedded sessions module in Safeguard for Privileged Passwords version 2.7 will be removed in a future release (to be determined). For uninterrupted service, organizations are advised to join to the more robust Safeguard for Privileged Sessions Appliance for sessions recording and playback.

Safeguard for Privileged Passwords version 2.7 introduced the ability to join Safeguard for Privileged Sessions for session recording and auditing.

The Asset Administrator can join a Safeguard for Privileged Sessions (SPS) cluster to a Safeguard for Privileged Password (SPP) cluster of one appliance or more for session recording and auditing. The actual join must be between the SPP primary and the SPS cluster master. This means that the Safeguard for Privileged Sessions (SPS) cluster is aware of each node in an SPP cluster and vice-versa.

Once joined, all sessions are initiated by the SPP appliance via an access request and managed by the SPS appliance and sessions are recorded via the Sessions Appliance.

Session recording, playback, and storage after the join
  • Sessions recorded after the join are playable through SPP and are stored on the SPS appliance. An archive server can be set up through SPS.
  • Sessions recorded prior to joining the Safeguard Sessions Appliances are not migrated to the SPS appliance. For that reason, it is recommended that the SPP sessions be migrated to an archive server prior to the join.
Functionality in SPS after the join

The following functionality handled in SPP's user interface is available in SPS after the join.

  • Session certificate assignment is handled by SPS. The certificate is available for audit by the Auditor.
  • After the join, you will set the following configurations in SPS. There is no migration of the SPP settings added via Administrative Tools | Entitlements | Access Request Policies | Session Settings. These include:
    • Session recording
    • SSH related command detection and controls (such as SFTP, SCP, and X11 forwarding)
    • RDP related command detection and controls (such as Windows title detection and allowing the clipboard)
  • In SPS, you will set the SSH banner text that is shown to session users when they initiate a privileged session notifying them the session will be recorded.
  • In SPS, you will identify the SSH host key presented to the user's SSH client when an SSH session is started.
  • In SPS, you will identify the status of the session module, such as session module health.
  • In SPS, you can edit the default policy.
Functionality in SPP after the join
  • During the join, SPP sets the SPS Connection Policy to safeguard_default for SSH or RDP, as appropriate and may need to be changed. This default is nothing more than SSH or RDP connection policy.
  • Other configuration set via the Access Request Policies dialog, are not affected by the join. These include: General, Scope, Requester, Approver, Reviewer, Access Config, Time Restrictions, and Emergency tabs.
  • The Activity Center shows all old sessions and new sessions per the configuration. You can playback a session from SPP. However, the session index which makes the privileged users' activity searchable is only available from SPS.
  • Entitlement reports have not changed.
  • On the Dashboard, administrators can still view and manage access requests and accounts failing tasks as usual.
  • After the join, Administrative Tools | Settings | Sessions functionality is no longer available and is handled via SPS. This includes session recording management, sessions module, SSH banner, and SSH host key.
Step 1: Prepare for the join

Move all session recording files from Safeguard for Privileged Passwords to an archive server.

  1. Move the SPP embedded sessions recordings from local SPP to an archive server.
    • If the join has not been started, you can use the SPP user interface to archive existing SPP sessions:
      1. Set up the archive server. Navigate to Administrative Tools | Settings | Backup and Retention | Archive Servers. For more information, see Archive servers.
      2. Assign the archive server to the SPP appliances. For more information, see Assigning an archive server to an appliance. SPP moves the files and deletes the local file storage.
      3. Verify the recordings have been archived by comparing the session events in the Activity Center with the actual recording files on the archive server.
      4. Test the playback of a recording stored on the archive server. You will need to download it before you can play it. For more information, see Replaying a session.
    • If the join is complete, use the API to archive existing SPP sessions.

      1. Use the API PUT Core/v2/SessionArchiveConfigs/{id}. Call this API giving it the id of the archive server (GET Core/v2/ArchiveServers) and the id of the appliance (GET Core/SessionArchiveConfigs). Calling the above POST API will assign an archive server to archive session recordings. Within a few minutes, all remaining recordings will be moved to the archive server and removed from the local SPP storage.
      2. Test the playback of a recording stored on the archive server. You will need to download it before you can play it. For more information, see Replaying a session.
  2. Ensure the join is performed when open access requests are not pending, if possible.

    When the SPS session connection is joined, open access requests are automatically closed. When you double-click the event in the Activity Center, the event details Action is Evicted.

  3. Back up your appliances and archive servers. For more information, see Backup and Retention settings on page 1.
Step 2: Join SPS and SPP

The join is initiated from Safeguard for Privileged Sessions. For details about the join steps and issue resolution, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions - Technical Documentation.

Pay attention to the roles assigned to the SPS nodes. The following caution is offered to avoid losing session playback from SPP.

CAUTION: Do not switch the role of an SPS node from the Search Local role to Search Minion role. If you do, playback of the sessions recorded while in the Search Local role may not be played back from the SPP appliance and may only be played back via the SPS web user interface. Recordings made with the node in Search Minion role are pushed to the Search Master node and are available for download to SPP. For details about SPS nodes and roles, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions - Technical Documentation.

Step 3: Perform post join activities in SPP and SPS

Perform these steps in SPP:

  1. Update the firewall rules.

    • Open the firewall connection to SPS. SPP will not broker the connection to SPS.
    • If open, you can close the firewall rule to open traffic though the Secure Shell (SSH) Protocol for SFTP/SCP transfers backups and session recordings to the archive server for the SPP embedded sessions module. Typically, this is port 22, protocol TCP (X0).
  2. Assign the managed networks for sessions management.

    Navigate to Administrative Tools | Settings | Cluster | Managed Networks. For more information, see Managed Networks.

  3. View, delete, or edit join connections.

    Go to Administrative Tools | Settings | External Integration | Sessions Management. For more information, see Sessions management with SPS joined on page 1.

  4. Identify the session settings on the entitlements access request policy.

    Perform the following steps to ensure each policy's session setting is correctly assigned.

    1. Navigate to Administrative Tools | Entitlements, select an entitlement, and open Access Request Policies.
    2. Double-click a policy, or select a policy and click Edit Access Policy.
    3. On the Session Settings tab, go to the SPS Connection Policy. The IP address of the cluster master is displayed first followed by the SPS cluster description: safeguard_default.

    4. If needed, select the cluster or appliance to which the policy applies.

      For more information, see Session Settings tab on page 1.

  5. While you are on the Access Request Policies dialog, check any other tabs, as needed. The join does not affect the settings on the tabs including the General, Scope, Requester, Approver, Reviewer, Access Config, Time Restrictions, and Emergency tabs.

In SPS:

Complete any set up in SPS required (such as setting up an archive server, the SSH banner, the SSH host key, and SSH or RDP related command detection and controls). For details, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions - Technical Documentation. :

Standard operating procedure after the initial join

If you add another SPS cluster after the initial join, follow these standard operating procedures:

  1. Add join connections. For more information, see Sessions management with SPS joined on page 1.
  2. Identify the session settings on the entitlements access request policy (SPS Connection Policy which is the IP address of the cluster master). For more information, see Session Settings tab on page 1. An access request policy is only assigned to one cluster.
  3. Assign the managed networks. For more information, see Managed Networks.
Reversing the join

CAUTION: It is not recommended to reverse the join. However, if you were using the embedded session prior to the join, you can return to the embedded sessions module via a factory reset or restoring the backup taken before the join. For more information, see Reversing the SPP to SPS join.

Related Documents