Part 6 · Operations
Access Reports
Module 1 named "approval and accountability" as one of the three ideas that repeat through this whole course. Reports are where accountability actually gets exercised: every session, every credential checkout, every Vault change, and every admin action leaves a record, and this module is about how to find, read, and export those records.
Why reporting is a first-class feature, not an afterthought
PRA reports "allow administrators and privileged users to generate comprehensive documentation on system activities, with the ability to apply filters for customized insights tailored to specific needs." That documentation is what turns "we grant privileged access" into "we can prove exactly who did what, to which system, and when" — the difference between a PAM tool and a plain remote-access tool. Reports track and analyze system usage, performance, and security metrics, and they exist specifically to support compliance, auditing, and decision-making.
Reports are accessed from the main menu under Privileged Remote Access > Reports, which opens on the Access tab by default. From there, separate tabs cover the other report families described below — Asset, Vendors, Vault, Syslog, and (if enabled) Compliance.
The three activity report types
From the Access tab, choosing a Report Type gives you three options: Session, Summary, and Session Forensics (if enabled). These are filtered by session ID, date range, endpoint, Asset Group, user, vendor group, or external key, then downloaded or shown on screen.
The Session report is the one you'll use most. It shows every access session matching your filters, with links into full session detail: chat transcripts, video recordings of screen sharing, Database Connections, and command shells; a record of files transferred (including failed transfers); and notable Windows events such as changes to the foreground window, captured with the executable name and window title. If a rep used Run As to inject credentials, the specific command information is logged too — though this level of command logging can be disabled from Security > manage security settings if your organization doesn't want credential-adjacent command text retained.
Session, Database Connection, and Command Shell recording are each separate checkboxes under Configuration > Options > Access Session Logging Options: Enable Screen Sharing Recording, Enable User Recording for TCP & IP Tunnel Database Connection, and Enable Command Shell Recording. Automatic Logging of System Information captures the endpoint's system info at session start (but never logs what the rep views on screen). None of this is retroactive — if a toggle was off during a session, that session has no recording to review later.
Session Forensics: searching inside recordings
Session Forensics is a separate, more expensive feature: it builds a search index across session events — chat messages, file transfers, registry editor events, and foreground-window-changed events — so an admin can search for a keyword and jump directly to the matching point in a recording. If Command Shell recording is enabled, forensics extends that search into shell recordings themselves: a keyword match queues the video to that exact timestamp. No command output or passwords are ever recorded as part of forensics search data. Because the index consumes real system resources, only enable it if you actually need search-inside-recordings; enabling it later requires the search index to be rebuilt, during which searches may return incomplete results. It is enabled by default on new sites.
Beyond sessions: the other report families
The Access/Session reports answer "what happened in this session." The other tabs on the Reports page answer different accountability questions — who has access, what changed in the Vault, and what's noisy or broken in the environment.
| Report | What it shows | Typical use case |
|---|---|---|
| Session | Per-session detail: chat transcript, screen/DB/shell recordings, file transfers, foreground-window events, Run As command detail | Investigate a specific incident or answer "what did this vendor actually do during that session?" |
| Summary | Aggregated session activity across the filtered date range/scope, without full per-session detail | Spot-check usage volume and trends without opening every session |
| Session Forensics | Keyword search across chat, file transfer, registry, window-change, and (if enabled) shell events, jumping straight to the matching timestamp | "Did anyone type this command / touch this file / open this app" across a large number of sessions |
| Asset | All Asset events — access history, user activity, associated session details — filterable by date range, Asset Group, Asset, and performed-by user | Audit who has been touching a specific server or Asset Group over time |
| Vendors | Activity and access history for third-party/vendor users specifically | Prove vendor access stayed within scope — the natural companion to Module 20's Vendor Groups |
| Vault | Privileged account activity: account creations/deletions, credential check-ins/check-outs, personal credential use, password rotations | Confirm credentials were checked out (not shared out-of-band) and rotation is happening on schedule |
| Duplicate Jump Clients | Active Jump Clients that appear more than once against the same endpoint, from a query against the Jump Client database | Reconcile Jump Client counts against license allotment and clean up orphaned installs |
| Compliance (opt-in feature) | User and endpoint anonymization requests/status, for scrubbing identifying data from historical records under regulatory requirements | Fulfill a data-subject erasure request without destroying the underlying audit trail |
| Syslog | Raw event stream (logins, config changes, session start/stop, and more) forwarded to an external syslog server | Feed a SIEM for centralized, long-term, tamper-resistant log retention |
Syslog: reporting that leaves the appliance
Everything above lives inside PRA's own Reports UI, which is fine until you need retention or correlation that spans more than one system. Syslog reporting integrates BeyondTrust event data with external syslog servers, forwarding user activity, session details, and system changes for centralized logging, analysis, and archiving alongside the rest of your infrastructure's logs. This is also the mechanism most SIEM integrations (Splunk and similar) build on. Module 5's site-wide configuration and Module 1's port table both mention this: syslog traffic normally goes out over UDP 514, with TCP 6514 available for TLS-encrypted delivery.
Reports stored only on the B Series Appliance are only as durable as that appliance. Forwarding events to syslog/SIEM gives you a copy outside PRA's control — useful for compliance retention windows, and essential if you ever need to prove what happened after an appliance has already failed over or been rebuilt (Module 6).
Treating the Reports page as a live monitoring tool. It isn't — reports are built from data already logged, so they show you what happened, not what's happening right now. Real-time oversight of active sessions (watching or joining a session in progress) is a Team/Access Console capability from Module 10, not a Reports capability. If you need to intervene in a session, you're too late by the time you're looking at a report.