Chat now with support
Chat with Support

One Identity Safeguard for Privileged Passwords 2.4 - 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 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 Privileged Sessions 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

Prepare SonicOS devices

Safeguard for Privileged Passwords supports SonicOS Internet appliances. Safeguard for Privileged Passwords uses the SSH protocol to connect to SonicOS devices.

To prepare a SonicOS device for Safeguard for Privileged Passwords

  1. Create the service account as a local user on the managed system and assign it a password.
  2. Add the service account to the SonicWALL Administrators group. This allows the service account to access the device with SSH to manage users.

    Important: Safeguard for Privileged Passwords can only manage passwords for users that are members of the SonicWALL Administrators group.

  3. Enable and configure the SSH server to allow the service account to log in remotely.
  4. Add the SonicOS device to Safeguard for Privileged Passwords using password authentication.

Prepare SonicWALL SMA or CMS appliances

Here are some important notes about configuring a SonicWALL SMA or CMS appliance for Safeguard for Privileged Passwords:

  1. Use the local "admin" account as the service account.
  2. Safeguard for Privileged Passwords can only manage the admin account; it cannot manage other local accounts or accounts from external providers.

Prepare SQL Servers

To prepare a Microsoft SQL Server for Safeguard for Privileged Passwords, refer to the documentation for your SQL server for information about how to setup and secure encryption.

To enable SSL server certificate validation, add the server’s signing authority certificate to the Trusted Certificates store in Safeguard for Privileged Passwords. For more information, see Trusted Certificates.

For more information about how Safeguard for Privileged Passwords database servers use SSL, see How do Safeguard for Privileged Passwords database servers use SSL.

To configure a SQL Server for Safeguard for Privileged Passwords (with an authentication type of Local System Account)

NOTE: To manage a Microsoft SQL server asset with the authentication type of Local System Account, you need a local Windows account that is a Security Admin in SQL. In order to use this authentication type, you must add a Windows asset and a SQL Server asset to Safeguard for Privileged Passwords.
  1. Log into the Safeguard for Privileged Passwords desktop client as an Asset Administrator.
  2. Navigate to Administrative Tools | Assets.
  3. Add a Windows asset that matches the OS of the server that is hosting the SQL database.
    1. On the Connection tab,
      • Authentication Type: Set to Password.
      • Service Account: Set to a local user that is a member of the Administrator's group.
    2. Add other accounts as needed.

    Save the asset.

  4. Add a SQL Server asset.
    1. On the Connection tab,

      • Authentication Type: Set to Local System Account.
      • Service Account: Click (or tap) Select Account and select a local system account from the list.

        The accounts available for selection are Windows accounts that are linked to the Windows asset you added in Step 3.

      • Run Test Connection and verify the connection works.

    Save the asset.

To configure a SQL Server for Safeguard for Privileged Passwords (with an authentication type of Directory Account)

NOTE: To mange a Microsoft SQL asset with the authentication type of Directory Account, you need a domain account that is a Security Admin in SQL. In order to use this authentication type, you must add a directory and directory users to Safeguard for Privileged Passwords.
  1. Add a directory and directory users.
    1. Log into the Safeguard for Privileged Passwords desktop client as a Directory Administrator.
    2. Navigate to Administrative Tools | Directories to add a directory for your domain.
    3. Once added, select the domain and open the Accounts tab to add domain user accounts.

    For more information, see Directories.

  2. Add a SQL Server asset.
    1. Log into the Safeguard for Privileged Passwords desktop client as an Asset Administrator.
    2. Navigate to Administrative Tools | Assets to add a SQL Server asset.
    3. On the Connection tab,

      • Authentication Type: Set to Directory Account.
      • Service Account: Click (or tap) Select Account and select a domain user account from the list.

        The accounts available for selection are domain user accounts that are linked to the directory you added in Step 1.

      • Run Test Connection and verify the connection works.

    Save the asset.

Prepare Top Secret - Mainframe systems

Safeguard for Privileged Passwords can manage authorized Top Secret users who have a valid accessor ID (ACID) with the facility ‘TSO’ who can log on to the TSO interface.

This applies to both Top Secret- Mainframe and Top Secret - Mainframe LDAP platforms.

To prepare CA Top Secret mainframe systems for Safeguard for Privileged Passwords

  1. Create a service account on the asset, assign it a password, and grant it the ‘TSO’ facility.
  2. Grant the service account the following authority for ACIDs within its scope:
    1. Permission to list security record information for an ACID.
    2. MISC1(SUSPEND) authority, to remove the PSUSPEND attribute from ACIDs.
    3. Either ACID(MAINTAIN) or MISC8(PWMAINT) authority, to update the password of another ACID.
  3. If not already installed, install a Telnet server on the z/OS system. If required, secure Telnet with SSL.

    Note: Please refer to your IBM z/OS system documentation for details on installing and configuring the Telnet server (and SSL).

  4. Test the Telnet server using a Windows-based 3270 emulator or on Linux, use the telnet-ssl or x3270 programs to test SSL and non-SSL connections to an z/OS system.
  5. In Safeguard for Privileged Passwords, create the asset and accounts for the z/OS system using password authentication.
About certificate support for the TELNET protocol

Safeguard for Privileged Passwords automatically accepts any server certificate that the connection offers and does not verify the trust chain on the TELNET certificate. In addition, Safeguard for Privileged Passwords does not support client certificate selection so if TELNET requires that the client present a certificate that is signed by a recognized authority, Safeguard for Privileged Passwords cannot support that configuration.

Related Documents