# PRA Vault & Credential Injection: — Sessions Where Nobody Sees the Password Source: https://ai.techclick.in/blog_beyondtrust_pra_vault_injection Markdown: https://ai.techclick.in/blog_beyondtrust_pra_vault_injection.md Publisher: Techclick Infosec Pvt Ltd PRA Vault & credential injection: account types, discovery, rotation, Jump Item Associations, Password Safe integration via ECM or direct, and vendor least… PRA Vault & Credential Injection: — Sessions Where Nobody Sees the Password student learning map A visual study map for PRA Vault & Credential Injection: — Sessions Where Nobody Sees the Password showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP PRA Vault & Credential Injection: — Sessions Where... 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 ① PRA Vault — the credential store... 4. Practice ② Credential injection — Connect,... 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 the PRA Vault is just a mini Password Safe — so a company must pick one vault or the other, and a serious shop should ignore the built-in one. Wrong on both counts. They are built for different jobs : the PRA Vault exists to feed credential injection into PRA sessions — store, associate, inject, rotate — while Password Safe owns the full enterprise credential lifecycle (approval workflows, functional accounts, dependency rotation, database and network platforms). And you never have to choose: through ECM — or the direct integration in PRA 25.3+ — Password Safe managed credentials inject straight into PRA sessions . One vault, both doors. ## ① 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 . 👉 So far: the Vault lives at /login > Vault (Accounts tab default), holds shared + personal accounts of 7 types, max 100,000, grouped and policy-ruled. Next: how it gets stocked without typing 500 accounts by hand. Figure 1 — The Vault inside the appliance — stock, wire, re-key Architecture diagram. In the centre, the B Series appliance in the DMZ contains the PRA Vault, which holds up to one hundred thousand accounts, shared and personal, plus an SSH certificate authority. Below the vault, an injection engine lends credentials to sessions without ever showing them. On the left, the slash-login Vault menu lists Accounts, Account Groups, Account Policies, Domains, Discovery, Options and Connections. On the right, a Windows Jumpoint with a management account enumerates the Active Directory domain — endpoints, local accounts, domain accounts and Windows services — and selected accounts are imported back into the Vault. A bottom band lists the three automatic rotation triggers plus the manual Rotate Password path. - One locker room, three jobs — stock it, wire it, re-key it /login > Vault Accounts (default tab) Account Groups · Policies Domains · Endpoints · Services Discovery · User Permissions Options · Connections the vault admin lives here B Series Appliance · DMZ · pra.lab.techclick.in 🔐 VAULT up to 100,000 accounts shared · personal (50/user) · keys · SSH-CA · X.509 grouped in Account Groups, ruled by Account Policies INJECTION ENGINE sessions borrow the secret — humans never hold it ← the secret never leaves this box — sessions get a handshake, humans get nothing discovery job Windows Jumpoint + management account (its ID letter) corp.flipkart.local Endpoints · Local Accounts Domain Accounts · Services (Win) password age · last login shown select → import → managed RE-KEY — three automatic rotation triggers + one manual ① manual check-in from /login ② session ends — injection was used in it ③ password hits max age (scheduled) manual: Vault > Accounts > … > Rotate Password · generator follows NIST guidance untrusted/attacker trusted/vaulted policy/decision key insight allowed/audited Left: the /login Vault menu the admin works in. Centre: the Vault and injection engine inside the B Series appliance. Right: discovery — a Windows Jumpoint with a management account enumerates the domain, and you import what it finds. Bottom: the three automatic rotation triggers. ### Four account types you will actually touch Tap each card — the Add menu makes more sense once you know what each type is for. 🔑 Username & Password tap to flip The workhorse — Windows local admins, domain accounts, web logins. Rotatable, injectable into RDP and Web Jump. So: 90% of your Vault. 🗝️ SSH Private Key tap to flip OpenSSH/PKCS8 keys for Shell Jump injection — with or without a certificate. So: Linux fleets stop sharing one id_rsa on chat. 📜 SSH Certificate Authority tap to flip Vault signs short-lived certs per session — 5-hour TTL, nothing durable to steal. So: the cleanest SSH story in the product. 🪪 X.509 Certificates tap to flip Parent CA + client certs for systems that authenticate with certificates instead of passwords. So: cert-auth web consoles get vaulted too. 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 . /login → Vault → Accounts → Add → Shared Account (Username and Password) . Real field labels. (Recreated for clarity — your console matches this.)"> 🖥️ Where the vault admin works — /login → Vault → Accounts → Add → Shared Account (Username and Password) . Real field labels. (Recreated for clarity — your console matches this.) pra.lab.techclick.in/login · Vault → Accounts 1 Name SQLPROD01 local admin 2 Account Type Username and Password 3 Username svc-dbadmin Password •••••••••••••••• (Generate) Account Group DB-Tier (policy: rotate after injection) 4 Jump Item Associations Jump Items Matching Criteria Save 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 . Sneha at Infosys faces this Sneha sets up Vault discovery for corp.infy.local — but the domain cannot be configured for a scan. The only Jumpoint in that segment is the Linux one the team uses for Shell Jump sessions, and discovery refuses to use it. Likely cause Vault Discovery runs only through a WINDOWS Jumpoint — it enumerates the domain with Windows APIs using the management account. A Linux Jumpoint can carry RDP/SSH/VNC sessions, but it cannot run discovery. Diagnosis Check the platform of every Jumpoint registered for that network segment, then check what the Domains page requires: a domain, a Jumpoint selection, and a management account. /login > Vault > Discovery (+ /login > Vault > Domains for the management account binding) Fix Deploy a Windows Jumpoint host inside the domain (it can sit beside the Linux one), bind the management account, and run discovery again. Keep the Linux Jumpoint for sessions — the two jobs are different. Verify Discovery returns results across the four tabs (Endpoints, Local Accounts, Domain Accounts, Services). Sneha imports 12 accounts with visible password-age data, and they appear under Vault > Accounts in the DB-Tier group. PRA Configuration API — token, then list Vault accounts (admin workstation) # 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" Expected output {"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} ] Quick check · Q1 of 10 Which of these is one of the THREE automatic rotation triggers in the PRA Vault? a) The appliance completes its nightly configuration backup b) A Jump Client on the endpoint upgrades to a new version c) A user leaves a session in which the credential was injected d) The vendor's SAML session token expires Correct: c. The three automatic triggers are: manual check-in from /login, leaving a session in which credential injection was used, and the password reaching max age under Scheduled Password Rotation. Backups, Jump Client upgrades and SAML token expiry have nothing to do with credential rotation — they are plausible-sounding noise. Pause & Predict Predict: Infosys discovery finds 1.2 lakh domain accounts and Sneha tries to import them all into the PRA Vault. What stops her? Type your guess. Reveal answer Answer: The ceiling. The PRA Vault manages up to 100,000 accounts — 1,20,000 will not fit, and personal accounts are further capped at 50 per user. More importantly, an estate that size with service-account dependencies is Password Safe territory — exactly the decision section ③ teaches. Import what PRA sessions actually consume; let the enterprise vault own the rest. ## ② 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. /login → Vault → Accounts → (svc-dbadmin) → Jump Item Associations . This decides where the credential is offered. (Recreated for clarity.)"> 🖥️ The wiring panel — /login → Vault → Accounts → (svc-dbadmin) → Jump Item Associations . This decides where the credential is offered. (Recreated for clarity.) pra.lab.techclick.in/login · Vault → Accounts → svc-dbadmin 1 Jump Item Associations Jump Items Matching Criteria 2 Filter — Hostname/IP 172.16.8.21 3 Filter — Tag sql-prod Filter — Name (blank — max 64 chars per filter) Filter — Comments (blank) Save 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 . 👉 So far: association decides WHERE a credential is offered; injection puts it into the protocol handshake so the human never holds it. Next: watch one injected session end-to-end — then watch it break. ### ▶ One injected RDP session, end to end Follow Rahul from the Jump click to rotation — the credential moves, but only on the appliance side of the glass. Press Play for the healthy path, then Break it to see the failure. ① Connect rahul@flipkart → Jump on SQL-PROD-01 (172.16.8.21) ▼ ② Offer credential dropdown ← Vault matches association · FLIPKART\svc-dbadmin ▼ ③ Inject appliance → RDP handshake: secret injected server-side · never displayed ▼ ④ Rotate session ends → trigger ② fires: password rotated · recording stored Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Figure 2 — Typed password vs injected credential — what the same keylogger gets Before and after comparison. Left, red panel: the vendor receives the admin password on chat, types it into the RDP prompt, a keylogger on the vendor laptop captures every keystroke, and an attacker reuses the captured password for months from anywhere. Right, green panel: the credential lives in the PRA Vault, the vendor clicks Connect and picks the account from a dropdown, the appliance injects the secret into the RDP handshake on the server side, and the same keylogger captures session keystrokes but no target password, because the password never crossed the vendor keyboard. Bottom line: the vendor cannot leak what the vendor never knew. Same vendor laptop, same keylogger — only the password path differs BEFORE — the vendor types the password password on chat Adm1n@2026! vendor TYPES it into the RDP prompt ⌨️ keylogger captures EVERY key A-d-m-1-n-@-2-0-2-6-! attacker replays it for MONTHS from anywhere — looks like a normal login every typed password is a copy handed to the laptop — and you do not control the vendor's laptop AFTER — credential injection 🔐 Vault account associated to the Jump Item Connect → pick account dropdown — no secret shown appliance INJECTS into the RDP handshake — server side SAME keylogger still running it captures session keystrokes — but NO password: the secret never crossed the vendor's keyboard session is recorded · rotation after session end means even the appliance-used secret dies minutes later The vendor cannot leak what the vendor never knew. Left (red): the password crosses chat, keyboard and screen — one keylogger turns it into months of silent access. Right (green): injection moves the secret appliance-to-server; the same keylogger captures session keystrokes but no password, and rotation kills the borrowed secret anyway. 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 . MISTAKE — “Web Jump opens the page but the login form stays empty” Symptom: the Web Jump session renders the internal firewall GUI, an associated Vault account exists, but username/password fields never fill. Cause: the login form uses non-standard fields that injection's auto-detection cannot find. Fix: edit the Web Jump Item and set Username Field Hint / Password Field Hint / Submit Button Hint with the exact CSS selectors of the form elements. Remember the browser runs on the Jumpoint (Chromium-based), not on the user's laptop — so debug the selectors against the page the Jumpoint sees. Karthik at Flipkart faces this Karthik associates svc-dbadmin for the DB tier. On SQL-PROD-01 the credential dropdown offers it fine — but on SQL-PROD-02 (172.16.8.22) the dropdown is empty, and the NOC is typing passwords again. Likely cause The account uses Jump Items Matching Criteria with a single Hostname/IP filter: 172.16.8.21. SQL-PROD-02 does not match any criterion, so the Vault offers nothing on it. Diagnosis Open the account and read its Jump Item Associations panel; compare every filter against the second Jump Item's name, hostname and tags. The mismatch is visible in one screen. /login > Vault > Accounts > svc-dbadmin > Jump Item Associations Fix Tag both SQL Jump Items sql-prod and switch the filter to Tag = sql-prod (≤64 chars). Better long-term: set the association once on the DB-Tier Account Group and let accounts inherit. Verify Jump to SQL-PROD-02 again — the dropdown now offers svc-dbadmin; the session authenticates with no typed password, and the Vault report logs an injection event for the account. Quick check · Q2 of 10 At session start on an associated Jump Item, what does Rahul actually interact with? a) A credential dropdown — he picks the Vault account, and the secret is injected without ever being displayed b) A popup showing the plaintext password for 20 seconds c) An OTP challenge sent to the server owner's phone d) A field where he types the functional account password Correct: a. Injection keeps the human out of the secret path: pick the account, the appliance does the handshake. The 20-second plaintext view is a Password Safe RETRIEVE behaviour, not PRA injection; OTP-to-owner is not a PRA mechanism; and functional accounts belong to Password Safe rotation, not PRA session auth. Pause & Predict Predict: Meera's injected Shell Jump session authenticated with a certificate issued by the Vault's SSH Certificate Authority. She extracts the cert from memory to reuse tomorrow morning. Does it work? Type your guess. Reveal answer Answer: No. Vault SSH-CA certificates issued for injection carry a five-hour TTL — by tomorrow it is an expired file, useless even if perfectly exfiltrated. Short-lived certificates are the SSH equivalent of rotate-after-session: do not chase the thief, just make the loot expire. ## ③ 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. 👉 So far: PRA Vault = injection-first store; Password Safe = full lifecycle (workflows, functional accounts, platform depth). Next: the bridge that lets one credential serve both — without ever being copied. Figure 3 — One vault, both doors — Password Safe behind PRA Integration diagram. Left box: Password Safe on the BeyondInsight platform — the deep vault owning dual-control approvals, functional accounts and dependency rotation, database and network device platforms, the session proxy on ports 4422 and 4489, and Smart Rules at scale. Right box: the PRA appliance — the access door with Jump Items, Jump Policies, the built-in injection-first Vault and outbound-443 vendor access. Two bridges connect them: the classic Endpoint Credential Manager service, which ships pre-installed with Password Safe and also fronts third-party vaults, and the PRA 25.3 direct connection that needs no ECM and adds Import Rules and SQL-tunnel injection. A bottom strip says when the built-in PRA Vault alone is enough and when to bring Password Safe. One vault, both doors — Password Safe owns the lifecycle, PRA opens the session PASSWORD SAFE (BeyondInsight) the deep vault — lifecycle owner • dual-control approvals + ticket validation • functional accounts + dependency rotation • DBs, network devices, custom platforms • session proxy :4422/:4489 + keystrokes • Smart Rules onboarding at 10k+ scale credential lives HERE — once PRA (B Series appliance) the access door — vendors & admins • Jump Items + Jump Policies + approvals • built-in Vault (injection-first, ≤100k) • outbound-443 vendor access, no VPN • session recordings + audit reports • credential dropdown at Connect credential is BORROWED here — per session classic: ECM service pre-installed with Password Safe also fronts CyberArk & others 25.3+: DIRECT no ECM · Import Rules SQL-tunnel injection The credential lives ONCE in Password Safe · PRA borrows it at Connect · the vendor sees neither vault no copy-paste between vaults, no drift, one rotation engine, one audit story PRA Vault alone is enough when… • credentials are consumed INSIDE PRA sessions • scale 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. 👉 So far: identity (SAML+MFA) → scope (Jump Group + Start Sessions Only) → conduct (Jump Policy) → credentials (injection-only) → evidence (recordings). Watch it run — and watch where lazy group policy breaks it. ### ▶ A vendor session, end to end Arjun's Tuesday: from SAML sign-in to a rotated credential — least privilege at every hop. Press Play for the healthy path, then Break it to see the failure. ① Sign in arjun@oem-vendor.com → SAML IdP + MFA → vendor account on /login ▼ ② See access console shows exactly 3 Jump Items · Jump Group: Vendor-LB · role: Start Sessions Only ▼ ③ Session injected RDP via Jumpoint → 192.168.40.18 · recording ON · no password shown ▼ ④ Close recording + session log stored · credential rotated (trigger ②) · audit complete Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset 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. Aditya at Airtel faces this A quarterly audit at Airtel finds the OEM vendor account VIEWED the firewall admin password twice last month — the Vault report shows check-out events, not injection. Policy says vendors are injection-only. Likely cause The vendor group policy inherited Vault permissions meant for internal admins, so vendor users could check out shared accounts and read the secret — injection-only was an intention, never an enforced setting. Diagnosis Read the Vault report for the account and classify each event (injection vs check-out vs rotation), then open the vendor group policy and audit exactly which Vault permissions it grants. /login > Reports > Vault (+ /login > Users & Security > Group Policies > vendor group) Fix Strip check-out rights from the vendor group's Vault permissions so vendor users can consume credentials only through the session dropdown; rotate the exposed firewall password immediately (Vault > Accounts > … > Rotate Password). Verify Sign in as the vendor test account: the credential still appears at Connect, but no path exists to view or check out the secret. The next Vault report shows injection and rotation events only — which is what the auditor files. MISTAKE — “the vendor reorganised our Jump Groups” Symptom: Jump Items renamed, moved, even deleted — by a vendor account. Cause: the vendor group policy granted the default Administrator Jump Item Role (which can create, move and remove Jump Items) instead of Start Sessions Only . Remember role resolution: the most specific user↔Jump Group relationship wins, so one careless group policy quietly overrides your safer defaults. Vendors get Start Sessions Only — full stop. Your compliance team gets the Auditor role (v25.2+, exactly one permission: View Reports). Figure 4 — The vault decision card — everything on one screen Cheat sheet. Top tiles: Vault account types — username and password, single token, private key, SSH key with certificate, SSH certificate authority, X.509, with personal accounts capped at fifty per user; numbers to memorise — one hundred thousand account cap, five-hour SSH-CA certificate TTL, ninety-day recording retention, sixty-four character association filters; the three rotation triggers; and the injection checklist from adding the account to picking it at Connect. Bottom: a four-row decision matrix mapping scenarios to PRA Vault, Password Safe, or the integration, plus the vendor blueprint one-liner. PRA Vault & injection — the one-card revision sheet Account types (Add menu) Username & Password · Token Private Key · SSH key + cert SSH Certificate Authority X.509 parent / client cert personal: max 50 per user Numbers to memorise 100,000 — account cap 5 hours — SSH-CA cert TTL 90 days — recordings on appliance 64 chars — association filter max 50 — personal accounts per user Rotation triggers ×3 ① manual check-in (/login) ② session end after injection ③ max password age (schedule) Vault > Accounts > … > Rotate Password (manual) Injection checklist 1 add/import account 2 Account Group + Policy 3 Jump Item Association 4 user: Jump → pick account 5 injected — never shown Which vault for which job? — the decision matrix Scenario Use Why Vendor RDP/SSH consumed inside PRA only PRA Vault inject at Connect, rotate after session Tier-0 release needs dual-control approval Password Safe approval workflow lives there Service accounts w/ dependencies, DBs, network Password Safe dependency mapping + platform depth PS-managed credential inside a PRA session Integration ECM (≤25.2) · direct, no ECM (25.3+) Vendor blueprint: SAML + MFA · one Jump Group, 3 items · Start Sessions Only · injected credential · recording ON · rotate after session memorise this line — it answers the most common PAM interview scenario Top: account types, the numbers (100k / 5h / 90d / 64 chars / 50), rotation triggers and the injection checklist. Bottom: the decision matrix — which vault for which job — and the vendor blueprint line to recite in interviews. 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. 🎮 Hands-on: BeyondTrust PAM Essentials room Recap: PRA Jump Technology Deep-Dive Quick check · Q4 of 10 A vendor signs in and sees 14 Jump Items instead of the 3 they support. What do you check FIRST? a) The appliance license count under /appliance b) Which Jump Groups the vendor's group policy grants, and with which Jump Item Role c) The SSL certificate expiry on the B Series appliance d) The vendor laptop's local firewall rules Correct: b. What a user sees in the Jump interface is authorization: Jump Group memberships and roles granted through group policies. Fourteen visible items means the vendor group policy grants too much — likely a broad Jump Group or an extra membership. Licensing, certificates and the laptop firewall affect connectivity, not item visibility. Pause & Predict Predict: 120 days after Arjun's session, Legal asks for the recording. What does Meera find on the appliance — and what should she have done? Type your guess. Reveal answer Answer: Nothing — session data stays on the appliance for up to 90 days, so day 120 is past retention. The design answer: schedule the Integration Client (or API export) to pull recordings (.flv) and session logs (.xml) into long-term storage continuously, sized to your compliance retention (RBI expectations commonly exceed 90 days). Evidence you did not export is evidence you do not have. VERIFY — prove the whole lesson in your lab Run the chain once, cold: add a Vault account → associate it by Tag to one Jump Item → Jump and confirm the dropdown offers it → complete an injected session typing no password → confirm the rotation event fired at session end (Vault report) → sign in as a vendor test user and count visible Jump Items → confirm no check-out path exists for that user. If you can demo those seven steps, you can answer every Vault-and-injection question an interviewer has. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Can a vendor ever SEE a Vault password? What happens to the password right after an injected session ends? Why does Vault Discovery insist on a Windows Jumpoint? Does injection work on web consoles like a firewall GUI? ECM or the 25.3 direct integration — which should we deploy? PRA Vault vs Password Safe in one interview answer? 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 In the PRA /login admin console, where does the built-in Vault live, and which tab opens by default? a) /appliance > Security > Vault — the Certificates tab b) /login > Vault — the Accounts tab opens by default c) /login > Asset Management > Vault — the Endpoints tab d) Only in the desktop access console, under a Vault tab Correct: b. The Vault is a top-level /login menu whose Accounts tab loads by default, with sub-pages like Account Groups, Account Policies, Domains and Discovery. /appliance is the OS/patching interface, not credential storage; Asset Management holds Jump configuration (Gateways, Assets), not the Vault; and the access console only CONSUMES vault credentials via the dropdown — it does not manage them. Q6 · Apply Priya (Wipro) wants WIPRO\svc-sql offered for injection ONLY on the three SQL production RDP Jump Items — nowhere else. Where does she enforce that? a) Account Policy → enable Scheduled Password Rotation b) Jump Item Associations → Any Jump Items c) Convert it to a personal account so only she can see it d) Jump Item Associations → Jump Items Matching Criteria, filtering on a sql-prod Tag (or Hostname/IP) Correct: d. Matching Criteria is the scoping tool: filter on Name, Hostname/IP, Tag or Comments (≤64 chars each) and the account is offered only where a criterion matches — tagging the three Jump Items sql-prod is the rename-proof way to express it. Rotation policies control freshness, not placement; Any Jump Items is the exact opposite of scoping; personal accounts hide the credential from the team without controlling which items offer it. Q7 · Apply An OEM engineer must RDP to one ICICI server through PRA without ever learning the local admin password. Which build is correct? a) Add the local admin to the Vault, associate it with that Remote RDP Jump Item, and let the engineer pick it from the credential dropdown at Connect — injection completes the login b) Let the engineer check the password out, type it into the RDP prompt, and rotate it next quarter c) Send the password in a password-protected PDF before each scheduled session d) Give the engineer VPN access and let them run mstsc directly to the server Correct: a. Vault + association + injection is the zero-knowledge path: the secret moves appliance-to-server, never to the engineer. Check-out reveals the secret to a human — the exact thing to avoid for vendors — and quarterly rotation leaves a months-long exposure window; a PDF is just slower WhatsApp; VPN + direct RDP grants network access with no brokering, no recording and no injection at all. Q8 · Analyze A keylogger runs silently on a vendor laptop during an injected RDP session to 192.168.40.18. Which statement is TRUE about what it captures? a) It captures the server admin password as the vendor types it into the RDP prompt b) It captures the Vault's master encryption key from the session stream c) It captures what the vendor types INSIDE the session — but no target password, because the secret went from the appliance into the RDP handshake and never crossed the vendor's keyboard d) It captures nothing at all, because injection encrypts the vendor's keyboard Correct: c. Be precise: injection removes the PASSWORD from the vendor side; it does not blind the laptop. Session keystrokes (commands, filenames) are still typed and still keyloggable — which is why recordings matter — but there is no authentication secret to steal because it was never typed. Option a describes the pre-injection world; b invents a key that never leaves the appliance; d overclaims — injection is not keyboard encryption. Q9 · Analyze Flipkart needs dual-control approval before tier-0 credentials release, rotation of service accounts WITH dependency updates across 4,000 Windows systems, and database platform rotation. They already run PRA. What is the honest architecture call? a) The PRA Vault handles all of this — just enable Account Policies b) Bring Password Safe in for the credential lifecycle and keep PRA as the access door — injecting Password Safe managed credentials into PRA sessions over the integration c) Replace PRA with Password Safe, since one product must win d) Maintain a copy of every credential in both vaults and rotate both nightly Correct: b. Each requirement names a Password Safe capability the PRA Vault deliberately lacks: release approval workflows with dual control, functional-account driven rotation with service dependency mapping, and database platform depth. But PRA stays — it is the session broker and vendor door — and the ECM/direct integration injects Password Safe credentials into PRA sessions. Replacing PRA loses the access layer; duplicating credentials creates drift and doubles the attack surface. Q10 · Evaluate Two vendor-access designs at Airtel. A: site-to-site VPN + a shared local admin password on WhatsApp, changed quarterly. B: SAML+MFA vendor accounts, a Jump Group with exactly the needed items as Start Sessions Only, injected Vault credentials, recordings ON, rotation after each session. An auditor asks which is defensible — and why. a) A — the VPN is encrypted, so sharing the password over chat is acceptable b) Both are equal as long as the password is 16+ characters c) B — but only because MFA is present; the rest is cosmetic d) B — every control maps to evidence: identity is federated and MFA-gated, scope is three items not a network, the secret is never known to the vendor, sessions are recorded, and rotation kills the borrowed secret — A fails on every one of those points Correct: d. Defensibility = evidence per control. Design B answers who (SAML+MFA, offboarded at the OEM's IdP), what (three Jump Items), how (injection — no human knows the secret), and what happened (recordings + Vault events + rotation timestamps). A's VPN encryption protects transit, not scope or secrecy — the password is standing knowledge for months across an unknown set of people. Password length (b) does not fix exposure; and MFA alone (c) ignores scope, secrecy and evidence, which carry equal audit weight. 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 is an injected credential safer than a strong password the vendor types? Then compare to the expert version. Compare with expert answer Expert version: Because the vendor never learns it — there is nothing to keylog, photograph, save or reuse after the session; the secret moves appliance-to-server inside the handshake, and rotation at session end kills even the copy the appliance used. ### 🗣 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 Vault & Injection at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Vault (PRA) PRA's built-in credential store at /login > Vault — imports, rotates and injects up to 100,000 accounts. Credential injection The appliance places a vaulted secret straight into the RDP/SSH/web handshake — the user authenticates without ever seeing it. Jump Item Association Per-account/group setting deciding which Jump Items an account is offered on: Inherited / Any / None / Matching Criteria (Name, Hostname/IP, Tag, Comments). Shared account Vault account usable by permitted users; types include username/password, tokens, SSH keys and X.509 certificates. Personal account Owner-only Vault account — invisible to everyone else; capped at 50 per user. Check-out / check-in Retrieving a shared credential for use OUTSIDE a session, then returning it; check-in can trigger rotation. Vendors should not have it. Vault Discovery Domain/endpoint scan via a Windows Jumpoint + management account; tabs: Endpoints, Local Accounts, Domain Accounts, Services. Management account The credential discovery uses to connect to the domain and enumerate accounts — the census enumerator's ID letter. SSH Certificate Authority Vault mode that issues short-lived (5-hour TTL) certificates for injected SSH sessions — nothing durable to steal. Account Policy (Vault) Rotation/check-out rules for accounts or groups — e.g. Automatically Rotate Credentials after Check In, Scheduled Password Rotation. ECM Endpoint Credential Manager — middleware brokering Password Safe (or third-party vault) credentials into PRA sessions; optional for Password Safe since PRA 25.3. Import Rules PRA 25.3+ automation that auto-imports discovered accounts/endpoints from the direct Password Safe connection. #### 📚 Sources BeyondTrust Docs — PRA Vault Guide (discovery & import, rotation, injection, check-in/check-out, account groups & policies, SSH-CA). docs.beyondtrust.com/pra/v24.3/docs/vault - BeyondTrust Docs — Vault Account Types & Jump Item Associations (Add-menu type list, 100,000-account capacity, 50 personal accounts per user, 5-hour SSH certificate TTL). docs.beyondtrust.com/pra/v25.2/docs/cloud-vault-accounts - BeyondTrust Docs — Vault Account Rotation (the three automatic triggers; Vault > Accounts > … > Rotate Password; NIST-based generator). docs.beyondtrust.com/pra/v24.3/docs/rotation - BeyondTrust Docs — Vault Discovery (Windows Jumpoint + management account; Endpoints / Local Accounts / Domain Accounts / Services tabs; Entra ID service principal). docs.beyondtrust.com/pra/v24.3/docs/vault-discovery - BeyondTrust Docs — BeyondInsight & Password Safe integration with PRA (Endpoint Credential Manager brokers Password Safe credentials into PRA sessions; ECM ships with Password Safe). docs.beyondtrust.com/pra/docs/beyondinsight-password-safe - BeyondTrust Blog — Privileged Remote Access 25.3 updates (direct Password Safe integration without ECM, automated credential Import Rules, SQL protocol-tunnel injection). beyondtrust.com/blog/entry/privileged-remote-access-25-3-updates - BeyondTrust Docs — BeyondInsight & Password Safe API usage (PS-Auth header, Auth/SignAppIn, ManagedAccounts — the deep-vault side of the comparison). docs.beyondtrust.com/bips/reference/beyondinsight-and-password-safe-api-usage - BeyondTrust University — Privileged Remote Access Administration course + certification (40-question exam, 75% pass, two attempts). beyondtrust.com/services/beyondtrust-university/privileged-remote-access-administration ### What's next? The vendor saw exactly three Jump Items — but WHO decided that, and through which policy chain? Next lesson dissects PRA access control end-to-end: group policies, Jump Item Roles, Jump Policies, schedules and approvals — the rulebook that decides who may jump where, when, and with whose permission. Next · PRA access control: group policies, roles & approvals → 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