PRA Vault & Credential Injection: — Sessions Where Nobody Sees the Password

① PRA Vault — the credential store you already own

The Jump Technology lesson got Sneha (Infosys, PRA admin) to any server through Jump Items. One question was left hanging: when the RDP login appears, where does the password come from? If the answer is "the engineer knows it", you have rebuilt the old problem with extra steps. PRA's answer ships in the box: open /login > Vault and the Accounts tab loads by default, with sub-pages for User Permissions, Account Groups, Account Policies, Endpoints, Services, Domains, Discovery, Options and Connections. A vault admin owns three jobs: stock it (add or discover accounts), wire it (associate accounts to Jump Items), and keep it fresh (rotation).

What can it hold? The Add menu for shared accounts lists Username and Password, Single Token, Private Key, SSH Private Key with Certificate, SSH Certificate Authority, X.509 Parent Certificate Authority and X.509 Client Certificate. Personal accounts (username/password, token, keys) are owner-only, capped at 50 per user. The whole Vault can import, rotate and manage up to 100,000 accounts. Every account lands in an Account Group (or the built-in Default Group), and Account Policies decide rotation and check-out behaviour. SSH keys must be OpenSSH/PKCS8 format — and keep this one for interviews: the Vault can act as an SSH Certificate Authority, issuing per-session certificates with a five-hour TTL.

Four account types you will actually touch

Tap each card — the Add menu makes more sense once you know what each type is for.

Stocking 500 accounts by hand is how vaults die unloved. Vault > Discovery does it for you — with two prerequisites people forget: a Windows Jumpoint in the target domain (Linux Jumpoints cannot run discovery) and a management account with rights to enumerate. Discovery walks the domain across four tabs — Endpoints, Local Accounts, Domain Accounts and Services (Windows service accounts; this tab needs the other three selected) — showing username, endpoint, password age and last login, so you import with eyes open. It is the census enumerator pattern: the Jumpoint is the booth officer, the management account is his government ID letter, and HQ (you) decides whom to register. Entra ID Domain Services accounts can be discovered too, via a Microsoft Entra ID service principal.

Now the freshness job. The Vault rotates passwords on three automatic triggers: a manual check-in from /login, leaving a session in which credential injection was used, and a password reaching max age under Scheduled Password Rotation. There is also a manual button — Vault > Accounts > ellipsis (…) > Rotate Password — and the generator follows NIST guidance. Trigger ② is the one to tattoo on your brain: it means a vendor session can end with the very credential the appliance used already dead. Enable the behaviours via Account Policy options like Automatically Rotate Credentials after Check In and Scheduled Password Rotation.

# 1. OAuth 2.0 client-credentials token — API account made in /login > Management > API Configuration
curl -s -X POST -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  https://pra.lab.techclick.in/oauth2/token

# 2. List Vault accounts through the Configuration API
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://pra.lab.techclick.in/api/config/v1/vault/account"

{"access_token":"eyJhbGciOiJSUzI1NiIs...","token_type":"Bearer","expires_in":3600}
[
 {"id":12,"type":"username_password","name":"SQLPROD01 local admin","username":"svc-dbadmin","account_group_id":4},
 {"id":13,"type":"ssh","name":"netops jump key","username":"netops","account_group_id":7}
]

② Credential injection — Connect, and the password stays invisible

A stocked Vault helps nobody until PRA knows which credential belongs on which Jump Item. That wiring is Jump Item Associations, set on the account or once on its Account Group, with four options: Inherited from Account Group, Any Jump Items, No Jump Items, and the precision tool — Jump Items Matching Criteria, filtering on Name, Hostname/IP, Tag or Comments (each filter up to 64 characters). Get this wrong in either direction and you have a problem: too wide and the domain admin credential is offered on every intern's test box; too narrow and the dropdown at session start is mysteriously empty.

Now the user experience that sells PAM to management. In the access console, Rahul (Flipkart NOC) selects the SQL-PROD-01 Remote RDP Jump Item and clicks Jump. Because an associated Vault account exists, a credential dropdown appears — he picks FLIPKART\svc-dbadmin and the appliance pulls the secret and places it directly into the RDP authentication handshake, server-side. The password is never rendered on screen, never on his clipboard, never typed. It is credential injection — valet parking for credentials: the valet drives your car into the basement; you never touch the key. Injection works across RDP, Shell Jump, Web Jump and Windows sessions, and PRA 25.3 extends it into SQL protocol tunnels.

Be precise about the claim — interviewers test it. A keylogger on the vendor laptop still captures what the vendor types inside the session (commands, file names). What it can never capture is the target password, because that secret never crossed the vendor's keyboard or screen. Contrast injection with the Vault's other consumption mode: check-out, which reveals a shared credential for use outside a session. Check-out has legitimate uses for internal admins — but every check-out means a human now knows the secret, which is exactly the condition injection exists to prevent. Design rule: vendors are injection-only.

③ PRA Vault vs Password Safe — one vault, both doors

Here is the question every PRA admin eventually faces in a design review: "We have a vault in PRA — do we still need Password Safe?" Answer it by listing what the built-in Vault deliberately does not do. It has no approval workflow on credential release — no dual control, no ticket validation before a secret is used (PRA puts approvals at the session layer instead, via Jump Policies). It has no functional account machinery for deep platform rotation — databases, network devices, custom platforms — and no dependency mapping for service accounts (rotate a Windows service account without updating its services and you cause the outage yourself). No Smart Rules onboarding engine, no ISA role, no 525600-minute release governance. The PRA Vault is honest about its job: store, associate, inject, rotate — for credentials consumed inside PRA sessions.

Flip it around and the built-in Vault is enough more often than vendors of bigger vaults admit. If your estate is PRA-first — vendor access, internal admin sessions, a few thousand endpoint credentials, all consumed at Connect — then discovery + association + injection + rotate-on-session-end covers the whole loop with zero extra infrastructure. The honest sizing question is not "which vault is better?" but "where is the credential consumed, and does its release need workflow?" Consumed inside PRA sessions with no release workflow → built-in Vault. Released to humans/apps under approval, rotated across DB and network platforms, dependency-aware → Password Safe.

The bridge has two generations. Classic: the Endpoint Credential Manager (ECM), a service that brokers credentials from Password Safe into PRA sessions — it ships pre-installed with Password Safe, and the same plugin framework fronts CyberArk and other third-party stores. The engineer's experience is identical to section ②: click Connect, pick the credential, work — except the secret now comes from Password Safe's vault, with Password Safe's rotation and policy behind it. New generation: PRA 25.3 (late 2025) connects to Password Safe directly, no ECM middleware, adds automated Import Rules (auto-import discovered accounts and endpoints), and rounds out credential injection for SQL protocol tunnels. Either way the prize is the same: one vault, both doors — no duplicated secrets drifting out of sync, one rotation engine, one audit story.

# The deep-vault side of the bridge: confirm the account is managed and API-visible
curl -s -c /tmp/ps.jar -X POST \
  -H "Authorization: PS-Auth key=9f2c...77ab; runas=icici\\svc-pra-bridge;" \
  https://icici.ps.beyondtrustcloud.com/BeyondTrust/api/public/v3/Auth/SignAppIn

curl -s -b /tmp/ps.jar \
  "https://icici.ps.beyondtrustcloud.com/BeyondTrust/api/public/v3/ManagedAccounts?systemName=SQLPROD01"

200 OK              (SignAppIn — session established, cookie stored)
[{"ManagedAccountID":2031,"AccountName":"sa-dbadmin","SystemName":"SQLPROD01",
  "ChangeFrequencyType":"xdays","ReleaseDuration":120,"IsISAAccess":false}]
# this is the credential ECM / the 25.3 direct connector offers inside PRA at Connect

④ The vendor scenario end-to-end — three Jump Items, zero passwords

Now assemble everything this series has built into the scenario PRA was born for. Arjun is an OEM support engineer — his company supplies the load balancers ICICI runs — and he needs to maintain exactly three boxes. The old answer (site-to-site VPN + a shared admin password on WhatsApp) hands him the whole network and a secret he keeps forever. Meera, ICICI's PAM admin, builds the PRA answer in five layers: identity — Arjun signs in through SAML federated to the OEM's own IdP, with MFA enforced (vendor onboarding and groups live under /login > Users & Security > Vendors, identity sources under Security Providers); scope — a Jump Group holding only those three Jump Items, granted through the vendor group policy with Jump Item Role Start Sessions Only; conduct — a Jump Policy adding notifications and (if you want a human gate) Jump Approval; credentials — Vault accounts associated to those three items, injection-only; evidence — recordings on, reports reviewed.

The evidence layer deserves respect, because it is what auditors actually consume. Session logs stay on the appliance in uneditable form for up to 90 days; recordings export through the Integration Client (recordings as .flv, logs as .xml) or the API, and every authentication and session event can ship to your SIEM via syslog (UDP 514, or TLS on TCP 6514). Vault activity has its own trail — Reports > Vault shows who injected, checked out or rotated which account and when. When the RBI auditor asks "who touched the load balancer on the 14th?", Meera answers with a session recording, an injection event, and a rotation timestamp — not with a WhatsApp screenshot.

Turn the story into a recipe you can run at any company. 1) Inventory what the vendor must touch — items, not subnets. 2) Federate their identity (SAML to their IdP, MFA on) so offboarding happens at the source. 3) Scope a Jump Group to exactly those items; grant it via group policy with Start Sessions Only. 4) Vault every target credential, associate it to those items, vendors injection-only. 5) Jump Policy: notifications, approval if the asset is tier-0, recordings never disabled. 6) Schedule the evidence loop — export recordings before the 90-day window, review Vault reports monthly. That is least privilege as a checklist, not a slogan.