IAmDavid

Okta Privileged Access – Example Mechanisms to Export/View Session Recordings

Written by

iamdavid

in

, , ,

on

This article provides some example mechanisms that could be used to export and view the session recording files produced by Okta Privileged Access. There are two examples shown:

  1. A simple series of scripts that show the flow and commands to export and view logs, and
  2. An overview of a mechanism built by a former Okta employee to process Okta Privileged Access session recordings. It leverages an AWS S3 bucket and a custom web app to view the recordings. Note that this includes custom, and thus unsupported, components.

These are provided as examples to show how you could implement a mechanism.

Introduction

Okta Privileged Access (OPA) and it’s predecessor Okta Advanced Server Access (Okta ASA), can capture session recordings in the Gateway (subject to policy rules). These recordings are stored, but not processed further by OPA. In many cases, session recordings are only used for later forensic analysis and are not required to be accessed often, thus storing in a compressed format is the best option, allowing customers to decide what processes to wrap around using the files.

The recordings are stored as log files written as a base64 encoded binary file and signed to confirm that they haven’t been tampered with. The OPA client provides command options to decode (export) the files so that they can be viewed. As the OPA Gateway is a Linux server, and often without a UI, you can only view SSH recordings locally; RDP recordings need to be shipped somewhere that you can play back mkv format files.

Session Recording in OPA

Session Recording is a feature that’s been available in both Okta ASA and OPA for some time. It is often referred to a “Session Capture”. It stores the logs in a file on the gateway server (which could be an external drive locally mounted, like an S3 bucket) after a user session is finished. It does nothing further with the logs, but does provide commands to allow for bespoke processing on the log files.

OPA stores the logs in a raw Base64 encoded format that must be decoded (exported) using the OPA client. Note that it does not encrypt the logs.

OPA signs session logs to provide integrity. This prevents attackers from manipulating a log file to hide their actions. New signing keys are generated roughly every 24 hours. The OPA client can be used to verify the signature.

To review RDP session logs, you must Install RDP Transcoder.

Configuration of session recording involves:

  1. Mapping a gateway to the target servers in the Resource Group / Project
  2. Configuring a Policy / Rule to record sessions for a group of users connecting to a set of servers
  3. Configuring session recording on the gateway

The gateway configuration file, /etc/sft/sft-gatewayd.yaml, has configuration options for session recording.

This includes the LogDestinations option to tell the gateway where to write the sessions logs, which could be a local file (or mounted filesystem), AWS or GCS buckets. If extensive session recording is to be performed, you should consider where you will store the logs and how to manage them. You could easily consume a lot of local disk, particularly with RDP logs, and there’s no automatic cleanup of files. If this is a concern it would be advisable to store the logs on an external disk or cloud bucket.

Another point to note is that exporting RDP logs can be a CPU-intensive operation. You should ensure there is ample processing capacity on the gateway if you plan to export RDP logs there (or plan to ship the RDP logs to another server to export them. Wherever you plan to run the export command, you will need the OPA client installed.

A Simple Script-based Mechanism

The first approach is a simple series of scripts that can be run on the gateway to export and view (some) logs. The term session logs is used to mean the files that the gateway writes to disk. This is a trivial example that shows how commands could be used to export/view logs as per the Manage session logs doc page. It may not be the most secure or efficient way of doing it.

The scripts are:

The sequence of scripts is:

  1. List the SSH session logs that have been written by OPA
  2. Copy a session log to the local directory
  3. Convert the SSH session log to asciinema format
  4. Play the converted session log
  5. List the RDP session logs that have been written by OPA
  6. Copy a session log to the local directory
  7. Convert the RDP session log to mkv format

Note that the gateway is a Linux server and unless you have a UI and the relevant apps installed, you will not be able to view the graphical Windows recordings, only the text-based recordings.

Lets walk through them in more detail.

Exporting and Viewing SSH Session Logs

The first step (script) will list all ssh recordings in the location where the gateway writes them. 

sudo ls /var/log/sft/sessions | grep ^ssh

The output is a list of all ssh recordings, like

ssh~20241205T024708.3712~deadwoods-pam2~allServers~opa-demo-linux2~larry.linuxadmin~-1-6751142a-76d328f734c7cff842d72a1f.asa

The file format is defined in the gateway configuration file (sft-gatewayd.yaml).

The next step is to copy one of the files into the local directory. This is to set the permissions to work on it.

sudo cp /var/log/sft/sessions/$1 .
sudo chmod 777 $1
ls -ltr

The third step will use the OPA client (sft) to export the file. It’s passed the filename and writes the output in asciinema format to a file called exportedSessions.cast.

sft session-logs export --format asciinema $1 --output exportedSession.cast

This is the only step to require using the client. Obviously the client must be installed on to the gateway server and the user running the script needs to be able to run the session-logs command.

Exporting RDP Session Logs

Exporting the RDP session logs has a similar flow, to list the files, copy one into the local directory and set permissions. Then the sft session-logs export command is used.

sft session-logs export --format mkv --output ./rdpSessionExport $1

In this case the exported file is in mkv format and is stored in a sub-directory (./rdpSessionExport). This is because the files aren’t viewed locally, so this is where you could copy them from to a machine that can view them.

This completes the simple script-based mechanism.

Mechanism to Offload Logs to AWS S3 and An App to View Them

The previous example was a bare-bones example of just using basic scripts. The following example provides a more comprehensive approach. The mechanism was written by a former Okta employee and can be found at https://github.com/mrdanielmh/opa-utils.

Itt exports/converts the logs and stores them on a S3 bucket and provides a sample application that can be used to view the recordings as shown in the following figure.

The github page defines the installation/configuration, including:

  • Creating an Okta application (the one to view the logs) and assigning it to users
  • Deploying the app components into AWS, including creating the IAM definitions (roles), creating the S3 bucket, creating the Elastic Beanstalk app, mapping it to the Okta app definition and setting some parameters for it.
  • Setting up the Gateway, including assigning the new IAM role to the gateway instance, deploying the provided script (or similar), installing some software, configuring the S3 bucket as a mounted drive, creating a service to monitor for new session logs and configuring the gateway to write logs to the format the script is expecting.

The script will monitor a directory on the gateway (/var/log/sft/sessions) and when it detects a session log will run the appropriate sft session-logs export command and store the exported file onto the S3 bucket.

#!/bin/bash -x
#Watch for new session logs and convert them to asciinema (ssh) and mkv (rdp).
WATCHPATH="/var/log/sft/sessions"
DESTPATH="/mnt/aws/{bucketname}"
process-logs-ssh(){
sudo sft session-logs export --insecure --format asciinema --output "$DESTPATH"/"$file".cast "$WATCHPATH"/"$file"
}
process-logs-rdp(){
sudo sft session-logs export --insecure --format mkv --output "$DESTPATH"/"$file".mkv "$WATCHPATH"/"$file"
}
inotifywait -m "$WATCHPATH" -e create 2>/dev/null |
while read dirpath action file; do
    if [[ $file == *ssh~* ]]; then
            echo "ssh session capture found"
            echo "starting conversion process"
            process-logs-ssh
            echo "ssh session converted"
    elif [[ $file == *rdp~* ]]; then
            echo "rdp session capture found"
            echo" starting conversion process"
            process-logs-rdp
            echo "rdp session converted"
    else
            echo "skipping unknown file type $file"
    fi
done

With the exported session logs stored in S3, they can be accessed by the app (called OPA Utils or sometimes Advanced Server Access – Utilities).

Selecting a recording in the app will allow playback.

Note that this is an unsupported mechanism that was built in late 2022/early 2023. The session recording feature in Okta ASA and OPA has not changed since then, but YMMV.

Conclusion

Okta Privileged Access has a session recording capability for ssh and rdp sessions. The OPA Gateway will record the sessions and write them to files (locally or on AWS/GCS buckets) where the customer can access them. This article has shown two examples of how those session recording files can be stored and accessed.