Password Safe Session Management: — Proxy Sessions, Recording & Live Termination

① Why session proxy — Connect without ever holding the password

Lesson 7 ended with Sneha's request approved: RDP to the ICICI prod DB server 192.168.40.18 as svc-dbadmin, ticket CHG0042118, 120-minute release. Old world, the portal would now show her the password — and from that second the bank has a problem: the secret is in her head, her clipboard, maybe her notepad. New world, she just clicks Connect. The portal hands her client a connection — and the password never appears anywhere. That trick is the session proxy.

Mechanically there are two legs. Leg 1: Sneha's laptop connects to the Password Safe host — not the target — on the proxy ports: 4489 for RDP, 4422 for SSH (a third listener, 4488 on 127.0.0.1, feeds session monitoring). On this leg she authenticates as herself — her own directory login and MFA. Leg 2: the proxy pulls svc-dbadmin's password from the vault and opens its own connection to the target on the real port (3389/22), performing credential injection. The secret travels only on the far leg. A keylogger on her laptop captures her typed commands — but the one thing it came for, the privileged password, was never typed, never displayed, never on her side of the gate.

Now the question interviewers love: what does the target see? A perfectly normal logon — account svc-dbadmin, source IP = the proxy, not Sneha's laptop. The Windows security log on 192.168.40.18 cannot name Sneha at all. That is not a bug; it is the design. Think of a hotel master-key register: the room lock only knows "the master key opened me" — it is the register at the front desk that records which staff member signed the key out, when, and for which room. Target log = the lock; Password Safe session record = the register. Attribution lives in the register, which is why section ④ matters so much to auditors. One operational consequence to teach your network team: firewall the real ports so that only the proxy may speak 3389/22 to managed targets — otherwise an admin who once saw the password can quietly bypass the gate.

For terminal people there is a power-user path that skips the portal: Direct Connect. You SSH to the proxy port with a composite username — requester, managed account and system stitched together with + delimiters — and Password Safe matches it to your approved request. RDP gets the same convenience differently: the portal serves a unique .rdp file per account + system combo, pre-pointed at port 4489. Those files expire — a stale one is the classic "it worked yesterday" ticket.

ssh -p 4422 sneha.r+svc-dbadmin@icici.in+DBPROD01@pam.icici.in

sneha.r@pam.icici.in's password: ********   ← HER password + MFA, not the managed one
Password Safe: request 4112 matched (svc-dbadmin @ DBPROD01, 118 min left)
Session is being recorded.
[svc-dbadmin@DBPROD01 ~]$

The four numbers and names of the proxy layer

Tap each card — these four come up in every Password Safe interview round.

② Session recording — what the camera sees, what it honestly cannot

Recording is switched on per access policy — the same schedule that carried Approvers and Auto Approve in lesson 7 also carries Record Session, Keystroke Logging (on by default) and Enhanced Session Auditing. What lands on disk depends on the session type, and the difference matters in audits. RDP is a camera: full screen video of everything Sneha saw, plus — via Enhanced Session Auditing — keystrokes and mouse activity, and even text copied to the clipboard in-session (captured the first time only; copying the same text again is not re-logged). SSH is a transcript: every keystroke stored as text, which makes it the searchable one.

That word searchable is where SSH recording earns its keep. In Password Safe → Sessions → Completed Sessions, the grid filter has a Filter by: Keystroke option — type DROP TABLE or rm -rf and you get every session, across months, where those characters were typed. Open a recording and the keystroke pane sits on the right; click any keystroke entry and the replay jumps to that exact moment. One more SSH-specific control: Session Masks (Configuration → Privileged Access Management → Session Masks) replace matched secrets with asterisks on replay — so the DBA who typed an application password mid-session has not leaked it to every future reviewer of the recording.

Who may watch all this? Replay is gated by role: Administrator, Auditor, Recorded session reviewer, or ISA. Inside the player you get Play, a progress bar with hover timestamps, a Snapshot button that exports the current frame as a JPEG (1024×768 — auditors love attachable frames), and a Mark as Reviewed checkbox that itself leaves an audit trail of who reviewed what. Storage is the unglamorous half of the design: video is heavy, and in Password Safe Cloud the recordings cache on your Resource Broker first — the documented 64 GB session-cache disk is not a suggestion; undersized broker disks kill session monitoring before anything else. Cloud-side, sessions older than six months auto-archive; an archived session is one ⋮ → Restore Session away from replayable (add the Archive Status column via Column Chooser to see what state each row is in).

POST https://pam.icici.in/BeyondTrust/api/public/v3/Keystrokes/Search
Authorization: PS-Auth key=c479a66f...; runas=icici\\audit-svc;
Content-Type: application/json

{ "Data": "DROP TABLE" }

HTTP/1.1 200 OK
[
  { "KeystrokeID": 88231, "SessionID": 5521, "TimeMarker": 412,
    "Type": 0, "Data": "DROP TABLE customers_old;" }
]

Now the honest limits — say these before the auditor discovers them. ① If Rahul RDPs to the target and from there opens a second RDP to another box, that second hop is only pixels inside the video — no per-system keystroke audit, no separate session record. (Fix the behaviour: make the second system a managed system and broker it too.) ② RDP video is not text-searchable — search runs on keystrokes and metadata, never on pixels. ③ The recorder sees the brokered session, not the laptop around it — a photo of the screen, a second unmanaged machine, none of that is in scope. ④ And one field report worth repeating: a PeerSpot reviewer noted occasional keystroke gaps in RDP captures — treat recordings as one layer of evidence next to target-side logs and your SIEM, never as the only copy of the truth.

③ Live monitoring & control — watch, lock, terminate while it happens

Everything so far is forensic — useful after. The live layer is what makes the proxy a control rather than a diary. Password Safe → Sessions → Active Sessions lists every in-flight session; the ⋮ menu on a row offers four verbs, and choosing the right one is a small art. View Session — watch the session in real time (the user is not notified). Lock Session — freeze it; the user's screen tells them the session is locked and to contact their administrator. Terminate Session — kill the connection now. Terminate and Cancel Session — kill it and cancel the underlying request (offered for requestor-initiated sessions, not admin/ISA ones). Seeing the grids needs its own permissions, by the way — Active session reviewer / Recorded session reviewer roles — and admin-initiated sessions are visible only to holders of the Admin Session Reviewer read permission.

The verb choice that trips people: Terminate kills the session, not the release. The request is still approved, the release clock is still running — the user can simply reconnect. Sometimes that is exactly right (a hung client). For a misbehaving human it is exactly wrong: use Terminate and Cancel, which also pulls the request out from under them — no reconnect. Lock sits in between: the session survives, frozen, while you make a phone call. Map them to intent: glitch → Terminate, conversation → Lock, incident → Terminate and Cancel.

Now the pattern that sells session management to engineering managers: coaching. Flipkart, Friday evening. Karthik (8 months into his first job) has an approved change on the prod orders database. Meera, his senior, opens View Session on her second monitor and just… watches, on mute, while doing her own work. Karthik works knowing a senior can see — which already improves his care level (the society-gate CCTV effect: the camera's presence does most of the work). Twenty minutes in he opens the wrong database — orders_in instead of orders_in_stg. Meera clicks Lock Session; his screen freezes mid-keystroke with the contact-your-administrator message; she calls: "check your DB name, then I'll unlock." Thirty seconds of embarrassment instead of a sev-1 and a rollback. The recording even becomes training material later. That is live control used as mentorship — the kill switch is for vendors and incidents; the lock is for teaching.

POST https://pam.icici.in/BeyondTrust/api/public/v3/Sessions/5544/Lock
Authorization: PS-Auth key=c479a66f...; runas=icici\\secops-svc;

POST https://pam.icici.in/BeyondTrust/api/public/v3/Sessions/5544/Terminate
Authorization: PS-Auth key=c479a66f...; runas=icici\\secops-svc;

HTTP/1.1 204 No Content      ← Lock applied: user sees the locked-session message
HTTP/1.1 204 No Content      ← Terminate accepted: session torn down
# bulk variants exist too:
#   POST ManagedAccounts/{id}/Sessions/Terminate   (kill ALL sessions on an account)
#   POST ManagedSystems/{id}/Sessions/Terminate    (kill ALL sessions on a system)

④ Sessions as compliance evidence — one chain from ticket to rotation

Why do Indian banks buy this module? Because their regulators effectively require it. RBI's cyber security framework expects banks to centrally control privileged access and keep an audit trail of what privileged users actually did — "we have a strong password" answers neither. SEBI's CSCRF pushes the same on market intermediaries: privileged access monitoring plus log retention an examiner can test. And the Indian IT majors listed in the US — Infosys, Wipro — carry SOX ITGC obligations: prove every change to a financial system was authorised and attributable. All three asks reduce to one auditor question: "For this privileged action, show me who, with whose approval, doing exactly what, and prove they could not do it again with the same secret." Session management is the module that answers it in one screen.

The answer has a shape — teach it as the six-link chain: ticket → request → approval → release → recording → rotation. The ServiceNow ticket says the work was sanctioned; the request carries the reason and maps human to account; the approval shows dual control on tier-0; the release bounds the time window; the recording (video + keystrokes) shows the actual hands on the actual system; the rotation event proves the used password died at check-in. Six artefacts, every one generated automatically by the workflow you built in lessons 7–8 — the audit story writes itself as a by-product of normal operations. Compare that with the screenshot-folder-and-spreadsheet evidence most teams scramble to assemble every audit season.

Two production habits turn this from demo to discipline. First, retention is a decision, not a default: agree with compliance how long recordings and keystroke logs must be reachable (RBI examiners routinely sample 6–12 months back), confirm cloud archive/restore covers it, and on-prem watch the appliance disk — video eats storage, and a full disk silently becomes a retention failure. Second, export the events: ship session start/stop, lock/terminate actions and rotation events to the SIEM via syslog so evidence survives even a PAM-platform outage, and pull periodic reports for the audit binder. The grid is your working view; the SIEM copy is your insurance.

$base = "https://pam.icici.in/BeyondTrust/api/public/v3"
$h = @{ Authorization = "PS-Auth key=c479a66f...; runas=icici\\audit-svc;" }
Invoke-RestMethod -Method Post -Uri "$base/Auth/SignAppIn" -Headers $h -SessionVariable ps | Out-Null
$s = Invoke-RestMethod -Uri "$base/Sessions?status=2" -Headers $h -WebSession $ps
$s | Where-Object { $_.AssetName -eq "DBPROD01" } |
  Select-Object SessionID, UserID, ManagedAccountName, NodeID, StartTime, EndTime |
  Export-Csv -Path .\DBPROD01-sessions-may.csv -NoTypeInformation
Invoke-RestMethod -Method Post -Uri "$base/Auth/Signout" -Headers $h -WebSession $ps

PS C:\audit> Import-Csv .\DBPROD01-sessions-may.csv | Select -First 2

SessionID UserID ManagedAccountName StartTime            EndTime
--------- ------ ------------------ ---------            -------
5521      214    svc-dbadmin        2026-05-03T02:00:11Z 2026-05-03T02:24:48Z
5544      377    svc-dbadmin        2026-05-09T11:02:05Z 2026-05-09T11:41:19Z