What's new in version 184.108.40.20662
One Identity Safeguard for Privileged Passwords 220.127.116.1162 introduces the following new features and enhancements.
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 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, SPP 2.7 or later 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 jobs, 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 job for the partition is displayed and can be changed.
- 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:
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.
What's new in version 18.104.22.16833
One Identity Safeguard for Privileged Passwords introduces the following new features and enhancements in version 22.214.171.12433.
Virtual appliance and web management console (770749, 781091, 798013, 798014, 798527)
The Appliance Administrator responsible for racking and initial configuration of the appliance can create the virtual appliance, launch the Safeguard web management console, and select one of the following wizards.
- Initial Setup: Used to set up the virtual appliance for the first time including naming, OS licensing, and networking.
- Setup: After the first setup, Safeguard for Privileged Passwords updates and networking changes can be made via the web management console, Setup.
Support Kiosk: The Support Kiosk is used to diagnose and resolve issues with Safeguard for Privileged Passwords. Any user able to access the kiosk can perform low-risk support operations including appliance restart or shutdown and support bundle creation. In order to reset the admin password, the user must obtain a challenge response token from One Identity support.
Security and backups
To maximize security in the absence of a hardened appliance, restrict the access to the Safeguard virtual disks, the web management console, and the MGMT interface to as few users as possible. Recommendations:
- X0 hosts the public API and is network adapter 1 in the virtual machine settings. Connect this to your internal network.
- MGMT hosts the web management console and is network adapter 2 in the virtual machine settings. This interface always has the IP address of 192.168.1.105. Connect this to a private, restricted network accessible to administrators only or disconnect it from the network to restrict unauthenticated actions such as rebooting or shutting down the appliance. The web management console is also available via the VMware console.
Once setup is completed, you can verify which of your NICs is MGMT and X0 by referring to the MAC address information found in Support Kiosk | Appliance Information | Networking for X0 and MGMT.
To protect the security posture of the Safeguard hardware appliance, Safeguard hardware appliances cannot be clustered with Safeguard virtual appliances. Additionally, to ensure the security of the hardware appliance, backups taken from a hardware appliance cannot be restored on virtual appliances and backups taken from a virtual appliance cannot be restored on a hardware appliance.
Application to Application (A2A) enhancement: API visible to certificate user (794148)
When registering a third-party application configured for credential retrieval, the Policy Administrator can make the registration, including the API keys, visible to the certificate user that is configured for the A2A registration. The third-party application can discover the API key and other information needed. The Visible to certificate user check box can be selected when adding an application registration via Administrative Tools | Settings | External Integration | Application to Application.
Custom platform: telnet and HTTP support (799699, 787583)
Custom HTTP, SSH, telnet, and TN3270 transports are available. For more information, see Safeguard for Privileged Passwords Administration Guide,Custom platforms and Creating a custom platform script.
CAUTION: Facebook and Twitter functionality has been deprecated. Refer to the custom platform open source script provided on GitHub. Facebook and Twitter platforms will be remove in a future release.
Sample custom platform scripts and command details are available at the following links available from the Safeguard Custom Platform Home wiki on GitHub:
CAUTION: Example scripts are provided for information only. Updates, error checking, and testing are required before using them in production. Safeguard for Privileged Passwords checks to ensure the values match the type of the property which include: a string, boolean, integer, or password (which is called secret in the API scripts). Safeguard for Privileged Passwords cannot check the validity or system impact of values entered for custom platforms.
Advanced password complexity rules (780274)
Separate password complexity rules can be set for local users and managed accounts. Password rules can be finely managed.
- Set the allowable password length in a range from 3 to 225 characters.
- Set first characters type and last character type.
- Allow uppercase letters, lowercase letters, numbers, and/or printable ASCII symbols along with the minimum amounts of each.
- Identify excluded uppercase letters, lowercase letters, numbers, and symbols.
- Identify if consecutive letters, numbers, and/or symbols can be repeated sequentially and, if allowed, set the maximum repetitions allowed.
Passwords are validated against the password rules before they are saved.
Job scheduler enhancements (753203)
An Appliance Administrator can finely tune backup and password check and change job schedules including the ability to ensure changes occur after hours. The administrator can create time windows including start and end times, days of the week, and days in a month by a static day of month or the first through fourth day of the month.
Safeguard for Privileged Sessions (SPS) initiated session (797262)
The Safeguard for Privileged Passwords (SPP) Asset Administrator can enable an SPS initiated session to get the session credentials from SPP.
The administrator will navigate to Administrative Tools | Settings | External Integration | Sessions Management and set the Session Module Password Access Enabled toggle on or off. When the toggle is on (), SPS has the ability to create an access request and check out a password from SPP on behalf of another user. When the toggle is switched off (), this ability is revoked.
CAUTION: On the Session Settings tab, SPS Connection Policy, do not select Sps initiated unless you have SPS version 6.2.0 or later installed. This is used when an access policy is used by SPS to create an SPS initiated access request.
Support for additional ServiceNow ticket types (793493)
System integrators designing privileged account access based on ServiceNow tickets can include ticket types for validation during access request workflow. The following tickets types are supported in addition to INC tickets:
- PRB (problem) tickets
- CHG (change) tickets
- RITM (request) tickets
If the ticket number is found in any of the ServiceNow tables searched (INC, CHG, RITM, or PRB) and the ServiceNow API property for the ticket is "Active", the user can make the access request.
Administrators can search by a ticket number in the Activity Center to find the access request.
What's new in version 126.96.36.19958
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:
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.
- 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).
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 188.8.131.5280
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.