One Identity Safeguard for Privileged Sessions 6.0.6 - Administration Guide

Credential Stores

Credential Stores are repositories of user credentials (for example, passwords, private keys, certificates). They are used for authenticating a user to the target server that the user wishes to access, without the user actually having access to those credentials. Credentials are retrieved transparently from One Identity Safeguard for Privileged Sessions's (SPS's) local Credential Store or an external, third-party password management system by SPS impersonating the authenticated user. This automatic password retrieval is crucial, as this method protects the confidentiality of passwords since users can never access them.

Users accessing connections that use Credential Stores must authenticate on SPS using gateway authentication. They only have to use their gateway password to log in to SPS, and if they are allowed to access the target server, SPS automatically logs in using the Credential Store. For details on gateway authentication, see The gateway authentication process.

Figure 5: Authenticating using Credential Stores

Credential Stores can be stored locally on SPS, or on a remote device. For remote Credential Stores, SPS integrates with external authentication and authorization systems using plugins.

For further information on Credential Stores including configuration details, see Using credential stores for server-side authentication.

Plugin framework

One Identity Safeguard for Privileged Sessions (SPS) provides a plugin framework to integrate SPS with external authentication and authorization systems, such as an external Credential Store, a ticketing system, or any third-party authentication or authorization solution.

Authenticating users to an external authentication and authorization system and the process overview that follows describe how user authentication works at a high level when there is an external authentication and authorization system involved:

Figure 6: Authenticating users to an external authentication and authorization system

1. The client tries to establish a connection to the target server.

2. SPS notices that an AA plugin is configured in the connection policy matching the connection. This is treated as gateway authentication. For details on gateway authentication, see The gateway authentication process.

3. SPS prompts the client for credentials.

4. The client provides authentication details to SPS when prompted.

5. SPS forwards the client's details to the external authentication and authorization system using the SPS API.

6. The external authentication and authorization system verifies the data received and provides feedback to SPS about the result.

7. If the client is granted access by the external authentication and authorization system, SPS authenticates the client to the target server, and establishes the connection.

For further information on plugins including configuration details, see Integrating ticketing systems and Integrating external authentication and authorization systems.

Indexing

One Identity Safeguard for Privileged Sessions (SPS) can index the contents of audit trails, making the records of privileged users' activities easily searchable.

Audit trails contain user activity data recorded from terminal sessions (such as SSH and Telnet) and graphical protocols (such as RDP, Citrix ICA, and VNC). Examples of data recorded in audit trails are: mouse activity, keystrokes, and so on. Using its own indexer service or one or more external indexers, SPS determines elements of the content visible on the user's screen at a given point in time. Screen content elements include commands, window titles, IP addresses, user names, and so on.

The indexer generates the following types of output as a result of processing the audit trail files:

• text

• screenshot files

• replayable video files

SPS then takes the output of indexing and breaks that down into searchable units.

Indexing audit trail files and the process overview that follows describe how indexing works at a high level:

Figure 7: Indexing audit trail files

1. SPS monitors and records the protocol traffic in the audited connections passing through SPS. Protocol traffic data is recorded in audit trail files.

2. Once a connection has been closed, SPS sends the audit trail files to the indexer.

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

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

4. The indexer returns the information extracted from the parsed audit trail files to SPS.

5. SPS processes the outcome of parsing and OCR-ing done in the previous phase and makes the data searchable.

6. Once indexed, the contents of the audit trails can be searched from SPS's web interface.

For details on how to configure SPS's internal indexer or one or more external indexers, see Indexing audit trails.

Supported protocols and client applications

One Identity Safeguard for Privileged Sessions (SPS) supports the following protocols and clients. As a general rule, client applications not specifically tested, but conforming to the relevant protocol standards, should work with SPS. One Identity supports the listed client and server applications only on a best-effort basis after their vendor or manufacturer declares end-of-support or extended (or any other non-standard support) period for them. Best-effort basis means that without the vendor support we only can fix issues with our existing knowledge in the problematic area, and can implement straightforward fixes only.