Chat now with support
Chat with Support

One Identity Safeguard for Privileged Passwords 2.5 - Administration Guide

Introduction System requirements Installing the One Identity Safeguard for Privileged Passwords desktop client Setting up Safeguard for Privileged Passwords for the first time Getting acquainted with the console Privileged access requests Toolbox Accounts Account Groups Assets Asset Groups Directories Entitlements Partitions Settings
Access Request settings Appliance settings Asset Management settings Backup and Retention settings Certificate settings Cluster settings External Integration settings Messaging settings Profile settings Access settings Sessions settings
Users User Groups Disaster recovery and clusters Administrator permissions Preparing systems for management Troubleshooting Frequently asked questions
How do I access the API How do I audit transaction activity How do I configure external federation authentication How do I manage accounts on unsupported platforms How do I modify the appliance configuration settings How do I prevent Safeguard for Privileged Passwords messages when making RDP connections How do I see which assets and/or accounts are governed by a profile How do I set the appliance system time How do I setup discovery jobs How do Safeguard for Privileged Passwords database servers use SSL What are the access request states What do I do when an appliance goes into quarantine What is required for One Identity Safeguard for Privileged Passwords, embedded sessions module What is required to integrate with Starling Identity Analytics & Risk Intelligence What needs to be set up to use Application to Application What role-based email notifications are generated by default When does the rules engine run for dynamic grouping and tagging Why did the password change during an open request Why join Safeguard for Privileged Passwords to One Identity Starling
Safeguard Desktop Player Appendix: Safeguard ports

Approving a password release request

Depending on how the Security Policy Administrator configured the policy, a password release request will either require approval by one or more Safeguard for Privileged Passwords users, or be auto-approved. This process ensures the security of account passwords, provides accountability, and provides dual control over the system accounts.

Note: You can configure Safeguard for Privileged Passwords to notify you of a password release request that requires your approval. For more information, see Configuring alerts.

To approve or deny a password release request

  1. From your  Home page, the Approvals widget has these controls:
    1. Select  (expand down) to open the list of approvals.
    2. Select  Popout to float the Approvals pane.

      You can then select and drag the pane to any location on the console and re-size the window.

    Note: You enable or disable the Home page widgets in the  Console Settings menu.

  2. Open the list of approvals and select one of these view filters:
    State Description
    All Password release requests in all states.
    Pending Requests that are waiting for approval.
    Approved Requests that have been approved, but not yet available to the requester.

    Note: The number indicates how many requests are in that state.

  3. Once you open the list, select the requester's name to see the details of the password release request.

  4. Take the following actions on password release requests:

    State Actions
    Pending

    Select to Approve or Deny a password release request.

    Optionally, enter a comment of up to 255 characters.

    Pending Additional Approvers

    Select to Deny a password release request.

    Optionally, enter a comment of up to 255 characters.

    Approved

    Select to Deny or Revoke an approved request.

    Note: You can revoke a request between the time the requester views it and checks it in.

    Any eligible approver can deny a password release request after it has already been approved or auto-approved. Once disallowed, the requester will no longer have access to the password, but he is given another opportunity to request that password again. The requester receives an email notifying him that the request was denied.

Reviewing a completed password release request

The Security Policy Administrator can configure an access request policy to require a review of completed password release requests for accounts in the scope of the policy.

You can configure Safeguard for Privileged Passwords to notify you of a password release request that requires your review. For more information, see Configuring alerts.

To review a completed password release request

  1. From your  Home page, the Reviews widget has these controls:
    1. Click  (expand down) to open the list of pending reviews.
    2. Click  Popout to float the Reviews pane.

      You can then select and drag the pane to any location on the console and re-size the window.

    Note: You enable or disable the Home page widgets in the  Console Settings menu.

  2. Open the list of pending reviews and select an account name to see the details of the password release request.

  3. Take the following action on password release requests:

    • Select Workflow to review the transactions that took place in the selected request.
    • Select  Review to complete the review process.

      Optionally, enter a comment of up to 255 characters.

    Once the review is complete, it no longer appears on the Reviews pane.

TIP: If one requester checks in the request and another requester wants to use it, the second requester is unable to check out the password until the original request has been reviewed. However, the Security Policy administrator can Close a request that has not yet been reviewed. This will bypass the reviewer in the workflow and allow the account to be accessed by another requester.

Session request workflow

With the embedded sessions module, authorized users can authorize connections, view active connections, limit access to specific resources, be alerted if connections exceed pre-set time limits and even terminate connections.

Typically a session request follows this workflow.

  1. Request: Users that are designated as an authorized "user" of an entitlement can request an RDP or SSH session for any asset in the scope of that entitlement's policies.
  2. Approve: Depending on how the Security Policy Administrator configured the policy, a session request will either require approval by one or more Safeguard for Privileged Passwords users, or be auto-approved.
  3. Review: The Security Policy Administrator can optionally configure an access request policy to require a review of completed requests for assets in the scope of the policy. In addition, if session recording is enabled in the policy, reviewers can audit the workflow transactions and launch the Safeguard for Privileged Passwords Player to replay the session as part of the review process.

The following topics explain the entire end-to-end session access process from request to approval to review (and play back if sessions recording is enabled).

About sessions and recordings

One Identity Safeguard for Privileged Passwords proxies all sessions to target resources. Users do not have direct access to resources, therefore, the enterprise is protected against viruses, malware or other dangerous items on the user's system. One Identity Safeguard for Privileged Passwords for Privileged Sessions can proxy and record Unix/Linux, Windows, network devices, firewalls, routers and more.

Important notes
  • The Safeguard for Privileged Passwords Desktop Player, used to play back recorded sessions, is installed with the Windows desktop client.
  • Safeguard for Privileged Passwords PuTTY is installed with the Windows desktop client and is used to launch the SSH client if PuTTY is not available on the machine.
  • For some systems (SUSE and some Debian systems) that use SSH, you must enable password authentication in the package generated configuration file (sshd_config). For example, in the debian sshd_config file, set the following parameter: PasswordAuthentication yes.

  • Sessions requests are enabled by default. However, if authorized users cannot request sessions, check the Session Requests Enabled setting (Administrative Tools | Settings | Access Request | Enable or Disable Services).

    NOTE: You must have Appliance Administrator permissions to manage the service settings.

  • All session activity - every packet sent and action that takes place on the screen, including mouse movements, clicks and keystrokes - is recorded and available for play back.
  • If Safeguard for Privileged Passwords detects no activity for 10 minutes during a privileged session, the session is terminated.
  • It is highly recommended to assign an archive server for each Safeguard for Privileged Passwords Appliance's session recordings to avoid filling up the appliance's disk space. For more information, see Session Recordings Storage Management.

  • Both SSH and RDP session recordings use the Timestamping Certificate Authority. For more information, see Sessions Certificates.

    Recordings are signed and timestamped every 30 seconds so that partial recordings may be verified as authentic.

  • During an RDP session, the embedded sessions module proxies the connection to the target asset.

    When an RDP connection is established, the embedded sessions module will generate a certificate on the fly and sign it using the RDP Connection Signing Certificate. Therefore the RDP client trusts the RDP Connection Signing Certificate and the generated certificate that is signed by the RDP Connection Signing Certificate. This allows the client to verify that the connection is trusted.

  • During an SSH session, the Privileged Sessions module proxies the connection to the target asset. Therefore, Safeguard for Privileged Passwords's SSH host key (Settings | Sessions | SSH Host Key) must be trusted by the client. This SSH host key is unique and produced during manufacturing. This key can be trusted by the client or replaced with a different key if desired.

Related Documents