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

Replaying audit trails in your browser in Search (classic)

Purpose:

Caution:

You can replay audit trails in your browser, or using the Safeguard Desktop Player application. Note that there are differences between these solutions.

Browser Safeguard Desktop Player
Works without installation -
Works on any operating system Windows, Linux
Can replay audit trails recorded with SPS 5 F4 and newer
Can replay TN5250 sessions
Can extract files from SCP, SFTP, and HTTP sessions -
Can replay HTTP sessions - Only exports raw files from the command line
Can replay X11 sessions
Can start replay while rendering is in progress -
Can follow 4-eyes connections -
Can replay live streams in follow mode -
Can export to PCAP -
Can search in the trail content -
Can display user input
Can display subtitles for video -
Export audit trail as video -
Export screen content text -

To replay audit trails in your browser in Search (classic), see "Replaying audit trails in your browser in Search (classic)" in the Administration Guide.

For details on the Safeguard Desktop Player application, see Safeguard Desktop Player User Guide.

Caution:

Even though the SPS web interface supports Internet Explorer and Microsoft Edge in general, to replay audit trails you need to use Internet Explorer 11, and install the Google WebM Video for Microsoft Internet Explorer plugin. If you cannot install Internet Explorer 11 or another supported browser on your computer, use the the Safeguard Desktop Player application. For details, see Replaying audit trails in your browser in Search (classic) and Safeguard Desktop Player User Guide.

To replay an audit trail in your browser, complete the following steps.

Steps:
  1. On the Search > Search page, find the audit trail you want to replay.

    Figure 205: Search > Search — Browse the connections database

  2. Optional step: To replay encrypted audit trails, upload your permanent or temporary keys to the User menu > Private keystore. For more information, see Replaying encrypted audit trails in your browser.

  3. Click to display the details of the connection.

  4. Click to generate a video file from the audit trail that you can replay. Depending on the load of the indexer and the length and type of the audit trail, this can take several minutes (to cancel processing the audit trail, click ). The Video status field shows the progress of the this process.

    When the video is available, changes to .

    Figure 206: Search > Search — Audit trail details

  5. To replay the video, click . The Player window opens.

  6. The Player window has the following controls.

    Figure 207: Replaying audit trails in your browser

    1. : Play, Pause

    2. , : Jump to previous event, Jump to next event

    3. : Adjust replay speed

    4. : Time since the audit trail started / Length of the audit trail. Click on the time to show the date (timestamp) of the audit trail.

    5. : List of keyboard events. Special characters like ENTER, F1, and so on are displayed as buttons. If the upstream traffic is encrypted, upload your permanent or temporary keys to the User menu > Private keystore to display the keyboard events.

    6. : Active mouse button

    7. : Create a screenshot

    8. : Show / hide events. Select the types of events to display. Depending on the protocol used and how the audit trail was processed, SPS can display keyboard events, commands, mouse events, and window titles. Commands and window titles are displayed as subtitles at the top of the screen.

    9. : Fullscreen mode

    10. : Progress bar

    11. : Shows the distribution of events. Blue - commands, green - keyboard events, yellow - mouse events, orange - window title.

    12. : Close the player, and return to the Connection details page.

Replaying encrypted audit trails in your browser

Purpose:

To view screenshots generated for encrypted audit trails, and replay encrypted audit trails in your browser, you have to upload the necessary certificates and corresponding private keys to your private keystore. Depending on the encryption, decrypting the upstream part of an audit trail might require an additional set of certificates and keys.

Only RSA keys (in PEM-encoded X.509 certificates) can be uploaded to the private keystore.

NOTE:

Certificates are used as a container and delivery mechanism. For encryption and decryption, only the keys are used.

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

For more information on audit trail encryption, see Encrypting audit trails.

You can upload certificates permanently or temporarily. The temporary certificates are deleted when you log out of SPS.

The certificates and private keys in your keystore can be protected with a passphrase. To use the certificates and private keys in a passphrase-protected keystore for decrypting audit trails, you have to unlock the keystore first by providing the security passphrase. The keystore then remains unlocked for the duration of your session.

Steps:
  1. Click on User menu > Private keystore.

    Figure 208: User menu > Private keystore — The private keystore

  2. Optional step: Create a security passphrase, if you have not configured one yet.

    1. In Security passphrase, click Change.

    2. In the New field, enter your new security passphrase. Repeat the same passphrase in the Confirm field.

      NOTE:

      SPS accepts passwords that are not longer than 150 characters. The following special characters can be used: !"#$%&'()*+,-./:;<=>?@[\]^-`{|}

    3. Click Apply.

    If you forgot your security passphrase, contact our Support Team.

  3. Click to add a new certificate.

    Figure 209: Adding certificates

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

    Figure 210: Uploading certificates

  5. Select Browse, select the file containing the certificate, and click Upload. Alternatively, you can also copy-paste the certificate into the Certificate field and click Set.

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

    Figure 211: Uploading the private key

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

  8. To add more certificate-key pairs, click and repeat the steps above.

  9. To finish uploading certificates and keys to your private keystore, click Apply.

Using the content search

To most effectively search in the contents of the audit trails, make sure that the following prerequisites are met:

  • Indexing was enabled in the connection policy related to the audit trail during the session, and

  • the audit trail has already been indexed.

If the previous prerequisites are met, you can use the following in content search:

  • wildcards

  • boolean expressions

  • search in the commands of terminal connections (for example, command:"sudo su")

  • search in the window titles of graphical connections (for example, title:settings)

The following sections provide examples for different search queries.

For details on how to use more complex keyphrases that are not covered in this guide, see the Apache Lucene documentation.

Searching for exact matches

By default, SPS searches for keywords as whole words and returns only exact matches. Note that if your search keywords include special characters, you must escape them with a backslash (\) character. For details on special characters, see Searching for special characters. The following characters are special characters: + - & | ! ( ) { } [ ] ^ " ~ * ? : \ /

Example: Searching for exact matches
Search expression example
Matches example
Does not match

examples

example.com

query-by-example

exam

To search for an exact phrase, enclose the search keywords in double quotes.

Search expression on the web interface "example command"
Search expression on the REST API %22example%20command%22
Matches example command
Does not match

example

command

example: command

To search for a string that includes a backslash characters, for example, a Windows path, use two backslashes (\\).

Search expression on the web interface C\:\\Windows
Search expression on the REST API C%5C%3A%5C%5CWindows
Matches

C:\Windows

Combining search keywords

You can use boolean operators – AND, OR, NOT, and + (required), – to combine search keywords. More complex search expressions can also be constructed with parentheses. If you enter multiple keywords,

Example: Combining keywords in search
Search expression on the web interface keyword1 AND keyword2
Search expression on the REST API keyword1%20AND%20keyword2
Matches (returns hits that contain both keywords)
Search expression on the web interface keyword1 OR keyword2
Search expression on the REST API keyword1%20OR%20keyword2
Matches (returns hits that contain at least one of the keywords)
Search expression on the web interface "keyword1 keyword2" NOT "keyword2 keyword3"
Search expression on the REST API %22keyword1%20keyword2%22%20NOT%20%22keyword2%20keyword3%22
Matches (returns hits that contain the first phrase, but not the second)
Search expression on the web interface +keyword1 keyword2
Search expression on the REST API %2Bkeyword1%20keyword2
Matches (returns hits that contain keyword1, and may contain keyword2)

To search for expressions that can be interpreted as boolean operators (for example: AND), use the following format: "AND".

Example: Using parentheses in search

Use parentheses to create more complex search expressions:

Search expression on the web interface (keyword1 OR keyword2) AND keyword3
Search expression on the REST API %28keyword1%20OR%20keyword2%29%20AND%20keyword3
Matches (returns hits that contain either keyword1 and keyword3, or keyword2 and keyword3)
Using wildcard searches

You can use the ? and * wildcards in your search expressions.

Example: Using wildcard ? in search

The ? (question mark) wildcard means exactly one arbitrary character. Note that it does not work for finding non-UTF-8 or multibyte characters. If you want to search for these characters, the expression ?? might work, or you can use the * wildcard instead.

You cannot use a * or ? symbol as the first character of a search.

Search expression on the web interface example?
Search expression on the REST API example%3F
Matches

example1

examples

example?

Does not match

example.com

example12

query-by-example

Search expression on the web interface example??
Search expression on the REST API example%3F%3F
Matches

example12

Does not match

example.com

example1

query-by-example

Example: Using wildcard * in search

The * wildcard means 0 or more arbitrary characters. It finds non-UTF-8 and multibyte characters as well.

Search expression on the web interface example*
Search expression on the REST API example%2A
Matches

example

examples

example.com

Does not match

query-by-example

example*

Example: Using combined wildcards in search

Wildcard characters can be combined.

Search expression on the web interface ex?mple*
Search expression on the REST API ex%3Fmple%2A
Matches

example1

examples

example.com

exemple.com

example12

Does not match

exmples

query-by-example

Searching for special characters

To search for the special characters, for example, question mark (?), asterisk (*), backslash (\) or whitespace ( ) characters, you must prefix these characters with a backslash (\). Any character after a backslash is handled as character to be searched for. The following characters are special characters: + - & | ! ( ) { } [ ] ^ " ~ * ? : \ /

Example: Searching for special characters

To search for a special character, use a backslash (\).

Search expression on the web interface example\?
Search expression on the REST API example%5C%3F
Matches

example?

Does not match

examples

example1

To search for a string that includes a backslash characters, for example, a Windows path, use two backslashes (\\).

Search expression on the web interface C\:\\Windows
Search expression on the REST API C%5C%3A%5C%5CWindows
Matches

C:\Windows

To search for a string that includes a slash character, for example, a UNIX path, you must escape the every slash with a backslash (\/).

Search expression on the web interface \/var\/log\/messages
Search expression on the REST API %5C%2Fvar%5C%2Flog%5C%2Fmessages
Matches

/var/log/messages

Search expression on the web interface \(1\+1\)\:2
Search expression on the REST API %5C%281%5C%2B1%5C%29%5C%3A2
Matches

(1+1):2

Searching in commands and window titles

For terminal connections, use the command: prefix to search only in the commands (excluding screen content). For graphical connections, use the title: prefix to search only in the window titles (excluding screen content). To exclude search results that are commands or window titles, use the following format: keyword AND NOT title:[* TO *].

You can also combine these search filters with other expressions and wildcards, for example, title:properties AND gateway.

Example: Searching in commands and window titles
Search expression on the web interface command:"sudo su"
Search expression on the REST API command%3A%22sudo+su%22
Matches

sudo su as a terminal command

Does not match sudo su in general screen content
Search expression on the web interface title:settings
Search expression on the REST API title%3Asettings
Matches

settings appearing in the title of an active window

Does not match settings in general screen content

To find an expression in the screen content and exclude search results from the commands or window titles, see the following example.

Search expression on the web interface properties AND NOT title:[* TO *]
Search expression on the REST API properties%20AND%20NOT%20title%3A%5B%2A%20TO%20%2A%5D
Matches

properties appearing in the screen content, but not as a window title.

Does not match properties in window titles.

You can also combine these search filters with other expressions and wildcards.

Search expression on the web interface title:properties AND gateway
Search expression on the REST API title%3Aproperties%20AND%20gateway
Matches

A screen where properties appears in the window title, and gateway in the screen content (or as part of the window title).

Does not match

Screens where both properties and gateway appear, but properties is not in the window title.

Searching for fuzzy matches

Fuzzy search uses the tilde ~ symbol at the end of a single keyword to find hits that contain words with similar spelling to the keyword.

Example: Searching for fuzzy matches
Search expression on the web interface roam~
Search expression on the REST API roam%7E
Matches

roams

foam

Proximity search

Proximity search uses the tilde ~ symbol at the end of a phrase to find keywords from the phrase that are within the specified distance from each other.

Example: Proximity search
Search expression on the web interface "keyword1 keyword2"~10
Search expression on the REST API %22keyword1%20keyword2%22%7E10
Matches (returns hits that contain keyword1 and keyword2 within 10 words from each other)
Adjusting the relevance of search terms

By default, every keyword or phrase of a search expression is treated as equal. Use the caret ^ symbol to make a keyword or expression more important than the others.

Example: Adjusting the relevance of search terms
Search expression on the web interface keyword1^4 keyword2
Search expression on the REST API keyword1%5E4%20keyword2
Matches (returns hits that contain keyword1 and keyword2, but keyword1 is 4-times more relevant)
Search expression on the web interface "keyword1 keyword2"^5 "keyword3 keyword4"
Search expression on the REST API %22keyword1%20keyword2%22%5E5%20%22keyword3%20keyword4%22
Matches (returns hits that contain keyword1 keyword2 and keyword3 keyword4, but keyword1 keyword2 is 5-times more relevant)

Connection metadata

SPS stores the following parameters about the connections:

  • Additional metadata: Data about the connection recorded by the different plugins of SPS, for example, when using an Authentication and Authorization plugin.

  • Alerting: The list of content policy alerts triggered in the connection. For every alert, the following information is displayed:

    • Time of alert: Date and time of the alert

    • Alerting type: The type of the event (command, screen content, and so on).

    • Matched rule value: The expression that matched the content.

    • Matched context: Click this column to display the context of the matched content, for example, the contents of the screen, or the command line. The value that triggered the alert is highlighted.

    For example, a content policy that detects every execution of the sudo command in SSH commands, creates the following entry: 2012-10-05 15:46:17.902004: (adp.event.command) 'sudo'

  • Application: The name of the application accessed in a seamless Citrix ICA connection.

  • Archive date: The date when the connection was archived or cleaned up.

  • Archive path: The path where the audit trail was archived on the remote server.

  • Archive server: The hostname or IP address of the remote server where the audit trail was archived.

  • Audit trail downloads: An audit trail has been downloaded.

  • Audit-trail: Name and ID of the audit file storing the traffic of the channel. If the session has an audit trail, a icon is displayed. Note that a the following letters may appear on the download icon:

    • C: The audit trail has been cleaned up and is not available any more.

    • A: The audit trail has been archived. SPS will try to retrieve it from the archive server.

    • X: The audit trail is not available for some reason.

    You can filter the Audit-trail column for the following values:

    • no audit trail: Channels that have no audit trails.

    • has audit trail: Channels that have audit trails.

    • online: Channels that belong to an active, ongoing connection. If you are auditing every connection, then this list shows the connections also shown on the Active Connections page.

    • archived: Channels that had their audit trails archived to a remote server, but SPS cannot access the audit trail.

  • Authentication method: The authentication method used in the connection. For example, password

  • Channel policy: The Channel policy applied to connection. The Channel policy lists the channels (for example, terminal session and SCP in SSH, or Drawing and Clipboard in RDP) that can be used in the connection, and also determines if the channel is audited or not. The Channel policy can also restrict access to each channel based on the IP address of the client or the server, a user list, user group, or a time policy.

  • Channel type: Type of the channel.

  • Channel's indexing status: Shows if the channel has been indexed. The following values are possible:

    • Connection is active (0): The connection of the channel is still open (indexer is waiting for the connection to close).

    • Not indexed (1): All channels of the connection have been closed which belong to the connection. The channel is ready for indexing, unless the audit trail was placed in the skipped_connections queue.

    • Indexing in progress (2): The channel is being indexed (indexing in progress). Note that SPS will return search results for the parts of the channel are already indexed.

    • Indexed (3): Indexing the channel is complete.

    • Indexing not required (4): Indexing not required (indexing is not enabled for the connection).

    • Indexing failed (5): Indexing failed. The indexer service writes the corresponding error message in the error_message column of the indexer_jobs table. Note that SPS will return search results for the parts of the channel that were successfully indexed before the error occurred. For example, if the error occurred at the end of a long audit trail, you can still search for content from the first part of the audit trail.

    • No trail (6): Auditing is not enabled for the channel.

  • Client X.509 Subject: The client's certificate in TELNET or VNC sessions. Available only if the Client-side transport security settings > Peer certificate validation option is enabled in SPS.

  • Connection policy ID: The identifier of the connection policy.

  • Connection policy: The connection policy that handled the client's connection request.

  • Destination IP: The IP address of the server as requested by the client.

  • Destination port: The port number of the server as requested by the client.

  • Device name: The name or ID of the shared device (redirect) used in the RDP connection.

  • Duration: The length of the session.

  • Dynamic channel: The name or ID of the dynamic channel opened in the RDP session.

  • End time: Date when the channel was closed.

  • Events: A table that shows the commands that the user issued in a terminal session. These commands are searchable, together with the command prompt itself. Available only for Telnet and SSH session shell connections, if the audit trail has been indexed. For details on configuring indexing, see Indexing audit trails.

  • Exec command: The command executed in a Session exec channel.

  • File operations: The list of file operations (for example, file upload, create directory) performed by the client. Available only for SCP and SFTP sessions (Session exec SCP and Session SFTP SSH channels) if the Log file transfers to database option is enabled in the Channel Policy of the connection.

    For both SCP and SFTP connections, the filename is stored in a human-readable way if it only includes UTF-8-encoded characters. If the filename is not a valid UTF-8-encoded filename, the non-ASCII characters are translated into their hexadecimal equivalents. In both cases, the asterisk (*) characters are escaped with another asterisk (*) character.

    In case of a valid UTF-8-encoded filename:
    • Filename: ár*víz**

    • Hexadecimal sequence: C3 A1 72 2A 76 C3 AD 7A 2A 2A

    • Stored in connection database as: ár**víz****

    In case of a not valid UTF-8-encoded filename:
    • Filename: ár*víz** in ISO-8859-2

    • Hexadecimal sequence: E1 72 2A 76 ED 7A 2A 2A

    • Stored in connection database as: *e1r**v*edz****

    NOTE:

    For SFTP connections, this field includes the path and the filename. For SCP connections, it includes only the filename, the path is available in the SCP Path field.

    Windows and UNIX systems use different separator characters in the pathname, backslash (\) and slash (/), respectively. As the SCP and SFTP protocols do not specify the separator character used, SPS uses slash (/), for example, /var/log/messages.

    TIP:

    Use the filter in the header of the column to find sessions containing a specific file (for example, enter .gz to list sessions that accessed files with the .gz extension). Note that currently it is possible to search only in the filename and path, and not in the changed privileges.

  • Four-eyes authorizer: The username of the user who authorized the session. Available only if 4-eyes authorization is required for the channel. For details on 4-eyes authorization, see Configuring four-eyes authorization.

  • Four-eyes description: The description submitted by the authorizer of the session.

  • Hits and rank: Available only for indexed trails, when searching the content of the audit trails. This column is displayed automatically.

    • For channels indexed with the indexer service, displays the number of hits (search results) found in the audit trail, and the rank (relevance) of the audit trail regarding the search keywords. Rank is displayed as 1-5 stars. Hits is returned as a number for up to 100 results in the audit trail — the exact number of hits is not displayed if it is higher than 100.

    • For channels indexed with the Audit Player indexer service, rank is not available. The exact number of hits is not displayed, only that the search keywords were found in the trail at least once. In this case, the Hits and rank column displays 1+.

    Note that because of performance reasons, the number of hits can be inaccurate and is only an approximation. In this case, SPS displays a tilde (~) sign to mark approximated hit counts.

  • Port-forward target IP: The traffic was forwarded to this IP address in Remote Forward and Local Forward channels.

  • Port-forward target port: The traffic was forwarded to this port in Remote Forward and Local Forward channels.

  • Port/X11 forward originator IP: The IP address of the host initiating the channel in Remote Forward and Local Forward channels. Note that this host is not necessarily the client or the server of the SSH connection.

  • Port/X11 forward originator port: The number of the forwarded port in Remote Forward and Local Forward channels.

  • Protocol: The protocol used in the connection (Citrix ICA, HTTP, RDP, SSH, Telnet, or VNC).

  • Rule number: The number of the line in the Channel policy applied to the channel.

  • SCP path: Name and path of the file copied via SCP. Available only for SCP sessions (Session exec SCP SSH channels) if the Log file transfers to database option is enabled in the Channel Policy of the connection.

    NOTE:

    This field includes only the path, the filename is available in the File Operations field.

    Windows and UNIX systems use different separator characters in the pathname, backslash (\) and slash (/), respectively. As the SCP and SFTP protocols do not specify the separator character used, SPS uses slash (/), for example, /var/log/messages.

  • Server IP: The IP address of the server connected by SPS.

    NOTE:

    In case of HTTP, this is the target IP of the first request of the session, since it cannot be guaranteed that all page content come from the same server.

  • Server-local IP: The IP address of SPS used in the server-side connection.

  • Server-local port: The port number of SPS used in the server-side connection.

  • Server port: The port number of the server connected by SPS.

  • Session ID:

    A globally unique string that identifies the session. This session ID has the following format: svc/<unique-random-hash>/<name-of-the-connection-policy>:<session-number-since-service-started>/<protocol>, for example, svc/5tmEaM7xdNi1oscgVWpbZx/ssh_console:1/ssh.

    Log messages related to the session also contain this ID. For example:

    2015-03-20T14:29:15+01:00 scbdemo.balabit 
    zorp/scb_ssh[5594]: scb.audit(4): 
    (svc/5tmEaM7xdNi1oscgVWpbZx/ssh_console:0/ssh):
    Closing connection; connection='ssh_console', 
    protocol='ssh', connection_id='409829754550c1c7a27e7d', 
    src_ip='10.40.0.28', src_port='39183',
    server_ip='10.10.20.35', server_port='22', 
    gateway_username='', remote_username='example-username', 
    verdict='ZV_ACCEPT'
    			
  • Source IP: The IP address of the client.

  • Source port: The port number of the client.

  • Start time: Date when the channel was started.

  • Subsystem name: Name of the SSH subsystem used in the channel.

  • URLs: The list of URLs accessed in an HTTP session (the list is displayed in a pop-up window).

  • Unique connection ID: The unique identifier of the connection.

  • Username: The username used in the session.

    • If the user performed inband gateway authentication in the connection, the field contains the username from the gateway authentication (gateway username).

    • Otherwise, the field contains the username used on the remote server.

  • Username on server: The username used to log in to the remote server. This username can differ from the client-side username if usermapping is used in the connection. For details on usermapping, see Configuring usermapping policies.

  • Verdict: Indicates what SPS decided about the channel.

    • ACCEPT: Accepted.

    • ACCEPT-TERMINATED: Connection was accepted and established, but a content policy terminated the connection. For details on content policies, see Real-time content monitoring with Content Policies.

    • CONN-AUTH-FAIL: User authentication failed.

    • CONN-DENY: Connection rejected.

    • CONN-FAIL: Connection failed, that is, it was allowed to pass SPS but timed out on the server.

    • CONN-GW-AUTH-FAIL: Gatway authentication failed.

    • CONN-KEY-ERROR: Hostkey mismatch.

    • CONN-USER-MAPPING-FAIL: Usermapping failed.

    • DENY: Denied.

    • FOUR-EYES-DEFERRED: Waiting for remote username.

    • FOUR-EYES-ERROR: Internal error during four-eyes authorization.

    • FOUR-EYES-REJECT: Four-eyes authorization rejected.

    • FOUR-EYES-TIMEOUT: Four-eyes authorization timed out.

    NOTE:

    The Verdict column only accepts capital letters.

    NOTE:

    The rejected (CONN-DENY) HTTP requests are collected into a session, to avoid having too many entries in the database (for example when the user visits a forbidden page, and reloads the page several times, only one session will be visible instead of all the separate requests). The denied sessions have timeout and session ID.

Related Documents