One Identity Safeguard for Privileged Sessions 6.2.0 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS) The Welcome Wizard and the first login Basic settings
Supported web browsers and operating systems 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 and cleanup Forwarding data to third-party systems Joining to One Identity Starling
User management and access control Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing 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 RDP-specific settings SSH-specific settings 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) RPC API 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) 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 LDAP user and group resolution in SPS

HTTP indexer configuration format

This section describes the configuration format and options of the HTTP indexer (that is, how and which fields of the HTTP audit trails are indexed). For details on how to customize HTTP indexing, see Customizing the indexing of HTTP traffic.

NOTE:

If you want to index HTTP POST messages, include the "application/x-www-form-urlencoded" Content-Type in the General > WhiteList list. The indexer will decode URL encoding (percentage encoding), and create key=value pairs from the form fields and their values. Note that in the values, the indexer will replace whitespace with the underscore (_) character. To avoid indexing sensitive information (for example, passwords from login forms), use the Form > Blacklist option.

HTTP indexer configuration options

General

Type: Top level item

Description: Determines which HTTP Content-Types are indexed. An HTTP message is indexed only if its Content-Type is listed in Whitelist and is not listed in Blacklist.

For example:

"General": {
            "Whitelist": ["text/.*", ".*json.*", "multipart/.*", "application/x-www-form-urlencoded"],
            "Blacklist": ["text/css", "application/javascript", "text/xslt", ".*xml.*"]
},
General (Whitelist)

Type: list

Description: The list of HTTP Content-Types to index. Every entry of the list is treated as a regular expression.

For example:

"Whitelist": ["text/.*", ".*json.*", "multipart/.*", "application/x-www-form-urlencoded"],
General (Blacklist)

Type: list

Description: The list of HTTP Content-Types that are not indexed. Every entry of the list is treated as a regular expression.

For example:

"Blacklist": ["text/css", "application/javascript", "text/xslt", ".*xml.*"]
Form

Type: Top level item

Description: Determines which fields are indexed in HTTP POST messages.

For example:

"Form": {
         "Blacklist": ["password", "pass"]
},

NOTE:

If you want to index HTTP POST messages, include the "application/x-www-form-urlencoded" Content-Type in the General > WhiteList list. The indexer will decode URL encoding (percentage encoding), and create key=value pairs from the form fields and their values. Note that in the values, the indexer will replace whitespace with the underscore (_) character. To avoid indexing sensitive information (for example, passwords from login forms), use the Form > Blacklist option.

Form (Blacklist)

Type: list

Description: The list of fields that are not indexed in HTTP POST messages (for example, when submitting forms, such as login forms). Every entry of the list is treated as a regular expression.

For example:

"Blacklist": ["password", "pass"]
Html

Type: Top level item

Description: Include this section in the configuration to process text/html messages. HTML tags are stripped from the text, and only their content is indexed (for example, <html><title>Title</title></html> becomes Title).

For example:

"Html": {
         "Attributes": ["href", "name", "value", "title", "id", "src"],
         "StrippedTags": ["script", "object", "style", "noscript", "embed", "video", "audio", "canvas", "svg"]
}
Html (Attributes)

Type: list

Description: The list of HTML attributes that extracted as key=value pairs and indexed. Note that in the values, the indexer will replace whitespace with the underscore (_) character, and decode URL encoding. For example:

"Attributes": ["href", "name", "value", "title", "id", "src"],

Note that for the content attribute of the meta name="description", meta name="keywords", meta name="author" and meta name="application-name" is always indexed.

For example, if an audit trail contains the following HTML:

<head>
    <meta name="description" content="Web page description">
    <meta name="keywords" content="HTML,CSS,XML,JavaScript">
    <meta name="author" content="OI SA">
    <meta charset="UTF-8">
</head>

Then the index will contain the following text:

description=Web_page_description keywords=HTML,CSS,XML,JavaScript author=OI_SA
Html (StrippedTags)

Type: list

Description: The list of HTML tags that are not indexed.

For example:

"StrippedTags": ["script", "object", "style", "noscript", "embed", "video", "audio", "canvas", "svg"]

Using the Search interface

This section provides an overview on how to use the Search interface. It describes how you can access the Search interface, lists the steps to take to search effectively, view the details of a connection, replay the audit trails, or export the search results as a comma-separated text file.

Prerequisites

Users need the Search privilege to access the Search interface.

NOTE:

Assigning the Search privilege to a user on the AAA > Access Control page, automatically enables the Search in all connections privilege, and grants the user access to every audit trail, even if the user is not a member of the groups listed in the Access Control option of the particular connection policy.

If you want users to access audit trails only for connections for which they are granted permission, see Assigning search privileges.

For information on configuring:

  1. To access the Search interface, navigate to Search.

    You can view sessions in a card, table or flow view.

    Click:

    • for the card view.

      Figure 210: Search — Card view

    • for the table view.

      Figure 211: Search — Table view

      Sessions are displayed sorted by date. For ongoing sessions, the Search interface is updated in real-time to always show the most up-to-date information.

    • for the flow view.

      Figure 212: Search — Flow view

      The flow view allows you to:

      • Quickly visualize the distribution of the sessions based on their various metadata, such as, client address, username, protocol, verdict, server address, and One Identity Safeguard for Privileged Analytics (SPA) score.

        The metadata of the sessions are presented as vertical bars and each bar represents the proportional value of the data.

        Example: Proportional data representation

        The Verdict column shows that most of the sessions failed, a large number were accepted, and the rest of the sessions fall into the category of AUTH_FAIL, and TERMINATED.

        Figure 213: Search > Flow view — proportional data representation

      • See at a glance the relationship between various metadata and identify patterns in user behavior.

        Example: Relationship between metadata

        You want to have an overview of activities where access was denied.

        A quick look at the Verdict column shows that there were several accesses where the authentication failed (AUTH_FAIL) and the lines from the AUTH_FAIL field point to several server addresses.

        Figure 214: Search > Flow view — relationship between metadata

      • Use it interactively to drill down further on information.

        To drill down on information, click on an item, then click Search.

        TIP:

        To exclude an item, press Ctrl while clicking the item.

        Example: Interactive drill down

        You want to investigate if there were any unusual activities. To take a closer look, in the Analytics Score column, click Unusual, then click Search.

        The flow view now only displays the unusual session activities. You can further narrow your search as required.

        Figure 215: Search > Flow view — interactive drill down

  2. To sort columns, from the card or table view, click the Sort by drop-down menu and select from the list.

    Figure 216: Search — Sort columns

    For example, to see the shortest session, select Duration from the list. Sessions are now sorted based on duration with the shortest session first. To see the longest session, click (ascending).

  3. Specify a date and time range to restrict your search criteria as described in Specifying time ranges.

  4. Filter connections as described in Using search filters.

  5. Search the contents of audit trails as described in Searching in the contents of audit trails.

  6. View connection details as described in Viewing session details.

  7. Download and replay audit trails as described in Replaying audit trails in your browser.

  8. To export the search results as a comma-separated text file, select Export CSV. Note that if your search returns more than 10.000 results, only the first 10.000 rows are exported. If you want to see all results, refine your search.

    To customize which fields are exported, select Export CSV ....

Search Permissions

The following describes how to assign users to access sessions only for connections for which they are granted permission.

Users need the Search privilege to access the Search interface.

Assigning the Search privilege to a user on the AAA > Access Control page, automatically enables the Search in all connections privilege, and grants the user access to every session, even if the user is not a member of the groups listed in the Access Control option of the particular connection policy.

Prerequisites

To assign users to access sessions only for connections for which they are granted permission

  1. Navigate to AAA > Access Control.
  2. Figure 217: AAA > Access Control — Configuring search privileges

    Assign the Search privilege to your usergroup as described in Assigning privileges to usergroups for the One Identity Safeguard for Privileged Sessions (SPS) web interface.

  3. Deselect the Search in all connections privilege so that users can access sessions only for connections for which they are granted permission.

  4. To grant permission to a specific connection, navigate to the Connections page of the traffic (for example to SSH Control > Connections), and select the connection policy to modify.

  5. Figure 218: <Protocol name> Control > Connections > Access Control — Configuring search privileges

    Navigate to Access Control and click .

  6. Enter the name of the usergroup whose members are permitted to access the Search interface into the Authorizer Group field. This group must exist on the AAA > Group Management page.

    Caution:

    Usernames, the names of user lists, and the names of usergroups are case sensitive.

  7. Set the permissions of the usergroup.

    • If the usergroup can authorize (that is, enable) and audit (that is, monitor in real-time and download the audit trails) the sessions, select Permission > Search&Authorize.

    • If the usergroup can only audit the sessions but cannot authorize, select Permission > Search.

    NOTE:

    If the Client user is > Member of field is set, the auditor can only monitor the sessions of the specified usergroup. However, if Client user is > Member of field is set, the Auditor cannot access the Search page. To avoid this problem, add another Access Control rule for the Authorizer Group without setting the Client user isfield.

    The admin user of One Identity Safeguard for Privileged Sessions (SPS) can audit and authorize every connection.

Result

Users with the relevant privileges can now access the sessions for which they are granted permission. If users do not have the required permission to access sessions, a warning message is displayed and no session is visible as shown below:

Figure 219: Search — Permission denied

Related Documents