Tchater maintenant avec le support
Tchattez avec un ingénieur du support

One Identity Safeguard for Privileged Sessions 7.5.1 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS)
The philosophy of One Identity Safeguard for Privileged Sessions (SPS) Policies Credential Stores Plugin framework Indexing Supported protocols and client applications Modes of operation Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) Archive and backup concepts Maximizing the scope of auditing IPv6 in One Identity Safeguard for Privileged Sessions (SPS) SSH host keys Authenticating clients using public-key authentication in SSH The gateway authentication process Four-eyes authorization Network interfaces High Availability support in One Identity Safeguard for Privileged Sessions (SPS) Versions and releases of One Identity Safeguard for Privileged Sessions (SPS) Accessing and configuring One Identity Safeguard for Privileged Sessions (SPS)
Cloud deployment considerations The Welcome Wizard and the first login Basic settings
Supported web browsers The structure of the web interface Network settings Configuring date and time System logging, SNMP and e-mail alerts Configuring system monitoring on SPS Data and configuration backups Archiving Cleaning up audit data Using plugins Forwarding data to third-party systems Starling integration
User management and access control
Login settings Managing One Identity Safeguard for Privileged Sessions (SPS) users locally Setting password policies for local users Managing local user groups Managing One Identity Safeguard for Privileged Sessions (SPS) users from an LDAP database Authenticating users to a RADIUS server Authenticating users with X.509 certificates Authenticating users with SAML2 Managing user rights and usergroups Creating rules for restricting access to search audit data Displaying the privileges of users and user groups Listing and searching configuration changes
Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing One Identity Safeguard for Privileged Sessions (SPS) clusters Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster Upgrading One Identity Safeguard for Privileged Sessions (SPS) Managing the One Identity Safeguard for Privileged Sessions (SPS) license Accessing the One Identity Safeguard for Privileged Sessions (SPS) console Sealed mode Out-of-band management of One Identity Safeguard for Privileged Sessions (SPS) Managing the certificates used on One Identity Safeguard for Privileged Sessions (SPS)
General connection settings HTTP-specific settings ICA-specific settings MSSQL-specific settings RDP-specific settings SSH-specific settings Using Sudo with SPS Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) REST API One Identity Safeguard for Privileged Sessions (SPS) scenarios Troubleshooting One Identity Safeguard for Privileged Sessions (SPS)
Network troubleshooting Gathering data about system problems Viewing logs on One Identity Safeguard for Privileged Sessions (SPS) Changing log verbosity level of One Identity Safeguard for Privileged Sessions (SPS) Collecting logs and system information for error reporting Collecting logs and system information of the boot process for error reporting Support hotfixes Status history and statistics Troubleshooting a One Identity Safeguard for Privileged Sessions (SPS) cluster Understanding One Identity Safeguard for Privileged Sessions (SPS) RAID status Restoring One Identity Safeguard for Privileged Sessions (SPS) configuration and data VNC is not working with TLS Configuring the IPMI from the BIOS after losing IPMI password Incomplete TSA response received Using UPN usernames in audited SSH connections
Using SPS with SPP Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help Configuring SPS to use an LDAP backend Glossary

Configuring public-key authentication using local keys

The following describes how to store the public keys of the users and the private-public keypair used in the server-side connection locally on One Identity Safeguard for Privileged Sessions (SPS).

To configure public-key authentication using local keys

  1. Navigate to Policies > Local User Databases and create a Local User Database. Add the users and their public keys to the database. SPS will authenticate the clients to this database. For details on creating and maintaining local user databases, see Creating a Local User Database.

  2. Navigate to Policies > Credential Stores and create a Local Credential Store. Add hostnames and the users to the database. SPS will use these credentials to authenticate on the target server. For details on creating local credential stores, see Configuring local Credential Stores.

  3. Navigate to Traffic Controls > SSH > Authentication Policies and create a new Authentication Policy.

  4. Select Authenticate the client to SPS using > Local > Public key, clear all other options.

  5. Select the appropriate usergroup from the Local User Database field. SPS will authenticate the users to this local database.

  6. Select Relayed authentication methods > Public key > Fix, clear all other options.

  7. Click > Generate. This will generate a private key that is needed only for the configuration, it will not be used in any connection.

    NOTE: The Connection Policy will ignore the settings for server-side authentication (set under Relayed authentication methods) if a Credential Store is used in the Connection Policy.

  8. Click .

  9. Navigate to Traffic Controls > SSH > Connections and create a new Connection.

  10. Enter the IP addresses of the clients and the servers into the From and To fields.

  11. Select the authentication policy created in Step 1 in the Authentication Policy field.

  12. Configure the other options of the connection as necessary.

  13. Click .

  14. To test the above settings, initiate a connection from the client machine to the server.

Configuring public-key authentication using an LDAP server and a fixed key

The following describes how to fetch the public keys of the users from an LDAP server and use a locally-stored private-public keypair in the server-side connection.

NOTE:

TIP: One Identity recommends using 2048-bit RSA keys (or stronger).

To configure public-key authentication using an LDAP server and a fixed key

  1. Navigate to Traffic Controls > SSH > Authentication Policies and create a new Authentication Policy.

  2. Select Authenticate the client to SPS using > LDAP > Public key, deselect all other options.

  3. Select Relayed authentication methods > Public key > Fix, deselect all other options.

  4. Select Private key and click . A pop-up window is displayed.

  5. Click Browse and select the private key of the user, or paste the key into the Copy-paste field. Enter the password for the private key into the Password field and click Upload.

    NOTE: SPS accepts passwords that are not longer than 150 characters and supports the following characters:

    • Letters A-Z, a-z

    • Numbers 0-9

    • The space character

    • Special characters: !"#$%&'()*+,-./:;<>=?@[]\^-`{}_|

    If the private key of the user is not available, click Generate to create a new private key. You can set the size of the key in the Generate key field. In this case, do not forget to export the public key from SPS and import it to the server. To export the key from SPS, just click on the key and save it to your local computer.

  6. Click on the fingerprint of the key in the Server side private and public key > Private key field and save the public key. Do not forget to import this public key to the server: all connections that use this new authentication policy will use this keypair on the server side.

  7. Click .

  8. Navigate to Policies > LDAP Servers and click to create a new LDAP policy.

  9. Enter the parameters of the LDAP server. For details, see Authenticating users to an LDAP server.

  10. If different from sshPublicKey, enter the name of the LDAP attribute that stores the public keys of the users into the Publickey attribute name field.

    Caution:

    The public keys stored in the LDAP database must be in OpenSSH format.

  11. Navigate to Traffic Controls > SSH > Connections and create a new Connection.

  12. Enter the IP addresses of the clients and the servers into the From and To fields.

  13. Select the authentication policy created in Step 1 from the Authentication Policy field.

  14. Select the LDAP policy created in Step 7 from the LDAP Server field.

  15. If the server accepts a user only from a specific IP address, select the Use original IP address of the client radiobutton from the SNAT field.

  16. Configure the other options of the connection as necessary.

  17. Click .

  18. To test the above settings, initiate a connection from the client machine to the server.

Configuring public-key authentication using an LDAP server and generated keys

The following describes how to fetch the public keys of the users from an LDAP server and have One Identity Safeguard for Privileged Sessions (SPS) generate a keypair that is used in the server-side connection on-the-fly, and upload the public key of this pair to the LDAP database.

To configure public-key authentication using an LDAP server and generated keys

  1. Navigate to Traffic Controls > SSH > Authentication Policies and create a new Authentication Policy.

  2. Select Authenticate the client to SPS using > LDAP > Public key, deselect all other options.

  3. Select Relayed authentication methods > Public key > Publish to LDAP, deselect all other options.

  4. Click .

  5. Navigate to Policies > LDAP Servers and click to create a new LDAP policy.

  6. Enter the parameters of the LDAP server. For details, see Authenticating users to an LDAP server.

  7. If different from sshPublicKey, enter the name of the LDAP attribute that stores the public keys of the users into the Publickey attribute name field.

    Caution:

    The public keys stored in the LDAP database must be in OpenSSH format.

  8. Enter the name of the LDAP attribute where SPS shall upload the generated keys into the Generated publickey attribute name field.

  9. Click .

  10. Navigate to Traffic Controls > SSH > Connections and create a new Connection.

  11. Enter the IP addresses of the clients and the servers into the From and To fields.

  12. Select the authentication policy created in Step 1 from the Authentication Policy field.

  13. Select the LDAP policy created in Step 7 from the LDAP Server field.

  14. If the server accepts a user only from a specific IP address, select the Use original IP address of the client radiobutton from the SNAT field.

  15. Configure the other options of the connection as necessary.

  16. Click .

  17. To test the above settings, initiate a connection from the client machine to the server.

Organizing connections in non-transparent mode

When using One Identity Safeguard for Privileged Sessions (SPS) in non-transparent mode, the administrators must address SPS to access the protected servers. If an administrator has access to more than one protected server, SPS must be able to determine which server the administrator wants to access. For each protected server, the administrators must address either different ports of the configured interface, or different alias IP addresses.

Detailed information about this topic
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation