Password Safe Access Workflows: — Requests, Approvals, Dual Control & JIT

① The request flow — what the requester sees, what the policy decides

It is 11:40 AM at Infosys, Bengaluru. Sneha (L1, infra team) needs the local admin password of Windows server 192.168.40.18 to restart a stuck service. She does not ping a senior on chat for it — she opens the Password Safe portal, finds the managed account, and clicks Request Access. The form asks for three things: a Reason (free text, maximum 200 characters — and it auto-fills from defaults so lazy admins still leave a trail), an optional ticket number, and a Request Duration (auto-filled from the account's default release duration — 120 minutes out of the box, with an absolute maximum of 525600 minutes, i.e. one year).

Whether that Request button even works is decided by the access policy. BeyondTrust's own definition is worth memorising: it “defines the time frame and frequency that users can request passwords, remote access sessions, or access applications.” In practice an access policy answers four questions. Who may request — the user groups the policy is assigned to, with the Requestor role on those accounts. What they may request — the schedule is built per access type: View Password, RDP, SSH or Application. When — schedule entries with day/time windows. From where — Enable Location Restrictions can pin requests to known networks (it matches on X-Forwarded-For, so only office or VPN ranges pass).

The detail that separates a working deployment from an angry NOC: one policy can hold multiple schedule entries with different rules. The classic pattern — a business-hours window (09:00–18:00) with Auto Approve ON for routine accounts, and an after-hours window where Approvers is set to 1 or more. Same accounts, same users; only the clock decides whether the credential releases instantly or waits for a human. Think of a gated society: registered residents walk in freely during the day, but a visitor at 11 PM triggers a phone call to the flat owner. Auto-approve is not “no security” — the request, the reason, the release and the session recording all still land in the audit trail.

The four Password Safe roles

Tap each card — every workflow question in interviews starts from these four.

② Approvals — one key, two keys, and the ticket that must be real

When a window is not auto-approve, the request lands with the Approver group mapped to that account. The number that matters sits right on the policy schedule: Approvers — how many must say yes. Set it to 1 and any one approver can release the credential. Set it to 2 and you have dual control — the SBI bank locker model: your key and the bank officer's key must turn together, or the locker stays shut.

Dual control is the default answer for tier-0: domain admin, root on the payments DB, the firewall enable account. The threat it kills is the single point of yes — one bribed insider, one compromised approver mailbox, one manager clicking too fast at 6 PM. Each approver sees the full request — who, which account on which system, the reason, the ticket, the duration — and approves or denies with a comment. Denials are not failures of the system; they are the system working, and they are first-class audit events.

Approvers do not live in the console all day — that is what email-based approval is for. The approval notification lands in the approver's mailbox with the request details, and they can act on it directly; an on-call manager can release a credential from a phone at midnight without VPN-ing into BeyondInsight. The flip side: your approval flow now depends on email delivery, which is the production gotcha below.

Now the gate most teams skip: ticket validation. Anyone can type “CHG0048213” into a reason box — that proves nothing. With the ITSM integration (ServiceNow, Jira and similar), the policy can require a ticket number and validate it against the ticket system: the ticket must exist, and it must be open. A closed, cancelled or fictional ticket = automatic denial before any human even looks. It is the society gate-pass rule: the guard does not accept “owner ne bola hai” — he checks the slip number against the register book.

③ Just-in-time — design it so there is nothing to steal afterwards

Standing privilege is any admin credential that is valid 24×7 and known to humans — the domain-admin password in passwords.xlsx, the root password every senior “just knows”, the firewall enable secret in a team chat from 2023. Every standing secret is a permanent attack surface: steal it once, use it for months. JIT (just-in-time) flips the model — privilege is manufactured when needed and destroyed when returned, so between checkouts there is no usable secret anywhere outside the vault.

Password Safe implements JIT with two settings you already met: the time-boxed checkout (release duration, default 120 minutes) and Change Password After Release — rotate-on-check-in. The moment Sneha checks the account back in (or the window expires), the rotation engine sets a fresh random password per the password policy. The library analogy: the book is issued for a fixed period, and the librarian re-jackets it the moment you return it — your photocopy of the old cover opens nothing. Pair it with Check Password tests so out-of-band changes get caught too (you saw that machinery in the rotation lesson).

One pattern deliberately sits outside the request-approval loop: break-glass. What if BeyondInsight itself is unreachable at 3 AM — appliance failure, network partition — or a P1 needs domain admin and both approvers are on a flight? Break-glass is the fire-alarm box: a separate emergency account (never anyone's daily account), its password sealed — printed and locked in a physical safe, or held in a secondary sealed store — with alarms wired to any use: a SIEM rule on its logon events, instant notifications to security leadership, immediate rotation after use, and a mandatory post-incident review. Smashing the glass is allowed; smashing it quietly must be impossible.

④ ISA, API automation & the audit trail end-to-end

Some power users skip the queue by design. The ISA role (Information Systems Administrator) retrieves credentials instantly, with no approval step — the senior doctor's all-access hospital pass, while everyone else signs the visitor register at reception. Releases still get time-boxed (ISAReleaseDuration, default 120 minutes) and still audit, but nobody says yes first. Grant it the way hospitals grant master passes: a small senior team, only on the accounts they own, membership reviewed quarterly — because every ISA grant is a standing ability to bypass the approval layer you spent section ② building.

The second queue-skipper is automation. An Ansible patch run or a backup script should never hold a hardcoded password — it should request one. The whole human workflow you just learned has a REST mirror under /BeyondTrust/api/public/v3: authenticate with POST Auth/SignAppIn (the PS-Auth header carries an API key from the API registration plus a runas Password Safe user), then POST Requests → GET Credentials/{requestId} → PUT Requests/{requestId}/Checkin. Application-type users can use OAuth client-credentials instead. Point the API caller's group at an API-friendly access policy window (auto-approve, View Password) so no human has to wake up at 01:00 to approve a backup job.

# 1. Sign in — API key + runas user (key from the API registration)
curl -s -c /tmp/ps.jar -X POST \
  -H "Authorization: PS-Auth key=8c1f0d2e...d2e9; runas=techclick\\svc-ansible;" \
  https://techclick.ps.beyondtrustcloud.com/BeyondTrust/api/public/v3/Auth/SignAppIn

# 2. Create the request (account 2031 on system 118, 30 min, View)
curl -s -b /tmp/ps.jar -X POST -H "Content-Type: application/json" \
  -d '{"SystemId":118,"AccountId":2031,"DurationMinutes":30,"Reason":"CHG0048213 nightly patch run","AccessType":"View"}' \
  https://techclick.ps.beyondtrustcloud.com/BeyondTrust/api/public/v3/Requests

# 3. Retrieve the credential, then check it back in (rotation fires per policy)
curl -s -b /tmp/ps.jar https://techclick.ps.beyondtrustcloud.com/BeyondTrust/api/public/v3/Credentials/8412
curl -s -b /tmp/ps.jar -X PUT -H "Content-Type: application/json" -d '{}' \
  https://techclick.ps.beyondtrustcloud.com/BeyondTrust/api/public/v3/Requests/8412/Checkin

200 OK            (SignAppIn — session established, cookie stored)
8412              (Requests — the new request ID, auto-approved by the API window)
"vK9#mQ2!xT7@pL4z"  (Credentials/8412 — returned to the caller, never logged)
204 No Content    (Checkin — release ended, rotation queued)

# ISA users skip Requests entirely — ISARequests returns the credential directly
curl -s -b /tmp/ps.jar -X POST -H "Content-Type: application/json" \
  -d '{"SystemId":118,"AccountId":2031,"DurationMinutes":15,"Reason":"INC0099231 — emergency diag"}' \
  https://techclick.ps.beyondtrustcloud.com/BeyondTrust/api/public/v3/ISARequests

200 OK
"qF3$wN8&jR5*hB2y"   (credential returned immediately — no approver involved)
# release is still time-boxed by ISAReleaseDuration (default 120 min)
# and the retrieval still lands in the audit trail

Now zoom out and read the audit trail end-to-end — the hotel master-key register, but automatic. One request ID stitches together six events: the request (who, which account/system, reason, ticket, requested duration) → the decision (approver names, comments, or “auto-approved by policy”) → the release (timestamp, window) → the session evidence (recording + keystrokes, if RDP/SSH) → the check-in → the rotation event. When the auditor asks “who touched the payments DB on the 14th and under which change?”, you answer with one request ID and replay the whole story — including the recording. That closed loop is what makes the workflow defensible, not just convenient.

Designing the matrix for a real org is a classification exercise, not a tooling one. Step 1: tier the accounts — tier-0 (domain admin, root on payment systems, firewall/network device admin), tier-1 (production servers, databases), routine (test/lab, low-blast-radius). Step 2: per tier, decide the five dials — window, Auto Approve or Approvers count, ticket required + validated, record + keystrokes, rotate-on-check-in (the answer to that last one is always yes). Step 3: implement each row as ONE access policy and let Smart Groups map thousands of accounts onto the four rows — a Flipkart-scale estate of 3,000 managed accounts genuinely runs on four or five well-named policies, not forty.