Chat now with support
Chat with Support

One Identity Safeguard for Privileged Passwords 2.11.2 - Administration Guide

Introduction System requirements Using the virtual appliance and web management console Using the cloud Setting up Safeguard for Privileged Passwords for the first time Search box Using the web client Installing the desktop client Using the desktop client Privileged access requests Toolbox Accounts Account Groups Assets Asset Groups Discovery 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 Safeguard Access settings Sessions 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 Appendix E: Historical changes by release Glossary

What's new in version 2.9.0.10658

One Identity Safeguard for Privileged Passwords introduces the following new features and enhancements in this version.

Appliance diagnostics package (797266)

Appliance Administrators can execute a trusted, secure appliance diagnostics package to help solve issues with configuration, synchronization, and clustering, as well as other other internal challenges. The appliance diagnostics package is available from the web Support Kiosk, not the Serial Kiosk (Recovery Kiosk). The appliance diagnostics package can be used even when the appliance is in quarantine. To protect against external threats, Safeguard rejects illegitimate appliance diagnostics packages. The manifest file in the appliance diagnostics package lists criteria that may include the minimum Safeguard version, appliance ID, and expiration time-stamp UTC. New product code and database changes are not included in an appliance diagnostics package.

SPP-SPS join enhancements (803185)

Safeguard for Privileged Passwords (SPP) is enhanced to more easily use Safeguard for Privileged Sessions (SPS) for session recording and playback.

Appliance Administrators can identify the SPP SPS join connections by:

  • Host Name
  • Network Address (identified by the IP address of the session connection)
  • Other nodes in the SPS cluster

  • Other nodes that belong to each SPS cluster that has been joined to SPP

Navigate to Administrative Tools | Settings | Cluster | Session Appliances for details.

Appliance Administrators can also identify managed networks by the host name and IP address of the cluster master. Navigate to Administrative Tools | Settings | Cluster | Managed Networks and view Sessions Managed By.

Policy Administrators can identify the host name and IP address of the SPS cluster master from which policies originate. A Warning icon displays if a policy is not functional. Navigate to Administrative Tools | Entitlements | Access Request Policies | Session Settings tab and view the SPS Connection Policy.

Users and administrators receive timely notification if an access request will not result in a launchable session request. The notifications identify details such as:

  • User are informed if SPP could not contact SPS and are given the option to try again so the request can be redirected to another managed host in the SPS cluster.
  • Policy Administrators can identify the SPS connection policies by the host name and IP address of the SPS cluster master from which the policies originate.

  • User are informed if the SPS configuration is locked and are given the option to try again later. This condition is typically because the SPS administrator is making configuration changes to the SPS appliance at the same time that a new access request is being created or a session is being launched.

Telnet and TN3270/TN5250 session access request support (782501)

Safeguard for Privileged Passwords (SPP) supports session access requests with mainframes using software terminal emulation including telnet and TN3270/TN5250 over telnet. Safeguard for Privileged Sessions (SPS) version 6.1 or higher is used for session recording.

Actions

  • Security officers can record activities of administrators who maintain critical systems running on IBM iSeries and mainframe computers.
  • Asset Administrators can:
    • Customize the TN3270/TN5250 login screen field detection to work for the Safeguard custom login setup.
    • Mark an asset as supporting telnet sessions and specify if the asset is available.
  • Policy Administrators can create an entitlement with an access policy that includes session access using telnet and TN3270/TN5250 sessions over telnet.
  • Requesters' log in experience follows the regular client telnet or TN3270/TN5250 interface even when the session is being recorded. Sessions are not launched from Safeguard for Privileged Passwords and all required log in information is available through Safeguard for Privileged Passwords.

High level steps

IMPORTANT: Engagement with One Identity Professional Services is required for assistance with configurations and installation including available plug-ins, policy creation, pattern files, shortcuts, and best practices.

In Safeguard for Privileged Sessions (SPS), the following steps are required. For operation details, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions Administration Guide.

  • Until supplied by SPS, import the plug-in to supply authentication and authorization (AA) information to authenticate with and pull the credentials from SPP.
  • Create and assign Pattern Sets which use pattern files specific to the log in experience for each system connection, which vary from mainframe to mainframe.
  • Specify each Authentication Policy.
  • Configure each Connection Policy. Multiple connection policies are typically required because of the uniqueness of each system and pattern file.
  • Perform related activities based on your installation.

In Safeguard for Privileged Sessions (SPS):

  • The Asset Administrator adds the mainframe asset including the Telnet Session Port that is identified on the Administrative Tools | Asset | Management tab. For more information, see Adding an asset.
  • The Policy Administrator sets the Access Type (Telnet) on the Administrative Tools | Entitlements | Access Request Policies tab.
  • When configuration is complete, the requester proceeds to use the terminal service application in use. The requester will copy the required information based on the telnet or TN3270/TN5250 over telnet connection requirements.

For more information, see How do I set up telnet and TN3270/TN5250 session access requests.

Additional log in step and two-factor authentication with FIDO2 (79072)

IMPORTANT: All users will experience an additional step to log in to Safeguard for Privileged Passwords. After clicking Connect, the user sees a message like: You'll now be redirected to your web browser to complete the login process. You can select: Don't show this message again. Then, click OK. The browser window can be closed. On the user login screen, the user entered the User Name and Password as usual.

A new secondary authentication type, FIDO2, is now supported and can be assigned to any Safeguard for Privileged Passwords user, providing they have at least one compatible FIDO2 authenticator security key. After being configured by a User Administrator, a Safeguard for Privileged Passwords user will be prompted to register their FIDO2 authenticator security key at next login. For more information, see Requiring secondary authentication log in.

Users are then responsible for managing their own FIDO2 authenticator keys, including registering additional keys for backup purposes, viewing, renaming, or deleting unused keys. For more information, see User information and log out (desktop client).

Authenticator support

Any FIDO/FIDO2 authenticator that supports the WebAuthn standard can be used for two-factor authentication, this includes some older U2F authenticator security keys. Safeguard for Privileged Passwords does not use or require any authenticator attestation data. User verification, such as PIN or biometric is also not used.

Virtual appliance using Hyper-V (801564)

The Appliance Administrator can use Hyper-V as the virtual target environment deployed by importing the Safeguard for Privileged Passwords Hyper-V zip file with the virtual machine settings.

VMware ESXi: Backup and restore required

vSphere Hypervisor (ESXi) is enhanced in Safeguard for Privileged Passwords (SPP) 2.9. For SPP 2.9 only, you are required to take a backup of your 2.8.x system and restore it on your SPP 2.9 system. Future versions will not require this action.

CAUTION: Failure to backup of your 2.8.x system and restore it on your SPP 2.9 system will result in loss of configuration and functionality.

What's new in version 2.10.0.10980

One Identity Safeguard for Privileged Passwords introduces the following new features and enhancements in this version.

A2A service supports events for multiple accounts (804349)

Using the A2A service, an administrator can use a single signalR connection to monitor password change events for multiple accounts across multiple A2A registrations.

A signalR connection failure message is returned if any of the following occur:

  • The accounts sent in the authorization header is larger than 8K.
  • One or more of the API keys sent failed validation.
  • One or more of the API keys sent failed to match the user certificate used for authentication. This may occur across multiple A2A registrations.

Active Directory account discovery dynamic tags and dynamic groups (798532)

An Asset Administrator can:

  • Dynamically tag an account from Active Directory.
  • Add an account to a dynamic account group based on membership in an Active Directory group.
  • Add an account to a dynamic account group based on if the account is in a particular organizational unit (OU) in Active Directory.

The options to select Include objects from sub containers is available when adding an account discovery rule from Administrative Tools | Discovery | Account Discovery | Account Discovery Rule dialog. For more information, see Adding an Account Discovery rule.

Configure Web Client Inactivity Timeout (803424, 782603)

The Appliance Administrator can configure the Web Client Inactivity Timeout which is the time that has elapsed since the user made a request to the server. The minimum value is 5 minutes and the maximum value is 2880 minutes (2 days). When the timeout period is met, a message displays and the user can continue or log out. If there is no response, the user is automatically logged out. The default is 15 minutes. To configure the value, navigate to Administrative Tools | Settings | Safeguard Access | Login Control and set Web Client Inactivity Timeout.

"Other Managed" platform type (805372)

To ensure the automation environment is compliant, a System Integrator can use a generated password that is securely stored and periodically rotated.

To ensure compliance in an ultra secure environment, an Asset Administrator can manage an asset that Safeguard for Privileged Passwords cannot connect to (for example, when there is a one-way firewall).

In the Add Asset dialog under the Management tab, select the Product setting Other Managed. When selected, Safeguard for Privileged Passwords stores the password and can automatically check and change it per the profile configuration. There is no active connection or service account. The passwords are rotated internally and an event notifications is sent when the rotation is complete. Another component or piece of automation can change the password or make use of the password in the configuration files. For example, a listener can pick up the change event via the Safeguard for Privileged Passwords Application to Application (A2A) service and perform actions, as required.

What's new in version 2.11.0.11444

One Identity Safeguard for Privileged Passwords introduces the following new features and enhancements in this version.

Access requests proceed regardless of the review state of an earlier request (TFS 805354/DevOps 191598)

Policy Administrators can choose to allow subsequent access requests to proceed even if the required review on a previous access request is incomplete. This prevents blocking a new session request when the prior request requires a review and the review is not done. Navigate to Administrative Tools | Entitlements | Access Request Policies | (create or edit a policy) | Reviewer tab. For more information, see Reviewer tab.

Audit history for passwords and sessions (TFS 805354/DevOps 191549)

In preparation for a future release of Safeguard for Privileged Sessions, a toggle has been added to allow the Safeguard for Privileged Passwords Appliance Administrator to push audit data to SPS. Navigate to Administrative Tools | Settings | Appliance | Enable or Disable Services. For more information, see Enable or Disable Services .

Azure to run in cloud (191524)

Safeguard for Privileged Passwords (SPP) can be run in the cloud using Azure. A version of Safeguard for Privileged Passwords is available in the Azure Marketplace.

Generic ticket system without ticket system validation (TFS 794519/Dev Ops 191534)

Policy Administrators can require requesters to reference a ticket number in their password or session access request. Tickets do not have to be validated against an external ticketing system but, optionally, may be validated against the regular expression of a generic ticketing system. The ticket number is used in the decision to approve the request and serves as a reference visible in the Activity Center. Navigate to Administrative Tools | Settings | External Integration | Ticket Systems. In Type, select Other. For more information, see Ticketing systems.

Support dynamic grouping for assets based on Active Directory groups (TFS 806225/ DevOps 191499)

Implementers can create tags / asset groups based on any Active Directory group of which the asset is a member unrelated to discovery.

For account or asset groups, use the rule editor controls on:

  • Account Rules tab of the Dynamic Account Group dialog
  • Asset Rules tab of the Dynamic Asset Group dialog

To add a dynamic tag for an asset or asset account, use the New button on the Tags pane in the Settings | Asset Management settings page.

Web client (TFS 795288/DevOps 200361)

The Safeguard for Privileged Passwords web client provides a web-based user interface that can be used instead of the desktop client for the request workflow and some administration functions.

Requesters use the web client to:

  • Search for and request password access, session access, or both.
  • Concurrently request access to multiple passwords and sessions.
  • Create and use a favorite to quickly access the common access requests.

Reviewers use the web client to review requests.

Approvers use the web client to:

  • See the access requests awaiting approval.
  • See which access requests require immediate attention.
  • View the details of each access request.
  • Approve or deny an access request.
  • Select multiple access requests to approve or deny at the same time.
  • Return to an approved, active access request and revoke the request.

Administrators can also use the web client to:

  • Configure time, network, and license.
  • Shutdown or reboot the appliance

For more information, see Using the web client.

Windows SSH platform (TFS 792427/DevOps 191511)

Safeguard for Privileged Passwords can utilize SSH to connect to the target Windows asset and run commands to manage standard platform tasks. Using SSH only requires opening a single well known SSH port. OpenSSH is the recommended connectivity tool; however, other SSH servers may also work. Windows SSH assets support both SSH password and SSH session access requests. From Administrative Tools | Assets | Management tab, you can select the Product as Windows SSH and the Version.

Best practices

When configuring the SSH service on the asset, it is recommended to use automatic (versus manual) startup. You can also set the default shell to PowerShell. You can control this by going to HKLM\SOFTWARE\OpenSSH and creating a new string value called "DefaultShell and setting it to C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

Glossary

Related Documents