Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 5.9.0 - Administration Guide

Preface Introduction The concepts of SPS The Welcome Wizard and the first login Basic settings User management and access control Managing SPS
Controlling SPS: reboot, shutdown Managing Safeguard for Privileged Sessions clusters Managing a high availability SPS cluster Upgrading SPS Managing the SPS license Accessing the SPS console Sealed mode Out-of-band management of SPS Managing the certificates used on SPS
General connection settings HTTP-specific settings ICA-specific settings RDP-specific settings SSH-specific settings Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search (classic) interface Using the Search interface Searching session data on a central node in a cluster Advanced authentication and authorization techniques Reports The SPS RPC API The SPS REST API SPS scenarios Troubleshooting SPS Configuring external devices Using SCP with agent-forwarding Security checklist for configuring SPS Jumplists for in-product help Third-party contributions About us

SPS scenarios

This chapter discusses common scenarios for SPS.

Configuring public-key authentication on SPS

If a protected server requires public-key authentication from the users, complete one of the following procedures.

Configuring public-key authentication using local keys

Purpose:

To store the public keys of the users and the private-public keypair used in the server-side connection locally on SPS, complete the following steps:

Steps:
  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 SSH Control > Authentication Policies and create a new Authentication Policy.

  4. Select Authenticate the client to PSM 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 Commit.

  9. Navigate to SSH Control > 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 Commit.

  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

Purpose:

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, complete the following steps:

NOTE:

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

Steps:
  1. Navigate to SSH Control > Authentication Policies and create a new Authentication Policy.

  2. Select Authenticate the client to PSM 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. The following special characters can be used: !"#$%&'()*+,-./:;<=>?@[\]^-`{|}

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

  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 SSH Control > 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 Commit.

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

Related Documents