サポートと今すぐチャット
サポートとのチャット

Safeguard for Privileged Passwords On Demand Hosted - Administration Guide

Introduction System requirements and versions Using API and PowerShell tools Using the virtual appliance and web management console Cloud deployment considerations Setting up Safeguard for Privileged Passwords for the first time Using the web client Getting started with the desktop client Using the desktop client Activity Center Search box Privileged access requests Toolbox Accounts Account Groups Assets
General/Properties tab (asset) Accounts tab (asset) Account Dependencies tab (asset) Owners tab (asset) Access Request Policies tab (asset) Asset Groups tab (asset) Discovered SSH Keys (asset) Discovered Services tab (asset) History tab (asset) Managing assets
Asset Groups Discovery Entitlements Linked Accounts Partitions Profiles Settings
Access Request settings Appliance settings Asset Management settings Tags Backup and Retention settings Certificates settings Cluster settings Enable or Disable Services settings External Integration settings Password Management settings Real-Time Reports Safeguard Access settings SSH Key Management settings Security Policy Settings
Users User Groups Disaster recovery and clusters Administrator permissions Preparing systems for management Troubleshooting Frequently asked questions Appendix A: Safeguard ports Appendix B: SPP 2.7 or later migration guidance Appendix C: SPP and SPS join guidance Appendix D: Regular Expressions About us

Appendix C: SPP and SPS join guidance

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

The Asset Administrator can link 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 link 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 linked, 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.

CAUTION: When linking your One Identity Safeguard for Privileged Sessions (SPS) deployment to your One Identity Safeguard for Privileged Passwords (SPP) deployment, ensure that the SPS and SPP versions match exactly, and keep the versions synchronized during an upgrade. For example, you can only link SPS version 6.6 to SPP version 6.6, and if you upgrade SPS to version 6.7, you must also upgrade SPP to 6.7.

Make sure that you do not mix Long Term Supported (LTS) and feature releases. For example, do not link an SPS version 6.0 to an SPP version 6.1.

NOTE: If you have a single node SPS cluster where the Central Management node is also the Search Master, SPP will be unable to launch sessions. There has to be at least one SPS appliance in the cluster that is capable of recording sessions. See the SPS Administration Guide, Managing Safeguard for Privileged Sessions (SPS) clusters.

Additional overview information can be found in the Safeguard for Privileged Sessions Administration Guide, Using SPS with SPP.

Session recording, playback, and storage after the link
  • Sessions recorded after the link are playable through SPP and are stored on the SPS appliance. An archive server can be set up through SPS.
  • Sessions recorded prior to linking 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 link.
Functionality in SPS after the link

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

  • Session certificate assignment is handled by SPS. The certificate is available for audit by the Auditor.
  • After the link, 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.
    • Identify the SSH host key presented to the user's SSH client when an SSH session is started.
    • (Optional) Configure the SPS SSH connection policy to control how both SPS and SPP handle host key checking. If the SPS SSH connection policy is set to Only accept trusted keys, SPP will detect the setting and not allow a session to be initialized without a host key. However, if the SPS SSH connection policy is set to Accept key for the first time or Disable SSH host key checking, SPP will allow the session to be initialized without a host key and defer the host key checking to SPS.
    • Identify the status of the session module, such as session module health.
    • Edit the default policy.

The primary provider names must match for a SPS initiated RDP connection with SPP. See KB article 311852.

Functionality in SPP after the link
  • During the link, SPP sets the SPS Connection Policy to safeguard_default for SSH or safeguard_rdp for 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 link. 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 play back a session from SPP. Starting with session player 1.9.4, sessions can be played in SPP with full indexing (which makes the privileged users' activity searchable). However, if you are using an earlier version of the sessions player then indexing is only available in 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 link, 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 link

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

  1. SPP embedded sessions module was remove in SPP 6.0 LTS so this step should have been completed earlier. If not, move the SPP embedded sessions recordings from local SPP to an archive server.
    • Prior to moving to SPP 6.0: If the link has not been started, you can use the SPP user interface to archive existing SPP sessions:
      1. Set up the archive server. Navigate toFor more information, see Archive servers.
      2. Assign the archive server to the SPP appliances. 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.

    • After moving to SPP 6.0 or if the link is complete, use the API to archive existing SPP sessions.

      1. Use the API PUT Core/v3/SessionArchiveConfigs/{id}. Call this API giving it the ID of the archive server (GET Core/v3/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. Starting with SPP 6.7, you must call POST /core/v3/SessionArchiveConfigs/ArchiveRecordings to push the recording files to the assigned archive server and POST /core/v3/SessionArchiveConfigs/RemovedArchivedRecordings to delete the recording files from the SPP appliance local storage.
      3. 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 link is performed when open access requests are not pending, if possible.

    When the SPS session connection is linked, 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.
Step 2: Link SPS and SPP

The link is initiated from Safeguard for Privileged Sessions. For details about the link steps and issue resolution, see the One Identity Safeguard for Privileged Sessions Administration Guide.

NOTE: SPP can target a specific SPS appliance or network interface by IP address. This is done by configuring the SPS connection policy to specify an explicit TO address (for example, CIDR notation /32). When that connection policy is selected as the SPS connection policy for the access policy, SPP will construct a connection string that targets that specific IP address.

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: One Identity Safeguard for Privileged Sessions - Technical Documentation.

Step 3: Perform post link activities in SPP and SPS

Steps to perform in SPP

  1. The Appliance Administrator assigns the managed networks for sessions management.

    Navigate to Appliance Management | Cluster | Managed Networks. For more information, see Managed Networks.

  2. The Appliance Administrator can view, delete, or edit link connections, as needed.

    Go to Appliance Management | Cluster | Session Appliances. For more information, see Session Appliances with SPS link.

    If you soft delete a session connection, then reconnect, the access policies remain available. If you hard delete, the Security Policy Administrator will need to relink and reestablish the SPS Connection Policy. For more information, see Connection deletion: soft delete versus hard delete.

  3. The Security Policy Administrator identifies 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 Security Policy Management | 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 Security tab, go to the SPS Connection Policy. The host name of the cluster master is displayed first followed by the IP address: 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.

  4. While on the Access Request Policies dialog, the Security Policy Administrator checks any other tab, as needed. The link does not affect the settings on the tabs including the General, Scope, Requester, Approver, Reviewer, Access Config, Time Restrictions, and Emergency tabs.

Steps to perform in SPS

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

Standard operating procedure after the initial link

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

  1. Add link connections. For more information, see Session Appliances with SPS link.
  2. Identify the session settings on the entitlements access request policy (SPS Connection Policy that is the IP address of the cluster master). For more information, see Creating an access request policy (desktop client).
  3. Assign the managed networks. For more information, see Managed Networks.

Appendix D: Regular Expressions

Regular expressions are used to parse large amounts of data to find matching patterns and validate a predefined pattern. For example, in Safeguard for Privileged Passwords, regular expressions are used for:

  • Account Discovery rules (Property Constraints, Name Ranges and Group Ranges). Partial matches are acceptable (unless the regular expression itself is defined to only return exact matches).
  • Ticket numbers when an external ticketing system is not used. Matches must be exact.

For details, see these Microsoft resources:

Best practices for ticketing not tied to external ticket system

These best practices are for adding a regular expression for ticketing not tied to an external ticket system. For more information, see Ticketing systems.

If you use an alternation construct (“|” which is “or”), the longest matching expression is defined first to the least matching expression because Windows.Net regular expression (regex) stops after finding the first match.

For example: A{3}[0-9]{5}ZZZ|A{3}[0-9]{5} is advised instead of the reverse order. Sample entry results follow for the A{3}[0-9]{5}ZZZ|A{3}[0-9]{5} expression:

User entry: Match?  
AAA12345 Yes. Matched on the second regex  
AAA12345Z No. There is no exact match.  
AAA12345ZZZ

Yes. Matched on the first regex.

If the expression were reversed (A{3}[0-9]{5}|A{3}[0-9]{5}ZZZ) there would be a partial match on the first expression and the entry would be returned as invalid.

 

You may want to wrap each expression in an alternation construct with the anchors ^ and $ when using alternation constructs. An example follows: ^A{3}[0-9]{5}ZZZ$|^A{3}[0-9]{5}$.

The ? lazy quantifier should be avoided, especially at the end of the expression. For example, if the regex is A{3}[0-9]? and the user enters AAA12345, AAA1 is returned as a matched string which is not an exact match of AAA12345.

If the greedy quantifier (*) is used against AAA12345 then the matched string will be AAA12345 and be an exact match.

About us

One Identity solutions eliminate the complexities and time-consuming processes often required to govern identities, manage privileged accounts and control access. Our solutions enhance business agility while addressing your IAM challenges with on-premises, cloud and hybrid environments.

Contacting us

For sales and other inquiries, such as licensing, support, and renewals, visit https://www.oneidentity.com/company/contact-us.aspx.

Technical support resources

Technical support is available to One Identity customers with a valid maintenance contract and customers who have trial versions. You can access the Support Portal at https://support.oneidentity.com/.

The Support Portal provides self-help tools you can use to solve problems quickly and independently, 24 hours a day, 365 days a year. The Support Portal enables you to:

  • Submit and manage a Service Request
  • View Knowledge Base articles
  • Sign up for product notifications
  • Download software and technical documentation
  • View how-to videos at www.YouTube.com/OneIdentity
  • Engage in community discussions
  • Chat with support engineers online
  • View services to assist you with your product
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択