Recorded Sessions for Mixed macOS and Windows Admins
Summit Capital has 60 privileged administrators. About 25 use macOS laptops and the rest use Windows. They need RDP to 90 Windows jump hosts and SSH to 150 Linux servers. Compliance requires all privileged sessions recorded, with screen and keystrokes for SSH, retained for 12 months and reviewed after any incident. Today admins use native RDP and PuTTY clients with credentials checked out from Secret Server; sessions are not recorded. The network team will not allow direct admin RDP or SSH from user VLANs to server VLANs; traffic must pass through a controlled jump path. Secret Server 11.x is on-premises with a Distributed Engine in the server VLAN. A pilot of browser-based Remote Access worked but was not enabled for all users. The security team wants minimal client software on macOS and a clear playback and retention model.
1. Which launch architecture should you use, and why? Address macOS support, recording, and the network path.
Read the worked answer
Use Secret Server's browser-based Remote Access through the Distributed Engine in the server VLAN, with all privileged sessions launched from Secret Server rather than from native clients. macOS users then need only a supported browser, not a locally installed RDP or SSH client, which meets the minimal-client requirement. The network path becomes user VLAN to Secret Server over HTTPS, and engine to target over RDP or SSH; direct user-to-server admin traffic can remain blocked. Recording is centralized at the gateway or engine, so it does not depend on the endpoint and cannot be bypassed by a user closing a local recorder. If browser-based Remote Access is not licensed for all users, use supported local launchers with session recording enabled, but that reintroduces client software and endpoint dependency. The browser model is the better fit for compliance and mixed OS.
2. How should session recording, retention, and access to recordings be configured?
Read the worked answer
Enable session recording for the RDP and SSH launchers or Remote Access paths used by these admins. For SSH, enable keystroke recording as well as screen capture, because compliance explicitly requires both. Store recordings on a hardened file share with enough capacity for 12 months, and monitor free space and recording failures. Set the retention period to 12 months, with a documented exception process for legal hold. Restrict playback to a small Audit or Security role, not to all secret owners, because recordings may contain sensitive data. Use session monitoring for live review during incidents. Test playback from a non-admin account and confirm timestamps and user identity are present. Do not allow an unrecorded local client path to the same servers, because users will otherwise bypass the control.
3. A Linux administrator says browser-based SSH is too slow and asks to use a local SSH client directly. What do you check and decide?
Read the worked answer
First determine whether the delay is caused by engine placement, network latency from the user VLAN to Secret Server, browser proxy settings, or insufficient engine resources. If the engine is in the server VLAN but far from users, or if the recording share is slow, fix those issues before granting an exception. If a local client is necessary, use a supported recorded launcher or SSH proxy path that still sends the session through Secret Server, not a direct SSH connection. Test recording and playback for that path. Do not allow an unrecorded direct client merely for performance, because it defeats the compliance requirement and creates an unauditable path. If an exception is unavoidable, require documented risk acceptance, a compensating control such as network segmentation and command logging, and a time limit. The decision should be based on evidence from a test session, not on user preference alone.