Chat now with support
Chat with Support

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

Uploading external certificates to One Identity Safeguard for Privileged Sessions (SPS)

Upload a certificate generated by an external PKI system to One Identity Safeguard for Privileged Sessions (SPS).

Prerequisites

The certificate to upload. For the TSA X.509 Certificate and Server X.509 Certificate, the private key of the certificate is needed as well. The certificates must meet the following requirements:

  • SPS accepts certificates in PEM format. The DER format is currently not supported.

  • SPS accepts private keys in PEM format, using RSA, DSA, and EC private key algorithms. Password-protected private keys are also supported.

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

    For the internal CA certificate of SPS, uploading the private key is not required.

  • For the TSA certificate, the X509v3 Extended Key Usage extension must be set to critical with the value Time Stamping. Also, the Key Usage extension must be non repudiation and digital signature (that is, without key encipherment or other key usage).

  • For the Server certificate, the X509v3 Extended Key Usage extension must be set to TLS Web Server Authentication. Also, the Common Name of the certificate must contain the domain name or the IP address of the SPS host. If the web interface is accessible from multiple interfaces or IP addresses, list every IP address using the Subject Alt Name extension.

  • For the certificate used to sign audit trails, the X509v3 Extended Key Usage extension must be set to Sign (downloadable) executable code.

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

To upload a certificate generated by an external PKI system to SPS

  1. Navigate to Basic Settings > Management > SSL certificates.

  2. Click to upload the new certificate. A pop-up window is displayed.

    Figure 151: Basic Settings > Management > SSL certificates — Uploading certificates

    Select Browse, select the file containing the certificate, and click Upload.

    For the Server X.509 Certificate

    For the Server X.509 Certificate, you can also upload a certificate chain. For that, copy the certificates after each other in a single file. Alternatively, you can copy and paste the certificates one by one after each other into the Certificate field and click Set. The certificates do not have to be in order, SPS will order them and validate the chain: if a member of the chain is missing, an error message is displayed.

    NOTE: Certificate chains are supported only for the Server X.509 Certificate.

  3. To upload the private key corresponding to the certificate, click icon. A pop-up window is displayed.

    Figure 152: Basic Settings > Management > SSL certificates — Uploading the private key

    Select Browse, select the file containing the private key, provide the Password if the key is password-protected, and click Upload. Alternatively, you can also copy-paste the private key into the Key field, provide the Password there, and click Set.

    In the case of a certificate chain, the private key has to be the same as the bottom level certificate.

    Expected result

    The new certificate is uploaded. If you receive the Certificate issuer mismatch error message after importing a certificate, you must import the CA certificate which signed the certificate as well (the private key of the CA certificate is not mandatory).

    NOTE: To download previously uploaded certificates, click on the certificate and either download the certificate (or certificate chain) in one single PEM or DER file, or you can download single certificate files separately (if it is a certificate chain).

Generating TSA certificate with Windows Certificate Authority on Windows Server 2008

To generate a TSA certificate with Windows Certificate Authority (CA) that works with One Identity Safeguard for Privileged Sessions (SPS), generate a CSR (certificate signing request) on a computer running OpenSSL and sign it with Windows CA, then import this certificate into SPS for timestamping.

Prerequisites

A valid configuration file for OpenSSL with the following extensions:

[ tsa_cert ]
extendedKeyUsage = critical,timeStamping

TIP: You can copy /etc/xcb/openssl-ca.cnf from SPS to the computer that will be used for signing. Rename the file to openssl-temp.cnf.

The TSA certificate is considered valid, in terms of compatibility with SPS, if the following conditions are met:

  • The X509v3 Extended Key Usage extension of the TSA certificate is set to critical with the value Time Stamping.

  • The Key Usage extension is non repudiation and digital signature (that is, without key encipherment or other key usage).

    		 Caution:

    In Encryption, do not select Allow key exchange only with key encryption (key encipherment), because it will result in errors.

The following X509v3 extensions are supported:

  • Hard requirement:

    X509v3 Extended Key Usage must be critical, and must only contain Time Stamping.

  • Optional:

    X509v3 Key Usage, if present, must be digitalSignature and/or nonRepudiation.

To generate TSA certificate with Windows Certificate Authority on Windows Server 2008

  1. Create CSR using the new configuration file: openssl req -set_serial 0 -config openssl-temp.cnf -reqexts tsa_cert -new -newkey rsa:2048 -keyout timestamp.key -out timestamp.csr -nodes

  2. Complete the required fields according to your environment:

    Generating a 2048 bit RSA private key
........................+++
......................................+++
writing new private key to 'timestamp.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) []:New York
Locality Name (eg, city) []:New York
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Examplecompany IT Security
Organizational Unit Name (eg, section) []:Service Delivery
Common Name (eg, YOUR name) []:scb35-1-i1.tohuvabohu.examplecompany
Email Address []:vlad@examplecompany.com

  3. Sign the generated CSR with your Windows CA. Make sure that the CSR file is accessible from your Windows CA server.

    1. To issue and sign the new certificate request, open the Microsoft Certification Authority Management Console: Start > Run and run certsrv.msc.

    2. Right-click on the server name and navigate to All Tasks > Submit new request....

      Figure 153: Submitting a new request

    3. Select the CSR created in the second step.

    4. On the left pane, click Pending Requests. The new certificate request is displayed in the right pane.

      Figure 154: Issuing a new certificate

    5. To issue the new SSL certificate, right-click on the pending certificate request, select “All Tasks” and click on “Issue”.

    6. Select "Issued Certificates" and double-click on the certificate issued in the previous step.

    7. The CA Certificate window opens. Navigate to the Details tab. Ensure that the required Enhanced Key Usage field is visible and contains the Time Stamping value.

      Figure 155: Verifying certificate details

    8. Click Copy to File. The Certificate Export Wizard launches. Click Next.

    9. Select the format of the certificate: Base-64 encoded X.509 (.CER). Click Next.

      Figure 156: Selecting certificate file format

    10. Select location to save the certificate, and save it.

    11. The Completing the Certificate Export Wizard screen is displayed. Click Finish.

  4. In SPS, navigate to Basic Settings > Management > SSL certificates.

  5. Click next to TSA X.509 certificate, browse for the previously generated certificate, and click Upload.

  6. Click next to TSA private key, browse for the previously generated key, and click Upload.

    NOTE: If the root CA (the CA X.509 certificate field under Basic Settings > Management > SSL certificates) that is used for other certificates on SPS is different from the CA that was used to sign the TSA certificate, a warning is displayed. In this scenario, ignore this warning.

Generating TSA certificate with Windows Certificate Authority on Windows Server 2012

To generate a TSA certificate with Windows Certificate Authority (CA) that works with One Identity Safeguard for Privileged Sessions (SPS), generate a CSR (certificate signing request) on a computer running OpenSSL and sign it with Windows CA, then import this certificate into SPS for timestamping.

Prerequisites

A valid configuration file for OpenSSL with the following extensions:

[ tsa_cert ]
extendedKeyUsage = critical,timeStamping

TIP: You can copy /etc/xcb/openssl-ca.cnf from SPS to the computer that will be used for signing. Rename the file to openssl-temp.cnf.

The TSA certificate is considered valid, in terms of compatibility with SPS, if the following conditions are met:

  • The X509v3 Extended Key Usage extension of the TSA certificate is set to critical with the value Time Stamping.

  • The Key Usage extension is non repudiation and digital signature (that is, without key encipherment or other key usage).

    		 Caution:

    In Encryption, do not select Allow key exchange only with key encryption (key encipherment), because it will result in errors.

The following X509v3 extensions are supported:

  • Hard requirement:

    X509v3 Extended Key Usage must be critical, and must only contain Time Stamping.

  • Optional:

    X509v3 Key Usage, if present, must be digitalSignature and/or nonRepudiation.

To generate TSA certificate with Windows Certificate Authority on Windows Server 2012

  1. Create CSR using the new configuration file: openssl req -set_serial 0 -config openssl-temp.cnf -reqexts tsa_cert -new -newkey rsa:2048 -keyout timestamp.key -out timestamp.csr -nodes

  2. Complete the required fields according to your environment:

    Generating a 2048 bit RSA private key
........................+++
......................................+++
writing new private key to 'timestamp.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) []:New York
Locality Name (eg, city) []:New York
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Examplecompany IT Security
Organizational Unit Name (eg, section) []:Service Delivery
Common Name (eg, YOUR name) []:scb35-1-i1.tohuvabohu.examplecompany 
Email Address []:vlad@examplecompany.com

  3. Create and configure a time stamping web server template in the Certificate Authority, and use that to generate the TSA certificate.

    1. Start the Certification Authority Microsoft Management Console, and select the CA server.

    2. Right-click on Certificate Templates, and choose Manage.

      Figure 157: Managing certificate templates

      The Certificate Templates Console opens.

    3. Right-click the Web Server template, and choose Duplicate Template.

      Figure 158: Duplicating a Template

      The Properties of New Template window is displayed.

    4. Make the following changes to the new template:

      • On the General tab, change the Template display name to TSA.

        Figure 159: Creating the new template

      • On the Request Handling tab, enable the Allow private key to be exported option.

      • On the Extensions tab, make the following changes:

        Edit Application Policies

        Select Application Policies and click Edit below the list of extensions.

        Figure 160: Editing Application Policies

        Remove Server Authentication

        Select Server Authentication and click Remove.

        Figure 161: Removing Server Authentication

        Add Time Stamping

        Click Add, select Time Stamping and click OK.

        Figure 162: Adding Time Stamping

        Make Time Stamping critical

        Select Time Stamping and enable the Make this extension critical option, then click OK.

        Figure 163: Making Time Stamping critical

        Time Stamping and Critical extension are listed in the Description of Application Policies.

        Figure 164: Description of Application Policies

        Edit Key Usage

        Select Key usage, click Edit. Enable the Signature is proof of origin (nonrepudiation) option.

        Select Allow key exchange without key encryption (key agreement).

        Click OK.

        Figure 165: Editing Key Usage

        The following are listed in the Description of Key Usage.

        Figure 166: Description of Key Usage

      • On the Security tab, select Authenticated Users, and set Enroll to Allow.

        Figure 167: Configuring permissions for the template

    5. Click Apply. Click OK. The new TSA template is now displayed in the list of templates.

      Figure 168: The new TSA template is now displayed in the list of templates

    6. Close this window and return to the Certification Authority main screen, and select the Certificate Templates folder.

      Figure 169: Certificate Templates

      Right-click under the list, and choose New > Certificate Template to Issue.

      Figure 170: Certificate Template to Issue

      The Enable Certificate Templates window is displayed.

      Figure 171: Enable the new template

    7. Select the TSA certificate template, and choose OK. Close this window.

    8. Open the command line, and issue the following command:

      certreq -submit -attrib "CertificateTemplate:TSA" <CSR>

      Replace <CSR> with the full path of the CSR created earlier (in the second step).

    9. The Certification Authority List is displayed. Select the CA.

    10. The Save Certificate window is displayed. Choose an output folder.

      The certificate is generated to the specified folder.

  4. In SPS, navigate to Basic Settings > Management > SSL certificates.

  5. Click next to TSA X.509 certificate, browse for the previously generated certificate, and click Upload.

  6. Click next to TSA private key, browse for the previously generated key, and click Upload.

    NOTE: If the root CA (the CA X.509 certificate field under Basic Settings > Management > SSL certificates) that is used for other certificates on SPS is different from the CA that was used to sign the TSA certificate, a warning is displayed. In this scenario, ignore this warning.

General connection settings

Connections determine if a server can be accessed from a particular client.

  • The policies used in the connection definition can restrict the availability of the connection based on the user name, time, authentication method, and so on. Channel policies (see Creating and editing channel policies) determine if a particular channel can be used within an already established connection.

  • The policies used in the channel policy can restrict the availability of the channel based on the server and the client IP address, user name, and so on. The types of policies available in a connection depend on the protocol (SSH, RDP, and so on) enabled in the connection.

SPS compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. SPS applies to the connection the first connection policy that completely matches the connection request.

This section describes how to configure connections, and details the general configuration options and policies that apply to every type of connection that SPS can control: HTTP, ICA, RDP, SSH, Telnet, and VNC. For a detailed list of supported protocol versions, see Supported protocols and client applications.

Protocol-specific configuration options are described in their respective sections: HTTP-specific settings, ICA-specific settings, RDP-specific settings, SSH-specific settings, Telnet-specific settings, and VNC-specific settings.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating