Chat now with support
Chat with Support

One Identity Safeguard for Privileged Passwords 2.7 - Release Notes

One Identity Safeguard for Privileged Passwords Release Notes

One Identity Safeguard for Privileged Passwords 2.7

Release Notes

May 2019

These release notes provide information about the One Identity Safeguard for Privileged Passwords 2.7 release.

About this release

One Identity Safeguard for Privileged Passwords Version 2.7 is a minor release with new features and resolved issues. The new features include:

  • Account discovery enhancements
  • Activity Center enhancements
  • Allow Oracle SYS account as a service account
  • Asset discovery enhancements
  • Custom platform: TN3270
  • Separate identity and management for directories for fine grained management
  • Microsoft SQL Server TCP/IP support
  • Multiple directory account session support with access request policy
  • Sessions Appliance join
  • Radius enhancements

For more detail, see:

NOTE: For a full list of key features in One Identity Safeguard for Privileged Passwords, see the One Identity Safeguard for Privileged Passwords Administration Guide.

About the Safeguard product line

The One Identity Safeguard for Privileged Passwords Appliance is built specifically for use only with the Safeguard for Privileged Passwords privileged management software, which is pre-installed and ready for immediate use. The appliance is hardened to ensure the system is secured at the hardware, operating system and software levels. The hardened appliance approach protects the privileged management software from attacks while simplifying deployment and ongoing management -- and shortening the timeframe to value.

Safeguard privileged management software suite

Safeguard privileged management software is used to control, monitor, and govern privileged user accounts and activities to identify possible malicious activities, detect entitlement risks, and provide tamper proof evidence. The Safeguard products also aid incident investigation, forensics work, and compliance efforts.

The Safeguard products' unique strengths are:

  • One-stop solution for all privileged access management needs
  • Easy to deploy and integrate
  • Unparalleled depth of recording
  • Comprehensive risk analysis of entitlements and activities
  • Thorough Governance for privileged account

The suite includes the following modules:

  • One Identity Safeguard for Privileged Passwords automates, controls and secures the process of granting privileged credentials with role-based access management and automated workflows. Deployed on a hardened appliance, Safeguard for Privileged Passwords eliminates concerns about secured access to the solution itself, which helps to speed integration with your systems and IT strategies. Plus, its user-centered design means a small learning curve and the ability to manage passwords from anywhere and using nearly any device. The result is a solution that secures your enterprise and enables your privileged users with a new level of freedom and functionality.
  • One Identity for Privileged Sessions is part of One Identity's Privileged Access Management portfolio. Addressing large enterprise needs, Safeguard for Privileged Sessions is a privileged session management solution, which provides industry-leading access control, as well as session monitoring and recording to prevent privileged account misuse, facilitate compliance, and accelerate forensics investigations.

    Safeguard for Privileged Sessions is a quickly deployable enterprise appliance, completely independent from clients and servers - integrating seamlessly into existing networks. It captures the activity data necessary for user profiling and enables full user session drill-down for forensics investigations.

  • One Identity Safeguard for Privileged Analytics integrates data from Safeguard for Privileged Sessions to use as the basis of privileged user behavior analysis. Safeguard for Privileged Analytics uses machine learning algorithms to scrutinize behavioral characteristics and generates user behavior profiles for each individual privileged user. Safeguard for Privileged Analytics compares actual user activity to user profiles in real time and profiles are continually adjusted using machine learning. Safeguard for Privileged Analytics detects anomalies and ranks them based on risk so you can prioritize and take appropriate action - and ultimately prevent data breaches.

New features

Sessions Appliance join (792394)

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.

Managing sessions via the Safeguard Sessions Appliance is now available for use in production. For this release, the embedded sessions module for Safeguard for Privileged Passwords is still available.

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

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

Safeguard for Privileged Passwords join guidance

Before initiating the join, review the steps and considerations in the join guidance. For more information, see Appendix C: SPP and SPS sessions appliance join guidance.For more information, see Appendix C: SPP and SPS sessions appliance join guidance.For more information, see Appendix C: SPP and SPS sessions appliance join guidance.

Safeguard for Privileged Sessions join steps and troubleshooting

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.

Separate identity and management for directories for fine grained management (773267)

The following information summarizes the changes at a high level. For more information specific for your initial deployment of Safeguard for Privileged Passwords 2.7, see the Safeguard for Privileged Passwords Administration Guide, Appendix B: SPP 2.7 Migration guidance.


Safeguard for Privileged Passwords version 2.7, has been simplified to allow for a separation of duties based only on identity management, asset management, access policy configuration, and appliance maintenance. In the migration to version 2.7, greater flexibility is realized through these high-level assignments:

  • Directories are migrated to assets.
  • Accounts include both directory accounts and asset accounts.
  • Each directory is assigned its own partition in the migration to version 2.7.

The following information details the changes from version 2.6 to version 2.7. The same information is generally true if you are upgrading from version 2.1 forward to version 2.7.


  • The Directory Administrator role is removed and users with Directory Administrator permission are assigned as partition owners for directories that are migrated to assets. This role does not include the ability to manage identity providers.
  • An Authorizer administrator can now add an Active Directory forest only for identity to use as an unprivileged service account for connection.
  • An Asset administrator can now:
    • Use service accounts to manage Active Directory. The service accounts can have limited permissions within a single domain.
    • Use multiple service accounts for managing the same Active Directory domain with different limited permissions within the domain. For example, the administrator can add the domain as a managed asset multiple times with different service accounts.
    • Use a service account from Active Directory to manage an asset from a different partition so that the administrator does not have to add that Active Directory to each of the administrator’s partitions.
    • Set up a dependent system for a service running as an Active Directory account that isn’t in the administrator’s partition. This avoids having to add the Active Directory asset or the account to the partition.
    • Add Active Directory for authentication to Safeguard for Privileged Passwords without managing any of the accounts in Active Directory.
    • Set up multiple assets for the same domain.


During the migration to version 2.7, directories are migrated as an asset with the appropriate identity provider and associated users.


Directories can be subdivided so administrators can be assigned to manage portions of a directory. For example, Admin A might only manage objects in the Finance organizational unit (OU) of the directory and Admin B might only manage objects in the Engineering OU of the directory. This is possible via the settings on Assets including the asset Name, Domain Name, and whether to Manage Forest. This way, multiple assets can govern the same domain.

Directory accounts can be service accounts to other assets to run windows services/tasks on assets to keep password changes in sync.


  • You can select a directory account and view the assets that have a dependency on the account.
  • You can sync passwords between a directory account and an asset account.


  • Directories are migrated to assets with the appropriate provider assignment.
  • Directories are still synced with Safeguard.
  • Migrated directory assets reflect the account dependencies.
  • You can select whether a directory asset manages the forest or a subset of the forest. Multiple assets be assigned against the same forest.
  • Migrated directory assets are available for access discovery jobs beyond partition boundaries.
  • Each migrated directory asset is assigned to its own partition and includes the Account Discovery schedules, the check and change schedules, account password rules, password sync groups, and related functions.
  • A directory is a member of an asset partition so that ownership of different parts of the directory can be delegated.
  • During import, entities imported from a directory must be unique across all partitions (for example, you cannot import Admin C account into multiple asset partitions).
  • When you add an asset, the Account Discovery schedule for the partition is displayed and can be changed.

Discovery schedules

  • Account discovery includes the option for discovered accounts: enable password requests, enable session requests, and make the discovered accounts available for use across all partitions.
  • Account discovery can be configured as Unix based, Windows based, or Directory based, each with its own schedule.

Account discovery enhancements (788930)

Asset Administrators and delegated partition owners can create account discovery jobs to perform the functions in the following list:

  • Set the default password of a discovered account to configure the environment initially and incrementally.
  • Add a discovered account to a sync group to configure the environment initially and incrementally.
  • Immediately check and change the password of discovered accounts that are set to be automatically managed. This places the account under immediate management rather than waiting for the schedule to execute.

    NOTE: In Settings | Profile, the partition profile's Change Password Schedule and Check Password Schedule must both be set to a value other than Never.

Activity Center enhancements (799288, 799308, 799307)

From the Activity Center, you have the option to choose All entities (such as users, assets, and accounts) without picking all of them. You can export the report without first previewing the report.

Allow Oracle SYS account as a service account (799993, 800128)

An Asset Administrator responsible for Oracle database servers can use the SYS account with either SYSDBA or SYSOPER system privileges as a service account.

The SYS account is automatically created when the administrator installs Oracle and has the necessary privileges. See the Oracle document, About Administrative Accounts and Privileges, for more information. The SYS user is automatically granted the SYSDBA privilege on installation and can be SYSOPER. For more details, see the Oracle document, SYSDBA and SYSOPER System Privileges.

This is set via setting the Service Name when you add or edit an asset. Navigate to Administrative Tools | Assets | Connection tab.

Asset discovery enhancements (782848)

Asset Administrators are now given:

  • Expanded connection options when setting up the connection template to discovered assets to automatically manage discovered assets and service accounts.
  • The ability to set a platform type in the asset discovery rules.
  • The ability to assign a different profile to service accounts in the asset discovery rules so that the service account is assigned a profile other than default asset profile inherited by other accounts discovered on the asset.

In addition, SSH keys are now auto-accepted for supported platforms.

Custom platform: TN3270 (798892)

An Asset Administrator responsible for an AS400 and mainframe infrastructure (such as ACF2 or RACF) can manage servers customized log in screens and connection strings.

A custom platform author can create a customer platform script to check and change passwords against servers where the login screens and connection strings have been customized.

Microsoft SQL Server TCP/IP support (798894, 799577)

An Asset Administrator responsible for Microsoft SQL Server can have Safeguard for Privileged Passwords connect to the databases using TCP/IP rather than named pipes.

Multiple directory account session support with access request policy (792426)

A Policy Administrator can add multiple directory accounts to a single access request policy. For example, you can grant access to a Windows asset via RDP using one of multiple directory accounts. Accounts are added when you create or edit an access request policy via the Administrative Tools | Entitlements | Access Request Policies | Directory Account option.

Radius enhancements (798896)

The User Administrator is offered two new configuration controls on Settings | External Integration | Identity and Authentication when Radius is selected as the provider.

  • The User Administrator can choose to mask the Radius secondary authentication response entered by users by selecting the Always Mask User Input check box. If selected, the text box that the user enters their one-time password, or other challenge required by the Radius server, will always be a password style text box in which the user's input is masked and appears as a series of dots, not as clear text. This may be desired when the challenge is not just a one-time password, but also contains the user's PIN. This will prevent any passer-by from seeing the private information. Note, however, that when this setting is enabled, it will also override the Prompt attribute of the Radius server's Access-Challenge response, such that the user's input will always be masked.

  • The User Administrator can choose to have the Radius secondary authentication pre-submit an Access-Request message to the Radius server in order to initiate a challenge/response cycle before the user sees or enters any information. The PreAuthenticate for Challenge/Response check box is used to indicate whether an Access-Request call containing only the User-Name should be sent to the Radius server prior to the user's authentication attempt. This is done to inform the Radius server of the user's identity so the server can possibly begin the authentication process by starting a challenge/response cycle. This may be required to seed the user's state data. In addition, the Radius server's response may include a login message that is to be displayed, which is specific to that user. Note, if the Radius server is not configured to respond with an Access-Challenge, then this will cause the log in to fail and the user will be unable to proceed.

In addition, the timeout for log in is now configurable to more than 60 seconds.

See also:


The following is a list of enhancements implemented in Safeguard for Privileged Passwords 2.7.

Table 1: General enhancements
Enhancement Issue ID

Add ability to set a profile on auto discovered accounts for directories.


Would like to set a default known password for all auto discovered accounts.


Custom platform sample script added for RACF mainframes.


Increase valid time for factory reset keys from 24 to 48 hours.


Allow customization of the SAP Client ID. Safeguard always uses Client ID 001.


Add password check out reason to the access request activity report.


Self Service Tools
Knowledge Base
Notifications & Alerts
Product Support
Software Downloads
Technical Documentation
User Forums
Video Tutorials
RSS Feed
Contact Us
Licensing Assistance
Technical Support
View All
Related Documents