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:
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:
SPS monitors and records the protocol traffic in the audited connections passing through SPS. Protocol traffic data is recorded in audit trail files.
Once a connection has been closed, SPS sends the audit trail files to the indexer.
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).
The indexer returns the information extracted from the parsed audit trail files to SPS.
SPS processes the outcome of parsing and OCR-ing done in the previous phase and makes the data searchable.
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.
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.
Microsoft provides mainstream and extended support periods for Windows Server 2012 Standard as described here. One Identity follows these periods and our best-effort support period starts at the same time when the mainstream period ends at Microsoft.
SPS supports the HTTP 1.0 and 1.1 standards.
SPS supports only the SSHv2 protocol. The older and insecure v1 version is not supported.
Supported client and server applications:
OpenSSH (client and server)
Client and server tested with a weekly build of the latest available version.
OpenSSH (client and server) with X.509 patch
Client and server tested with version OpenSSH_7.1p2 and OpenSSL 1.0.2f-fips 28 Jan 2016.
Dropbear (client and server)
Tested with version 2015.67.
SecureCRT (Windows, client)
Tested with version 7.3.4
Tested with version 0.65.
Supported Windows client applications:
The built-in applications of the Windows 7 SP1, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows 10 platforms.
Supported Mac OS X client applications:
The Royal TSX client application, tested with Royal TSX 2.0 on Mac OS X Yosemite.
Supported server (target) applications:
The built-in applications of Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 and Windows 10 platforms.
Accessing Remote Desktop Services (RemoteApp programs) is also supported.
Other Remote Desktop clients are not explicitly supported, but may be compatible with SPS. When using an alternative client application, note the following limitations:
SPS is certified for the following server versions:
Citrix Virtual Apps (formerly known as Citrix XenApp) 6.5
Citrix Virtual Apps 7.6
Citrix Virtual Apps 7.15
Citrix Virtual Desktops (formerly known as Citrix XenDesktop) 6.5
Citrix Virtual Desktops 7.6
Citrix Virtual Desktops 7.15
For details on the deployment scenarios that support Citrix Virtual Desktops (formerly known as Citrix XenDesktop), see SPS deployment scenarios in a Citrix environment.
The latest version of the Citrix Workspace app (formerly known as Citrix Receiver) for Windows, Linux and MacOS is supported.
Telnet traffic must conform RFC 854, and to various extensions described in RFCs 856-861, 652-658, 698, 726-27, 732-736, 749, 779, 885, 927, 933, 1041, 1043, 1053, 1073, 1079, 1091, 1096-97, 1184, 1372, 1408, 1572, 2066, 2217, 2840, 2941, and 2946.
TN3270: Telnet 3270 terminal protocol.
TN5250: Telnet 5250 terminal protocol, as described in RFC2877.
SPS can act as a Remote Desktop Gateway (also called RD Gateway) and transfer the incoming connections to RDP connections.
VNC versions 3.3-3.8 are supported. Supported client and server applications: RealVNC, UltraVNC, TightVNC, KVM, Vino.
VMware Horizon View Clients using the Remote Desktop (RDP) display protocol to access remote servers are supported. For details, see VMware Horizon View connections.
SPS can be configured to monitor both transparent and non-transparent connections.
In transparent mode, SPS acts as a transparent router between two network segments. For details, see Transparent mode.
You can also use policy-based routing to forward connections within the same network segment to SPS, in which case it acts like a single interface transparent router. For details, see Single-interface transparent mode.
In non-transparent mode, users have to address SPS to initiate connections to protected servers. For details, see Non-transparent mode.
When addressing SPS, you can also use inband destination selection to choose the server to connect to. For details, see Inband destination selection.
It is recommended to design the network topology so that only management and server administration traffic passes SPS. This ensures that the services and applications running on the servers are accessible even in case SPS breaks down, so SPS cannot become a single point of failure.
In transparent mode, SPS acts as a transparent router connecting the network segment of the administrators to the segment of the protected servers at the network layer (Layer 3 in the OSI model). All connections must pass through SPS to reach the servers — SPS is a proxy gateway, completely separating the protected servers from the rest of the network. Controlled connections and traffic are inspected on the application level, while other types of connections are simply forwarded on the packet level.
SPS can also be configured to act as a single-interface transparent router. For details, see Single-interface transparent mode.
Transparent mode does not support multicast traffic.
Figure 8: SPS in transparent mode