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

The search and filter process

The screen content is first indexed, then processed with the search backend, and finally, the filter expressions are applied. This process is described in detail in the following sections.

Figure 213: The search and filter process

Prerequisites - Indexing phase

First, as a prerequisite of the search process, screen content is indexed. The indexing phase generates a database that the search and filter processes will run on.

The indexer parses the contents of the audit trail files, and builds an "inventory" of the privileged user's activity data based on what appeared on their screen.

  1. In the case of a terminal session, screen content corresponds to the activity data that is captured in a terminal window. In the case of graphical protocols, screen content is whatever is visible in the graphical user interface of the applications the user is interacting with. In the latter case, the indexer's Optical Character Recognition (OCR) engine extracts text that appeared on the screen (for example, window titles).

    NOTE:

    If a piece of text is displayed for less than 1 second, it is not extracted.

  2. The indexer returns the information extracted from the parsed audit trail files to SPS. In the case of a terminal session, the captured text is put in the backend database as one document per one second of screen content. Because of this, the content that you have searched for might only partially appear in the screenshot. In the case of graphical protocols, the captured text is put in the backend database as one document per screenshot.

  3. The queries will be run on this database during the search process.

For details on indexing, see Indexing audit trails.

Search and filter process phases

The search and filter process consists of three major phases:

  • Query phase

  • Grouping phase

  • Filter phase

Query phase:

In the query phase, the backend ranks and then limits the number of results.

  1. The result of one query is the top 3000 documents, ordered by the default ranking system of the backend.

    This means that if there are more than 3000 results, those of the lowest rank will not be passed to the next phase at all.

    The ranking system cannot be modified, so there is no way to "upvote" those results of lower ranks.

    If you want to ensure that all important results are passed to the grouping phase, use a smaller time range that you run the query on. If there are fewer than 3000 results, it is certain that the events you are interested in will be included in the grouping phase.

  2. The grouping phase receives the results.

Grouping phase:

The grouping phase groups the results that were passed on from the query phase.

  1. First, the results with the same trail IDs are grouped together. A trail ID group contains all search hits that are in that trail.

  2. The trail ID groups are then further grouped by seach expression and time range. This group is essentially the time range during which the expression is displayed on the screen (for example, if the text root is displayed from 00:00:12 to 00:01:45, this will be one group).

  3. This grouped result is displayed in the search screen as one row.

Filter phase:

The filter phase applies filter expressions to these grouped results.

NOTE:

If there were screen content search results that were excluded during the query phase, the filter expressions will not be applied to them.

Example: Filtering for search results that were excluded in the query phase

For example, if you want to filter for Telnet connections where the text root was displayed, the following can happen:

You search for the Screen content: root. There are 3100 search results that consist of 3050 SSH connections and 50 Telnet connections. In this example, Telnet connections received the lowest ranks for some reason. 100 results that have received the lowest rank are excluded, and in this example it means all Telnet connections.

If you filter for protocol Telnet now, you will not see any results.

To remedy this situation, try searching in a smaller time range to make sure that there are less than 3000 search results. If you are unsure about the time range, you might want to attempt fine-tuning the backend search manually. For details, see: Fine-tuning the backend search manually.

Fine-tuning the backend search manually

You can fine-tune your search manually with the command line utility lucenectl. To do this, log on to the core shell. For details, see Accessing the SPS console.

  • Specify more exact time ranges (use Unix timestamps).

    For example, to limit the time range to Thursday, June 30, 2016 11:39:51 AM - Thursday, November 3, 2016 2:44:46 PM, enter the following command:

    lucenectl search --from-to 1467286791 1478184286 --text remote --limit 3000 --aggregate-by-trail --normalize-rank

    NOTE:

    For converting timestamps to Unix timestamp, use https://www.epochconverter.com/.

  • Increase the query limit of 3000 to a limit of your choice.

    For example, to increase the query limit of 3000 to 4500, enter the following command:

    lucenectl search --from-to 1467286791 1478184286 --text <your-screen-content-search-expression> --limit 4500 --aggregate-by-trail --normalize-rank
    lucenectl search --from-to 1467286791 1478184286 --text remote --limit 4500 --aggregate-by-trail --normalize-rank

    NOTE:

    If you do not receive more results with a larger query limit, it means that you have found all results with your search expression.

However, the downside of using lucenectl to fine-tune your search is that after the cli search, you have to manually extract the trails that you find interesting with the help of the metadb.

The following example shows the output of a lucenectl search:

{
 "hits": [
   {
     "hits_count": 1,
     "channel_id": 1,
     "trail_id": "58",
     "rank": 0.4068610216585047
   },
   {
     "hits_count": 7,
     "channel_id": 761,
     "trail_id": "12",
     "rank": 1.0
   },
   {
     "hits_count": 2,
     "channel_id": 1,
     "trail_id": "139",
     "rank": 0.5923645275802537
   }
 ]
}
  • rank: the larger the number, the higher the rank

  • hits_count: the number of times the screen content search expression is displayed in the audit trail

  • trail_id: the ID of the trail

  • channel_id: the ID of the channel

The most relevant audit trail will probably be the one with the highest rank.

If you have determined which audit trail you are interested in, enter the following command. The value of _connection_channel_id will be the value of the trail_id from the lucenectl output that you have determined as most relevant.

psql -U scb scb -c "select audit from channels where _connection_channel_id = 12;"

The output of this command will be:

/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:2
/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:1

From this output, the audit trail file name path is as follows: /<audittrailpath>/audit-scb_rdp-1467274538-0.zat

NOTE:

If you cannot find the file at the path, try to enter the following command to check whether it has been archived and search for the file in the archive path:

psql -U scb scb -c "select audit, _archive_path  from channels where _connection_channel_id = 12;"

The output of this command will be:

                    audit                                | _archive_path
---------------------------------------------------------+---------------
/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:2 | /<myarchive/path>/
/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:1 | /<myarchive/path>/
                                                         | 

If you still cannot find the audit trail, contact our Support Team.

Viewing connection details

The session info window provides in-depth information on each of the indexed audit trail stored in the connection database. You can use it to gain contextual insight about the indexed session and its events.

Access the session info window in the following ways:

  • Double-click on an empty area of the relevant audit trail.

  • Click the button in the last column of the relevant audit trail.

    Alternatively, in the card view, click .

    Figure 234: Search > Search — Accessing connection details

The session info window is displayed:

Figure 235: Audit trail details

The session info window provides details about the sessions on tabs.

overview tab:

The overview tab is divided into the following main areas:

  • The Events area displays connection events in chronological order.

    View the date and time of the event, the event type and event details. To filter events, use the events tab.

  • The Quick look area contains user information, for example, gateway and server username, start and end time of the connection, and so on.

    The gateway username corresponds to the Username field of the connection metadata database, so note the following:

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

  • The Interesting events area displays events selected as interesting, for example, a list of commands and window titles from the session that could be interesting from a security point of view.

  • The Network area displays connection information, for example, connection verdict, protocol, connection policy, client and server address.

details tab:

In addition to the Quick look, Interesting events, and Network screen areas, the details tab provides monitoring information and channels information, too.

events tab:

The events tab displays the:

  • Connection events in chronological order.

    You can narrow the event list by entering the event name in the Filter events field.

  • Date and time of the event.

  • Event type (command, screen content, window title).

  • Event details.

contents tab:

Screenshots are generated for search results and alerts when the trail is opened, and for subsequent searches. You can scroll between screenshots using the carousel, and view each screenshot in full size. Selecting a screenshot highlights the corresponding search result or alert.

Screenshots are not available for:

  • Ongoing connections.

  • Unindexed trails.

  • Trails of HTTP connections.

  • Encrypted trails (without the necessary certificate).

NOTE:

For SSH and Telnet trails, trail data is aggregated for each second. The screenshot you see reflects the terminal buffer as it was visible at the end of that second. If data was pushed off-screen during this second, the search still finds it, but it will not be visible on the generated screenshot.

analytics tab:

If you use the Privileged Account Analytics, you can view detailed analyses provided by the configured algorithms. For more information, see Analyzing data using One Identity Safeguard for Privileged Analytics.

Viewing active connections

If a connection is not closed and is still active, the label is displayed in the session info window.

To close an active connection, click the label.

You can also view the live connection as follows:

  1. Click the label.

  2. Download the audit trail.

    Trail data is exported in .srs format, which you can open with the Safeguard Desktop Player application.

    For more information on the Safeguard Desktop Player, see Safeguard Desktop Player User Guide.

Replaying audit trails in your browser

Purpose:

This section describes how you can create and replay an audit trail in your browser.

Prerequisite:

If you want to replay encrypted audit trails, use the Search (classic) interface to upload your permanent or temporary keys to the User menu > Private keystore. For more information, see Replaying encrypted audit trails in your browser.

After you have finished uploading certificates and keys to your private keystore using the Search (classic) interface, you can use the Search or the Search (classic) interface to view and replay encrypted audit trails.

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.

  2. Click to display the details of the connection.

    Alternatively, in the card view, click .

  3. Click to generate a video file from the audit trail you want to replay. Depending on the load of the indexer and the length and type of the audit trail, this can take several minutes.

    When the video is available, changes to and . You can use the button if you want to remove the generated video. After you remove the video file, the button is available and you can use it to recreate the video file.

  4. To replay the video, click .

    The Player window opens.

    Figure 236: Replaying audit trails in your browser

    TIP:

    You can quickly zoom in or out by clicking anywhere in the Player window.

    The Player window has the following controls:

    • : Play, Pause

    • , : Jump to previous event, Jump to next event

    • : Adjust replay speed

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

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

    • : Active mouse button

    • : Create a screenshot

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

    • : Fullscreen mode

    • : Progress bar

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

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

Handling encrypted audit trails

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.

To upload the certificates and corresponding private keys to your private keystore, use the Search (classic) interface.

After you have finished uploading certificates and keys to your private keystore using the Search (classic) interface, you can use the Search or the Search (classic) interface to view and replay encrypted audit trails.

For more information, see Replaying encrypted audit trails in your browser.

Related Documents