One Identity Safeguard for Privileged Sessions 6.4.0 - Administration Guide

Timestamping audit trails with external timestamping service

The following describes how to request timestamps from a remote Timestamping Authority (TSA).

To request timestamps from a remote TSA

1. Configure the remote TSA, and the timestamping interval. You have to repeat these steps for each protocol (HTTP, ICA, RDP, SSH, Telnet, and VNC) you want to configure:

   Figure 154: <Protocol name> Control > Global Options — Configuring a remote TSA

   

   1. In the protocol control settings, navigate to Global Options > Timestamping (for example, SSH Control > Global Options > Timestamping).

   2. Select Remote.

   3. Enter the address of the timestamping server into the URL field. Note that currently only plain HTTP services are supported, password-protected and HTTPS services are not supported.

   4. If the Timestamping Server has timestamping policies configured, enter the OID of the policy to use into the Timestamping policy field. One Identity Safeguard for Privileged Sessions (SPS) will include this ID in the timestamping requests sent to the TSA.

   5. Set the Signing interval. You can choose any value between 10 and 100 000 seconds.

      NOTE:

      The same interval setting applies to timestamping and signing.

   6. Click .

2. Configure audit policies to use timestamping. You have to repeat these steps for each audit policy you want to configure:

   1. Navigate to Policies > Audit Policies and select the audit policy you will use in your connections.

      TIP:

      By default, every connection uses the built-in default audit policy. Unless you use a custom audit policy, modifying the default audit policy will affect every audited channel of the connections passing through One Identity Safeguard for Privileged Sessions (SPS).

   2. Select the Enable timestamping option.

      Figure 155: Policies > Audit Policies — Timestamping audit trails

      

   3. Click . SPS will automatically add timestamps to the audit trails of every connection that is audited and uses this audit policy.

Digitally signing audit trails

One Identity Safeguard for Privileged Sessions (SPS) can digitally sign the audit trails to prevent the manipulation of the audit trail files. This requires an X.509 certificate and also the private key of the certificate. Note that SPS can generate a private key that you can use to create a certificate, but SPS itself cannot create the certificate used to sign the audit trails.

To enable the digital signing of the audit trails

1. Configure the signing interval. You have to repeat these steps for each protocol (HTTP, ICA, RDP, SSH, Telnet, and VNC) you want to configure:

   Figure 156: <Protocol name> Control > Global Options — Configuring the signing interval

   

   1. In the protocol control settings, navigate to Global Options > Timestamping (for example, SSH Control > Global Options > Timestamping).

   2. Set the Signing interval. You can choose any value between 10 and 100 000 seconds.

      NOTE:

      The same interval setting applies to timestamping and signing.

   3. Click .

2. Navigate to Policies > Audit Policies and select the audit policy you will use in your connections.

   Figure 157: Policies > Audit Policies — Signing audit trails

   

   TIP:

   By default, every connection uses the built-in default audit policy. Unless you use a custom audit policy, modifying the default audit policy will affect every audited channel of the connections passing through One Identity Safeguard for Privileged Sessions (SPS).

3. Select the Enable signing option.

4. Upload a certificate and the corresponding private key to SPS.

5. Click . SPS will automatically sign the audit trails of every connection that is audited and uses this audit policy.

6. Repeat the above steps for other audit policies if needed.

Verifying certificates with Certificate Authorities

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

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

   Figure 158: 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 X.509 CRLs are accepted in either PEM and DER format. PKCS7 CRLs 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 .

Signing certificates on-the-fly

At a number of places, One Identity Safeguard for Privileged Sessions (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

1. Navigate to Policies > Signing CAs and click .

2. Select:
   • Local to use the built-in signing CA solution, and complete the following steps:
     1. Enter a name for the CA into the topmost field.

        Figure 159: Policies > Signing CAs — Creating Signing CAs - Local

        

     2. 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 Edit 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 Edit in the CA private key field and upload the private key of the certificate authority that will sign the certificates.

        3. (Optional) 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 .

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

   • External Plugin to use an external signing CA plugin, and complete the following steps:
     1. Enter a name for the CA into the topmost field.

        Figure 160: Policies > Signing CAs — Creating Signing CAs - External Plugin

        

     2. From the Plugin field, select an uploaded external plugin using the drop-down menu.

        To be able to select from the drop-down menu, you must have an external plugin uploaded in Basic Settings > Plugins > Signing CAs.

        For more information about how to create an external Signing CA plugin, see Creating an external Signing CA.

     3. Optionally, fill the Configuration field as required by the uploaded plugin.

        The input you enter in the Configuration field is passed down to the plugin.