# Password Safe Session Management: — Proxy Sessions, Recording & Live Termination Source: https://ai.techclick.in/blog_beyondtrust_session_management Markdown: https://ai.techclick.in/blog_beyondtrust_session_management.md Publisher: Techclick Infosec Pvt Ltd Password Safe session management: RDP/SSH proxy on 4489/4422, credential injection, recording and keystroke search, live lock/terminate, RBI-ready audit evidence. Password Safe Session Management: — Proxy Sessions, Recording & Live Termination student learning map A visual study map for Password Safe Session Management: — Proxy Sessions, Recording & Live Termination showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Password Safe Session Management: — Proxy Sessions,... BeyondTrust · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Why session proxy — Connect... 4. Practice ② Session recording — what the... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers think session recording is surveillance theatre — a big-brother camera pointed at admins, useful only for catching someone after the damage is done. Wrong on both counts. The proxy+recording pair is primarily an attribution machine : the target's own log can only ever say which account logged in (everyone arrives as svc-dbadmin from the proxy IP) — only the session record says which human . And it cuts both ways: when prod breaks at 2 AM, the replay proves the innocent engineer innocent in fifteen minutes instead of a week of interviews. Plus it is live, not forensic — a senior can watch, freeze or kill a session while it is happening . ## ① 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. 👉 So far: Connect = two legs — Sneha→proxy (she proves who SHE is, port 4489/4422), proxy→target (vaulted credential injected, port 3389/22). Next: the whole architecture in one picture, then what the target's own log sees. Figure 1 — Two legs, one gate — the session proxy architecture Architecture diagram of a Password Safe proxied session. On the left, Sneha's laptop in the user zone connects outward to the Password Safe proxy, authenticating as herself on port 4489 for RDP or 4422 for SSH. In the middle, the Password Safe appliance holds the vault and the session recorder. On the right, the proxy opens a second connection to the target server on port 3389 or 22, injecting the vaulted credential. A leader line marks that the password never crosses to the left side. A green register bar along the bottom records request, session, keystrokes and rotation. A legend explains the colours. - Two legs, one gate — the password only travels on the far leg USER ZONE (untrusted side) Sneha's laptop 10.20.4.55 logs in as HERSELF (AD login + MFA) — no admin password Password Safe session proxy + vault VAULT svc-dbadmin RECORDER :4488 local listens: 4422 SSH · 4489 RDP policy gate: record? keystrokes? concurrent? force-terminate? admin can watch / lock / kill LIVE TARGET (audited side) prod DB server 192.168.40.18 its log shows: svc-dbadmin from the PROXY's IP — not Sneha's LEG 1 → :4489 she proves who SHE is LEG 2 → :3389 credential injected HERE 🔑 password never leaves the vault side — a keylogger on Sneha's laptop captures nothing usable ✗ direct RDP to target blocked by firewall — only the proxy may speak 3389 to prod 📒 one session = one register row: request #4112 · approver · ticket CHG0042118 · recording · keystrokes · rotation on check-in target log answers WHAT account logged in — this register answers WHICH HUMAN it was untrusted/attacker trusted/vaulted policy/decision key insight allowed/audited Follow the arrows: leg 1 (blue) carries Sneha's OWN identity to the proxy; leg 2 (green) carries the injected credential to the target. The red dashed line is the path that no longer exists — direct RDP to prod is firewalled off so the proxy is the only door. The green register bar is what the auditor will read in section ④. 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. Quick check · Q1 of 10 Sneha opens a proxied RDP session to 192.168.40.18. Security review later reads that server's own Windows event log. What does it show for her session? a) Her AD username, from her laptop's IP 10.20.4.55 b) The managed account svc-dbadmin, logging on from the Password Safe proxy's IP c) A special username like BEYONDTRUST-PROXY so admins can spot brokered logons d) Nothing — proxied sessions are invisible to target-side logging Correct: b. The target only experiences leg 2: a normal logon by the managed account from the proxy's address. It cannot see the human behind the proxy — that mapping (Sneha ↔ session ↔ request ↔ ticket) lives in Password Safe's session record. Options a and c invent things the protocol never sends; option d is the dangerous myth — the logon is fully visible, it just is not attributable from the target alone. 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. Direct Connect SSH — from Sneha's laptop, via the proxy (port 4422, never 22) ssh -p 4422 sneha.r+svc-dbadmin@icici.in+DBPROD01@pam.icici.in Expected output 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 ~]$ SYMPTOM: "RDP file worked yesterday, today the connection just dies" Three usual suspects, in order: the downloaded .rdp file went stale (re-download from the portal — each account+system combo has its own), the release expired so there is no active request behind the session, or the client is pointed at 3389 instead of 4489 (someone "helpfully" edited the file). Check the request first, then re-fetch the file. If all three pass, verify the proxy service itself — session monitoring rides 4488 on the appliance. ### ▶ One click of Connect — the proxied session, stage by stage This is Sneha's approved RDP request turning into a live, recorded session. Press Play for the healthy path, then Break it to see the failure. ① Connect sneha-lt → portal: Connect on request #4112 → unique .rdp file (target = proxy:4489) ▼ ② Leg 1 sneha-lt → proxy:4489 — authenticates as sneha.r (AD + MFA), request validated ▼ ③ Leg 2 + inject proxy → 192.168.40.18:3389 — vault injects svc-dbadmin credential server-side ▼ ④ Recorded video + keystrokes → recorder (:4488) · on check-in: password rotated Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Pause & Predict Predict: Sneha's laptop has a commodity keylogger on it (she does not know). She completes a full proxied RDP session with credential injection. What exactly does the attacker harvest? Type your guess. Reveal answer Answer: Her OWN directory password (typed on leg 1 — bad, but MFA limits it, and it is not a privileged secret) and every command she typed inside the session. What the attacker does NOT get: svc-dbadmin's password — it was injected on the proxy→target leg and never existed on her machine. And whatever they capture of the session, the recording captured too — the defenders have a copy of the attacker's view. This asymmetry is the whole sales pitch of injection over disclosure. ### The four numbers and names of the proxy layer Tap each card — these four come up in every Password Safe interview round. 🔢 4422 tap to flip SSH proxy listener. Users SSH here, never to target port 22. So: a 22 in your client config means you bypassed PAM. 🖥️ 4489 tap to flip RDP proxy listener. The portal's .rdp files point here. So: firewall 3389 so only the proxy may reach prod. 🎥 4488 tap to flip Session monitoring listener on 127.0.0.1 — feeds recording and live view. So: if replay is dark, check this service first. 💉 Injection tap to flip Vault supplies the credential on the far leg. User never sees it. So: nothing to phish, photo, or paste into chat. ## ② 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. 👉 So far: RDP = video + (with ESA) keystrokes/mouse/first-copy clipboard; SSH = searchable text transcript + masks. Next: the capture map with its honest red zone, then where recordings live and for how long. Figure 2 — Camera vs transcript — the session capture map Two-lane diagram of Password Safe session capture. The RDP lane shows screen video, keystrokes and mouse activity via enhanced session auditing, and clipboard text captured on first copy only. The SSH lane shows a searchable keystroke transcript with session masks turning typed passwords into asterisks. A red strip at the bottom lists what is not captured: activity on second-hop systems is pixels only, RDP video is not text-searchable, and the user's own laptop outside the session is never recorded. Camera vs transcript — know which evidence each session type gives you 🖥️ RDP session = CCTV camera Screen video — replay what the eyes saw Play · progress bar · Snapshot exports a JPEG frame Keystrokes + mouse — Enhanced Session Auditing ⚠ needs the functional account to be ADMIN on the host Clipboard text copied in-session captured on the FIRST copy only — repeats are not re-logged storage-hungry: video sizes your appliance/broker disk ⌨️ SSH session = signed transcript Every keystroke, as TEXT Filter by: Keystroke → "DROP TABLE" → 2 hits searchable across thousands of sessions in seconds Session Masks Configuration → Privileged Access Management typed secret on replay → ******** Click a keystroke → replay jumps to that moment transcript and timeline stay linked tiny on disk — text costs almost nothing to retain ✗ Honest limits — what the recorder does NOT give you ① a second hop (RDP from the target onward) is only PIXELS in the video — no per-system keystroke audit there ② RDP video is not text-searchable — search lives in keystrokes/metadata · ③ the user's own laptop outside the session is never recorded Design rule: recording documents the brokered hop — it does not replace target-side logging or your SIEM. Left lane is RDP: rich but heavy and pixel-based. Right lane is SSH: plain text, tiny, searchable. Read the red strip twice — knowing what the recorder does NOT capture is what separates an L2 answer from an L1 answer in audit meetings. Password Safe → Sessions → Completed Sessions , filtered on keystrokes. (Recreated for clarity — your console matches this.)"> 🖥️ This is where evidence is found — Password Safe → Sessions → Completed Sessions , filtered on keystrokes. (Recreated for clarity — your console matches this.) techclick.ps.beyondtrustcloud.com · Password Safe › Sessions 1 Grid Completed Sessions 2 Filter by Keystroke 3 Keystroke DROP TABLE 4 Result · Session 5521 rahul.v · svc-dbadmin @ DBPROD01 · 02:00–02:24 · SSH Row actions (⋮) View Session · Restore Session · Mark as Reviewed Replay controls Play · progress bar · Snapshot (JPEG) · keystroke pane → View Session 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). Password Safe API — find sessions where a phrase was typed (Keystrokes/Search) 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" } Expected output HTTP/1.1 200 OK [ { "KeystrokeID": 88231, "SessionID": 5521, "TimeMarker": 412, "Type": 0, "Data": "DROP TABLE customers_old;" } ] SYMPTOM: RDP recordings play, but the keystroke pane is EMPTY for every Windows session Enhanced Session Auditing has a precondition people miss: the functional account on the managed Windows / RDS host must have administrative rights — ESA plants its capture hooks using that account. Rotation may work fine with lesser rights, so the gap hides until an auditor asks for keystrokes. Verify the functional account's group membership on the target, then test one fresh session — ESA only applies from session start, it cannot backfill old recordings. 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. Quick check · Q2 of 10 An ICICI auditor asks: "Show me every session in March where anyone typed a command containing sysadmin." Which capture makes that a 30-second job? a) RDP screen video — scrub through the recordings and watch for it b) The target servers' bash history files c) SSH keystroke logs — Filter by: Keystroke on the Completed Sessions grid (or POST Keystrokes/Search) d) Clipboard capture — every command is copied before it is run Correct: c. Keystrokes are stored as searchable text — one grid filter (or one API call) sweeps months of sessions. Video (a) would mean human eyes on hours of footage, and pixels are not searchable. Bash history (b) lives on targets, is user-editable and proves nothing about WHO typed. Clipboard capture (d) only logs text actually copied in-session, first copy only — most commands are typed, not pasted. Pause & Predict Predict: during a recorded SSH session, a DBA types an application's database password in plain text. Three reviewers will replay this recording next year. What did the platform give you to contain this? Type your guess. Reveal answer Answer: Session Masks (Configuration → Privileged Access Management → Session Masks): define a mask pattern and replays show asterisks instead of the matched secret — active masks apply at playback. But masks are containment, not absolution: the password still crossed the wire and the target — best practice is to treat it as exposed, rotate that app credential, and coach the DBA (that is exactly what live monitoring in section ③ is for). ## ③ 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 . 👉 So far: four live verbs — View (silent watch), Lock (freeze + talk), Terminate (kill, reconnect possible), Terminate and Cancel (kill + revoke). Next: the coaching pattern that turns this from policing into teaching, and the API equivalents. Password Safe → Sessions → Active Sessions , ⋮ menu open on a vendor session. (Recreated for clarity — your console matches this.)"> 🖥️ The live control room — Password Safe → Sessions → Active Sessions , ⋮ menu open on a vendor session. (Recreated for clarity — your console matches this.) techclick.ps.beyondtrustcloud.com · Password Safe › Sessions › Active 1 Session 5544 · In Progress vendor.ext · svc-netadmin @ RTR-CORE-01 · RDP · 00:41 elapsed 2 Watcher meera.k (View Session — live, viewer-silent) 3 ⋮ Action Lock Session ⋮ Action Terminate Session 4 ⋮ Action Terminate and Cancel Session Policy on this session Record: Yes · Keystrokes: Yes · Force Termination at release end: Yes Apply 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. Aditya at Airtel faces this A network vendor's engineer (public IP 203.0.113.77) is in an approved RDP session to router-management host RTR-CORE-01 via svc-netadmin. Aditya, shadowing the session live, watches them open a browser and start downloading an unapproved "config backup tool" from a file-sharing site. He clicks Terminate Session — and ninety seconds later the vendor is simply BACK, continuing. Likely cause Terminate Session ends the TCP session but leaves the access request approved and the release window open. The vendor's portal still shows a valid Connect button, so they reconnected — legitimately, by the platform's rules. Diagnosis Active Sessions grid showed a NEW session ID for the same request minutes after the kill — the giveaway that the request, not the session, is the thing still alive. BeyondInsight > Password Safe > Sessions > Active Sessions Fix Use Terminate and Cancel Session — it kills the live connection AND cancels the underlying request, so reconnect is impossible. Then rotate svc-netadmin immediately rather than waiting for check-in rotation, raise an incident with the session ID, and Mark as Reviewed after replaying the recording with the vendor's management. Verify Active Sessions shows no new session for that request; the request status reads cancelled in the requester's portal; the rotation event for svc-netadmin appears in the audit log; the recording (including the download attempt) is preserved under the original session ID for the incident file. Password Safe API — lock, then terminate a live session (what the ⋮ menu calls under the hood) 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; Expected output 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) ALERTING — be honest about what is built in Password Safe will not page you because someone typed a scary command — there is no out-of-the-box "risky keystroke" alarm. Real deployments wire it up: forward BeyondInsight events to your SIEM via syslog, alert on session-start for tier-0 systems (so a human opens View Session), schedule Keystrokes/Search sweeps for your danger-list ( DROP TABLE , rm -rf , shutdown ), and let the access policy's Force Termination hard-stop anything that outlives its release. The platform gives you the hooks; the vigilance is your build. Quick check · Q3 of 10 Meera is live-watching Karthik mid-mistake on a prod DB. She wants him STOPPED immediately but CONNECTED — she is dialling his number to walk him through it. Which verb? a) Lock Session — freezes the session in place; his screen says to contact the administrator b) Terminate Session — stops the bleeding fastest c) Terminate and Cancel Session — stop it and revoke the request d) Force Termination — the access policy does it automatically Correct: a. Lock is the coaching verb: the session survives, frozen, while the human conversation happens — unlock and Karthik resumes with his approval intact. Terminate (b) throws him out but leaves the request alive (he reconnects mid-confusion); Terminate and Cancel (c) nukes his approved change — overkill for a typo; Force Termination (d) is not an admin action at all, it is the policy setting that ends sessions when the release window closes. Pause & Predict Predict: at 02:00 an on-call engineer sees ELEVEN active sessions under managed account svc-dbadmin — clearly a runaway automation gone wrong. Killing them one ⋮ at a time is too slow. What is the one-call fix? Type your guess. Reveal answer Answer: POST ManagedAccounts/{managedAccountID}/Sessions/Terminate — terminates every live session riding that managed account in one API call (there is a ManagedSystems variant to sweep a whole system the same way). Then cancel/disable whatever is re-creating the requests, and rotate the account. The per-session ⋮ menu is for surgical work; the bulk endpoints are for fires. ## ④ 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. Figure 3 — Same incident, two worlds — shared password vs brokered session Side-by-side comparison. Left, red world: a table was dropped at 2 AM, the target log only says administrator from an unknown jump box, six engineers all knew the shared password, the investigation dead-ends in interviews. Right, green world: the same event resolves through a chain — the session record names the human, links to request, reason, ticket and approver, the keystroke search finds the exact command, the replay shows the screen, and rotation proves the used password is already dead. 02:00 — somebody ran DROP TABLE on prod. Now investigate. WITHOUT a session broker Event 4624 · user: administrator source: 172.16.8.40 (shared jump box) Who knew the password? six engineers + two ex-employees No recording · no keystrokes · no ticket link password unchanged since January Investigation = interviews and guesswork auditor writes: "privileged actions not attributable" RBI/SOX outcome: observation raised "shared credentials, no individual accountability, no evidence of authorised change" → finding stays open for months WITH Password Safe sessions ① Keystroke search: "DROP TABLE" → session #5521 ② Session #5521 → human: rahul.v · 02:00–02:24 ③ Linked request #4112 · reason · ticket CHG0042118 ④ Approver: meera.k (dual control at 01:52) ⑤ Replay the video · Snapshot the exact frame ⑥ Rotation on check-in — used password already dead Investigation = 15 minutes of replay, zero interviews Turns out: authorised emergency fix, badly timed. The same chain that catches an insider also PROVES an innocent engineer innocent — recording protects Rahul as much as the bank Attribution is the product: target logs name the ACCOUNT — only the broker names the HUMAN. Left is the world auditors write findings about: the trail dies at "administrator did it". Right is the six-link chain — note step ⑥: rotation converts "we think the password is safe" into "the used password verifiably no longer works". Note also the bottom-right insight: the chain exonerates as often as it convicts. 👉 So far: RBI/SEBI/SOX all reduce to attribution + authorisation + non-reusability — and the six-link chain (ticket→request→approval→release→recording→rotation) answers all three automatically. Next: producing the evidence on demand, including for a session recorded eight months ago. Priya at ICICI faces this RBI inspection, day two. The examiner picks one change from last October — eight months ago — and asks Priya to demonstrate the full trail: who accessed the core-banking DB host, who approved it, and what was done in the session. The Completed Sessions grid finds the session, but View Session will not play it. Likely cause Password Safe Cloud auto-archives sessions older than six months. The October recording is archived, not gone — but archived sessions cannot be replayed until restored. Diagnosis Add the Archive Status column via the Column Chooser on the Completed Sessions grid — the October session shows as archived, while its metadata (user, account, system, duration, linked request) is still fully visible in the grid. BeyondInsight > Password Safe > Sessions > Completed Sessions Fix Click ⋮ → Restore Session on the archived row, wait for the restore to complete, then View Session → Play. Walk the examiner through the chain: linked request (reason + ticket number), approver and timestamp, release window, the replay itself, a Snapshot JPEG of the key frame for the working papers, and the rotation event after check-in. Mark as Reviewed to log the inspection itself. Verify The examiner's sampled change traces end-to-end in under ten minutes; the Snapshot lands in the audit file; the review action is itself in the audit trail — and Priya schedules a quarterly drill: restore + replay one archived session, so audit week is never the first test of the archive. 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. PowerShell — month-end audit export: every completed session on one system, with status decoded $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 Expected output 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 Figure 4 — Session-ops quick card Cheat sheet in five panels: proxy ports 4422 SSH, 4489 RDP, 4488 local monitoring; console paths for Sessions grids and Session Masks; live controls View, Lock, Terminate, Terminate and Cancel; API endpoints for creating, locking, terminating and searching sessions; session status codes and the roles allowed to replay recordings. 📋 Session-ops quick card — pin this above your desk PROXY PORTS 4422 → SSH proxy (not 22) 4489 → RDP proxy (not 3389) 4488 → monitoring, 127.0.0.1 user → proxy → target; never user → target CONSOLE PATHS Password Safe → Sessions → Active Sessions (watch · lock · kill) Password Safe → Sessions → Completed Sessions (⋮ View Session → Play) Configuration → Privileged Access Management → Session Masks replay roles: Administrator · Auditor · Recorded session reviewer · ISA LIVE CONTROLS (⋮ on Active Sessions) View Session — watch live, user unaware Lock Session — freeze; user told to call admin Terminate Session — kill now (request survives) Terminate and Cancel — kill + cancel the request ⚠ plain Terminate lets the user reconnect — the release is still live API (base /BeyondTrust/api/public/v3) POST Requests/{requestID}/Sessions POST Sessions/{sessionID}/Lock POST Sessions/{sessionID}/Terminate POST Keystrokes/Search · GET Sessions SessionType: SSH · RDP · rdpfile · app — owner of the request only SESSION STATUS CODES (GET Sessions) 0 Not Started · 1 In Progress · 2 Completed · 5 Locked 7 Terminated (deprecated) · 8 Logged Off · 9 Disconnected (RDP) cloud: recordings auto-archive after 6 months → ⋮ Restore Session brings them back for replay Interview one-liner: proxy = attribution, recording = evidence, live control = the kill switch. Everything operational from this lesson on one card: ports, console paths, the four live verbs, the API calls behind them, and the status codes you will read in GET Sessions output. Screenshot it. Quick check · Q4 of 10 A SOX auditor at Wipro has the target server's log: svc-appadmin logged on at 14:02 from the proxy IP and changed a payroll config. Which SINGLE artefact converts that anonymous account logon into a named, authorised human action? a) The firewall log showing the proxy-to-target connection b) The password rotation event from that evening c) The functional account's group membership on the target d) The Password Safe session record — it binds that logon to a human, their request, reason, ticket and approver Correct: d. Only the session record carries the human ↔ account ↔ time ↔ request mapping; from it the whole six-link chain unrolls (ticket, approval, recording, rotation). The firewall log (a) just confirms the network path, the rotation event (b) proves non-reuse but not identity, and the functional account (c) is the rotation worker — it has nothing to do with who used svc-appadmin. Pause & Predict Predict: the examiner's last question — "Prove that nobody can quietly reuse the password from the session we just replayed." What two artefacts close it? Type your guess. Reveal answer Answer: The rotation event fired at check-in (Change Password After Release — the used password verifiably stopped working minutes after the session), plus the access policy showing every future use requires a fresh request/approval cycle. Optionally demo it: attempt a logon with the old credential in a test — failure IS the evidence. This is why lesson 6's rotation and lesson 8's sessions are one story: recording proves what happened; rotation proves it cannot silently happen again. VERIFY — your session layer is audit-ready when… You can do all five, cold, in front of a stranger: ① open a proxied session and show the target log naming only the managed account; ② keystroke-search a phrase across last quarter and land in the right replay; ③ Lock and Terminate-and-Cancel a live test session; ④ restore an archived recording and export a Snapshot; ⑤ walk one change end-to-end through ticket → request → approval → release → recording → rotation in under ten minutes. Drill it quarterly — audit week is the wrong time to learn the Restore button. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Does the target server know Password Safe is in the middle? If the proxy goes down, do live sessions survive? Can the user tell that someone is watching their live session? How big do session recordings get, and what fills up first? Lock vs Terminate vs Terminate and Cancel — give me the 10-second version? What exactly do I hand an RBI/SOX auditor for one sampled change? Pre-curated from BeyondTrust docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which port does the Password Safe RDP session proxy listen on by default? a) 4489 b) 3389 c) 443 d) 4422 Correct: a. The RDP proxy listens on 4489 — users connect there, and the proxy speaks 3389 to the target on the far leg. 3389 is the target-side RDP port (if your client points there, you bypassed PAM), 443 is the web portal/API, and 4422 is the SSH proxy. The trio to memorise: 4422 SSH, 4489 RDP, 4488 session monitoring on 127.0.0.1. Q6 · Apply Rahul (TCS) has an approved request for account ops@unix01 on system UNIX01 and wants an SSH session from his terminal, not the portal. Password Safe host is pam.tcs.in. Which command is right? a) ssh -p 22 ops@unix01 — the request makes the direct path legal b) ssh -p 443 rahul.k@pam.tcs.in and type the managed password when prompted c) ssh -p 4422 rahul.k+ops@unix01.tcs.in+UNIX01@pam.tcs.in d) ssh -p 4488 rahul.k@pam.tcs.in — the monitoring port doubles as the proxy Correct: c. Direct Connect = SSH to the PROXY port 4422 with the composite username requester+account+system, authenticated with Rahul's OWN credentials; the proxy matches it to his approved request and injects the managed credential. Option a bypasses the proxy entirely (no recording, no attribution); 443 (b) is the web/API port, and he should never type a managed password anyway — injection exists so he never holds it; 4488 (d) is the local session-monitoring listener, not a user entry point. Q7 · Apply An auditor replays RDP sessions from Wipro's payment servers: video plays fine, but the keystroke pane is empty on every session from those hosts. SSH sessions elsewhere show keystrokes normally. Most likely cause? a) Keystroke capture is impossible for RDP — only SSH sessions have keystrokes b) Enhanced Session Auditing cannot hook those hosts because the functional account lacks administrative rights on them c) Session Masks are active and masked every keystroke into nothing d) The recordings were archived and restored, which strips keystroke data Correct: b. RDP keystroke/mouse capture comes from Enhanced Session Auditing, and ESA's documented precondition is an admin-privileged functional account on the managed Windows/RDS host — rotation can still work with lesser rights, so the gap hides until someone reads the keystroke pane. Option a is false (ESA exists precisely for RDP); masks (c) asterisk matched secrets in replay, they do not blank entire sessions; archive/restore (d) preserves the recording content. Q8 · Analyze Forensics at ICICI: the core-banking host's log shows svc-dbadmin logged on at 02:00 from 10.10.8.6 (the PS proxy) and dropped a table at 02:14. Three admins had approved releases on that account that night. What is the FASTEST way to name the human? a) Subpoena ISP records for 10.10.8.6 b) Check which admin's laptop was powered on at 02:00 via endpoint telemetry c) Interview all three admins and compare their stories d) Open Completed Sessions filtered to that system and time — the session record at 02:00 names its user, and a keystroke search for the DROP statement confirms the exact session Correct: d. This is exactly what the session record exists for: each concurrent release produces its own session row binding human → account → system → time, and Filter by: Keystroke pins the destructive command to one session ID. The proxy IP (a) is your own infrastructure — nothing to subpoena; endpoint telemetry (b) is circumstantial and slow; interviews (c) are the shared-password world this platform replaced. Q9 · Analyze During a live vendor session, a security engineer clicks Terminate Session. Two minutes later the same vendor is connected again and continuing. What ACTUALLY happened? a) The termination silently failed — only Lock works on vendor sessions b) The vendor exploited a reconnect vulnerability in the proxy c) Terminate killed the session but the approved request and its release window survived — the vendor legitimately reconnected; Terminate and Cancel Session was the right verb d) Force Termination was disabled in the access policy, which makes Terminate advisory only Correct: c. Terminate Session operates on the session, not the request — the release stays valid, so the portal happily issues a new connection. Terminate and Cancel kills both, making reconnect impossible (offered for requestor-initiated sessions). Nothing failed (a) and no exploit occurred (b) — the platform did exactly what was asked; Force Termination (d) governs what happens when the release window expires, it does not change what the Terminate button does. Q10 · Evaluate Two evidence strategies for an RBI inspection at an Indian bank. X: admins screenshot their changes into a shared folder and fill a monthly access spreadsheet. Y: brokered sessions only — auto-generated chain of request + approval + recording + keystrokes + rotation, archived sessions restorable, events mirrored to the SIEM. The examiner samples a change from 8 months ago. Which strategy survives, and why? a) X — self-attested screenshots are simpler for examiners to read than session replays b) Y — its evidence is generated by the control itself, not by the people being audited: tamper-resistant, complete for every session, time-bound, restorable months later, and corroborated by an independent SIEM copy c) Both pass — what matters is that some evidence exists for the sampled change d) X — recordings are inadmissible as audit evidence without each admin's consent Correct: b. Audit evidence is judged on independence and completeness. X is self-reported by the audited population — screenshots are curated, gaps are invisible, and an 8-month-old change exists only if someone remembered to capture it. Y produces evidence as a side effect of the control operating: every session, every time, with restore covering the look-back window and the SIEM copy surviving platform issues. Option c ignores evidence quality (RBI examiners do not); option d is invented — monitored privileged access under disclosed bank policy is standard, which is also why login banners state it. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line: why does a proxied session beat handing the admin a rotated-daily password? Then compare to the expert version. Compare with expert answer Expert version: Because the proxy removes the secret from the human entirely — nothing to keylog, photo or share — while producing attribution (which human, not just which account), a replayable recording, a live kill switch, and rotation on check-in; a disclosed password, however fresh, gives you none of those once it leaves the vault. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Sessions at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Session proxy Password Safe terminates the user's RDP/SSH on itself (4489/4422) and opens its own connection to the target — user and target never touch. Credential injection The proxy supplies the vaulted password on the proxy→target leg; the user never sees, types or holds it. Direct Connect Portal-skipping syntax: SSH to port 4422 with requester+account+system stitched into the username; RDP uses a downloaded per-combo .rdp file. Enhanced Session Auditing Captures keystrokes and mouse activity in RDP/app sessions; requires the functional account to have admin rights on the host. Keystroke search Filter by: Keystroke on Completed Sessions (or POST Keystrokes/Search) — find every session where a phrase was typed. Session Mask Configuration → Privileged Access Management → Session Masks pattern that replaces matched typed secrets with asterisks during replay. Active Sessions Live-session grid (Password Safe → Sessions) — the ⋮ menu carries View, Lock, Terminate, Terminate and Cancel. Lock Session Freezes a live session in place; the user is told to contact their administrator — the coaching verb. Terminate and Cancel Kills the live session AND cancels its request so the user cannot reconnect; plain Terminate leaves the release alive. Force Termination Access-policy setting that hard-ends sessions when the release window closes — policy, not an admin click. Archive / Restore Session PS Cloud auto-archives sessions older than 6 months; ⋮ → Restore Session makes them replayable again. Recorded session reviewer Role allowing recording replay (alongside Administrator, Auditor, ISA); Active session reviewer covers the live grid. #### 📚 Sources BeyondTrust Docs — Password Safe SSH/RDP session connections (proxy ports 4422/4489, monitoring 4488 on 127.0.0.1, Direct Connect syntax, per-combo RDP files). docs.beyondtrust.com/bips/docs/ps-ssh-rdp-connections - BeyondTrust Docs — Password Safe Sessions (Active/Completed Sessions grids; View/Lock/Terminate/Terminate-and-Cancel; replay, Snapshot, Mark as Reviewed; keystroke filter; Session Masks; 6-month cloud archive + Restore Session; reviewer roles). docs.beyondtrust.com/bips/docs/ps-sessions - BeyondTrust Docs — Password Safe API: Sessions, Session Locking & Termination (POST Requests/{requestID}/Sessions with SessionType; POST Sessions/{sessionID}/Lock|Terminate; ManagedAccounts/ManagedSystems bulk terminate; session status codes). beyondtrust.com/docs/beyondinsight-password-safe/ps/api/password-safe/sessions.htm - BeyondTrust Docs — Configure Password Safe Access Policies (Record Session, Keystroke Logging, Enhanced Session Auditing default-on, Concurrent, Force Termination, Log off on Disconnect). docs.beyondtrust.com/bips/docs/ps-configure-access-policies - BeyondTrust Docs — Resource Broker installation (Session Monitoring among the 9 broker services; 64 GB session-cache disk requirement). docs.beyondtrust.com/bips/docs/ps-cloud-resource-broker-install - BeyondTrust Beekeepers community — retention policies and session-recording storage duration thread (real-world retention sizing pain). beekeepers.beyondtrust.com/general-40/password-safe-documentation-on-retention-policies-and-session-recording-log-storage-duration-7441 - PeerSpot — BeyondTrust Password Safe pros & cons (session recording praised; field reports of RDP drops without error and occasional keystroke-capture gaps). peerspot.com/products/beyondtrust-password-safe-pros-and-cons - IdentitySkills — CyberArk vs BeyondTrust vs Delinea, which PAM to learn in 2026 (session monitoring concepts transfer across platforms; India job-market angle). identityskills.com/blog/cyberark-vs-beyondtrust-vs-delinea-which-pam-tool-should-you-learn-in-2026/ ### What's next? Humans now request, connect and get recorded — but half your passwords are not held by humans at all. They are hardcoded in scripts, CI pipelines and app configs. Next: Secrets Safe and the API patterns that pull credentials at runtime so nothing secret ever lives in code again. Next · Secrets Safe & killing hardcoded credentials via API → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt