Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 5.8.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

Verifying certificates with Certificate Authorities

Purpose:

SPS can check the validity of certificates using the certificates and certificate-revocation lists of the certificate authorities that issued the certificates. This can be used for example to verify the certificates of the servers in SSH/RDP connections. To create a list of CA certificates to use during the certificate validation, complete the following steps:

Steps:
  1. Navigate to Policies > Trusted CA Lists and click to create a new list.

    Figure 153: Policies > Trusted CA Lists — Creating Trusted CA lists

  2. Enter a name for the CA list into the topmost field.

  3. Click in the Certificate field, and upload the certificate of the Certificate Authority (CA) that will be used to validate the certificates.

  4. Enter the URL of the Certificate Revocation List of the CA into the CRL field. Certificates appearing on the CRL list will be automatically rejected.

    NOTE:

    Note that only .pem format CRLs are accepted. CRLs that are in PKCS7 format (.crl) are not accepted.

  5. To further limit which certificates are accepted, you may use the following options:

    • Strict hostname check: Select this option to accept only certificates when the Common Name of the certificate contains the hostname or the IP address of the host showing the certificate.

    • Use DNS to lookup hostnames: Select this option to use the domain name server set on Basic Settings > Network > Naming to resolve the hostnames and IP addresses for certificate validation. If you have enabled the Strict hostname check option, you probably want to enable this option as well.

    • To restrict the accepted certificates based on the content of the certificate, enter the required value into the appropriate field of the User certificate validation section. For example, to accept only certificates that contain Example Inc. in their Organization Name field, enter Example Inc. in to the Organization Name field. In the Common name, E-mail address, and Alternative e-mail address fields you can use the $username macro to refer to the username used in the connection. This macro makes it possible to check that the user is using his own certificate.

  6. Click Commit.

Signing certificates on-the-fly

Purpose:

At a number of places, SPS can generate the server certificates on the fly. This technique is used for example in SSL-encrypted RDP sessions, RDP sessions that use Network Level Authentication (CredSSP), or SSH connections that use X.509-based authentication. To create a signing CA, complete the following steps:

NOTE:

Note the following points about using signing CAs:

  • Signing CAs require a CA certificate permitted to sign certificates, and also the corresponding private key.

  • These CAs cannot be used to sign audit trails. For details on how to configure the certificates used to sign audit trails, see Digitally signing audit trails.

  • The version of the generated certificates will be the same as the version of the signing CA.

  • SPS ignores the CRL (from the crlDistributionPoints extension) of the signing CA when generating certificates. If you want to include a CRL in the generated certificates, you must set it manually. See the following steps for details.

Steps:
  1. Navigate to Policies > Signing CAs and click .

    Figure 154: Policies > Signing CAs — Creating Signing CAs

  2. Enter a name for the CA into the topmost field.

  3. To upload a CA certificate and its private key, complete the following steps. Skip this step if you want to generate a CA on SPS.

    1. Click in the CA X.509 certificate field and upload the certificate of the certificate authority. Alternatively, you can upload a certificate chain, where one member of the chain is the CA that will sign the certificates.

    2. Click in the CA private key field and upload the private key of the certificate authority that will sign the certificates.

    3. Optional step: Enter the URL of the Certificate Revocation List (CRL) that you generated using your Certificate Authority in your Public Key Infrastructure (PKI) solution. The URL pointing to this CRL will be included in the certificate. This is the CRL information that will be shown to clients connecting to SPS.

      Note that the CRL list is not generated by the internal CA of SPS. The list must come from your own PKI solution.

    4. Click Commit.

  4. To generate a CA certificate on SPS, complete the following steps:

    1. Enter the Common Name for the CA certificate into the Common Name field. This name will be visible in the Issued By field of the certificates signed by this CA.

    2. Fill the other fields as required, then click Generate private key and certificate.

    3. Click Commit.

Creating a Local User Database

Purpose:

Local User Databases are available for RDP, SSH and Telnet protocols, and can be used to authenticate the clients to credentials that are locally available on SPS. Such credentials include passwords, public keys, and certificates. Local User Databases are most commonly used in inband gateway authentication scenarios. To create a Local User Database, complete the following steps.

NOTE:

To store credentials on SPS and use them to authenticate on the server, use a local Credential Store. For details, see Using credential stores for server-side authentication.

Steps:
  1. Navigate to Policies > Local User Databases and click .

  2. Enter the name of the Local User Database.

  3. Click to add entries.

    Figure 155: Policies > Local User Databases — Mapping keys and certificates

  4. Enter the name of the user into the Username field.

    NOTE:

    If you also use Usermapping policies, enter the username that the client will use on the server side. If you also use gateway authentication, the gateway username can be used as well.

    • If you use public-key based authentication on the client side, click the icon in the Public Keys and Certificates > Public keys field, and upload the public key of the client.

    • If you use certificate-based authentication on the client side, click the icon in the Public keys and Certificates > Certificates field, and upload the certificate of the client.

    SPS will verify that a client trying to use the username set in Step 3 is authenticating itself with the private key that corresponds to the uploaded public key or certificate.

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

  5. Repeat the above steps to add other users as required.

  6. Click Commit.

  7. Navigate to the Authentication Policies tab of the respective protocol and select the Local User Database there.

Configuring cleanup for the SPS connection database

Purpose:

SPS can automatically archive audit trails older than a specified retention time. However, the metadata of the corresponding connections is not deleted from the SPS connection database. Deleting the stored data about old connections decreases the size of the database, making searches faster, and might be also required by certain policies or regulations. The period after metadata is deleted can be specified individually for the different protocols, (for example, data about SSH connections can be stored longer than other connections) and also for every connection policy. In order to configure SPS to delete the metadata of old connections for a particular protocol, complete the following steps:

Steps:
  1. Navigate to the Global Options page of the respective protocol, for example, to SSH Control > Global Options.

  2. Figure 156: <Protocol name> Control > Global Options — Configuring connection database cleanup for a protocol

    Enter how long SPS (in days) should keep the metadata into the Delete search metadata from PSM after field. For example, if you specify 365, SPS will delete the data of connections older than a year. Enter zero (0) to keep the data indefinitely (this is also the default behavior of SPS).

    NOTE:

    The database cleanup occurs once a day at 22:01 PM.

    The time you specify in the Delete search metadata from PSM after field cannot be shorter than the Delete data from PSM after field set for the Archive policies used in the connections of this protocol. Note that since the database cleanup happens once a day at 22:01 PM, if you specify the same retention time, for example, 1 day in the Delete data from PSM after field, ensure that the archiving or cleanup is set to start before 22:01 PM.

    The time you specify in the Delete search metadata from PSM after field cannot be shorter than the Delete search metadata from PSM after field set in the individual connection policies of this protocol.

  3. Click Commit and repeat the previous step for other protocols if needed.

  4. Figure 157: <Protocol name> Control > Connections — Configuring connection database cleanup for a connection

    To delete the metadata of certain connections earlier than the time set in the Global Options > Delete search metadata from PSM after field of the protocol, navigate to the particular connection policy, and enter how long SPS (in days) should keep the metadata of the sessions of this connection policy into the Delete search metadata from PSM after field. Enter zero (0) to use the settings of the protocol (this is also the default behavior of SPS).

    NOTE:

    The time you specify in the Delete search metadata from PSM after field cannot be shorter than the Delete data from PSM after field set for the Archive policies used in the connections of this protocol. Note that since the database cleanup happens once a day at 22:01 PM, if you specify the same retention time, for example, 1 day in the Delete data from PSM after field, ensure that the archiving or cleanup is set to start before 22:01 PM.

  5. Click Commit and repeat the previous step for other connections if needed.

    Expected outcome:

    Every day SPS deletes the metadata of connections older than the given cleanup time from the connection database.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating