Session Recording Gaps After a Jump Host Change
A software company routes all privileged RDP through a Password Safe jump host, with session recording enabled for domain admin and database admin groups. During a network refresh, the jump host was rebuilt and a new certificate was issued. Two weeks later, an insider investigation needs session recordings for a database admin's activity on a specific date. The recordings exist as files, but playback fails, and the session index shows the sessions as 'in progress' rather than completed. Separately, the team discovers that sessions initiated through a newly added SSH bastion are not recorded at all, because the bastion was never registered as a managed asset. The compliance officer asks whether the two-week gap invalidates the audit trail.
1. Explain the likely cause of the playback failure and the 'in progress' status, and distinguish this from the separate SSH gap.
Read the worked answer
These are two distinct failures and should be reported separately.
Playback failure / stuck 'in progress': The jump host rebuild changed its certificate. Session recording depends on a trusted relationship between the session broker/jump host and the vault - the recorder must authenticate to store the recording and close out the session record. If the new certificate was not trusted by the vault (or the jump host's connector identity was not re-enrolled), recordings may be written but never finalized: the session record stays 'in progress' because the completion/close event never validated. Playback then fails because the file lacks the metadata/index the player needs, or is encrypted under a key the rebuilt host no longer presents correctly. This is a configuration regression introduced at rebuild, not evidence tampering.
SSH bastion gap: The bastion was never registered as a managed asset, so sessions through it were never brokered by Password Safe at all. No recording was attempted. This is a coverage gap - a class of privileged access that was outside the control entirely.
The distinction matters: the first is a recoverable technical fault affecting existing recordings; the second is a scope failure meaning those sessions were never under management.
2. What should the team do to recover evidence, close the gaps, and answer the compliance officer honestly?
Read the worked answer
Recover and validate:
- Re-enroll the rebuilt jump host's certificate/connector identity and confirm trust with the vault.
- Re-index or re-associate orphaned recording files with their session records so they can be played back; validate one known session end-to-end before declaring recovery.
- Preserve the raw files with hashes and chain-of-custody documentation so their integrity can be attested even if playback tooling was broken.
Close the gaps:
- Register the SSH bastion as a managed asset and route its sessions through the broker; verify recording is actually produced for a test session.
- Add a change-management check: any rebuild or new bastion must pass a session-recording verification test before being put into service.
- Add monitoring that alerts on sessions stuck 'in progress' beyond a threshold, and on privileged hosts that are not managed assets.
Answer the compliance officer:
- State plainly that recordings for the affected window exist but were not finalized, and that SSH-bastion sessions in that period were not recorded at all.
- Provide the recovered evidence, the root-cause explanation, the remediation dates, and the compensating controls (e.g., command logs, authentication logs) for the unrecorded SSH window.
- Do not claim the trail is intact. An honest gap with documented remediation is defensible; a misrepresented one is not.