# Privileged Remote Access (PRA) Fundamentals: — Vendor Access Without the VPN Source: https://ai.techclick.in/blog_beyondtrust_pra_fundamentals Markdown: https://ai.techclick.in/blog_beyondtrust_pra_fundamentals.md Publisher: Techclick Infosec Pvt Ltd BeyondTrust PRA fundamentals: why vendor VPNs fail, the outbound-443 appliance model, PRA vs Remote Support vs VPN vs Password Safe, and vendor onboarding. Privileged Remote Access (PRA) Fundamentals: — Vendor Access Without the VPN student learning map A visual study map for Privileged Remote Access (PRA) Fundamentals: — Vendor Access Without the VPN showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Privileged Remote Access (PRA) Fundamentals: —... 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 ① The vendor-access problem: a VPN... 4. Practice ② What PRA is: the Bomgar-lineage... 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 a VPN plus a hardened jump server plus a shared admin password rotated monthly IS privileged remote access — just cheaper. Wrong — and it is exactly the design auditors keep red-flagging. A VPN authenticates once and then grants routes : the vendor's laptop can reach whatever the network allows, the shared credential destroys attribution, and nothing records what happened inside RDP. PRA inverts each piece: one named identity is brokered to one application through an appliance that everything dials OUT to on TCP 443 — with the password injected (never disclosed) and the session on tape. ## ① The vendor-access problem: a VPN grants a network, the vendor needs an app Sneha runs the quarterly access review at Infosys for a banking client. The spreadsheet has a row that should scare you: vendor_dbsupport , a shared credential used by an outside database vendor, attached to a VPN profile created in 2021. Three engineers at the vendor have changed jobs since. Nobody at the client knows which humans can still log in, and the VPN logs only show an IP address from a hotel in Pune. The contract says the vendor maintains one billing application . The VPN's route table says they can reach the entire 10.20.0.0/16 . That mismatch is the whole problem in one line: a VPN grants a NETWORK; the vendor only needs an APP. The classic patch-up is a jump server in the middle — but the jump server itself becomes a shared, credential-rich pivot box, and the access is still network-shaped: once you are on it, you hop wherever its routes and firewall rules allow. Add a flat network and one stolen vendor password becomes a master key. 👉 So far: vendor needs ONE app, VPN hands out ROUTES, jump servers just move the problem. Next: the breach that made this pattern famous. Figure 1 — Same vendor, two blast radii Split diagram. Left, red side: a vendor laptop connects through a VPN concentrator and gains routes to an entire flat 10.20.0.0/16 segment — billing app, HR database, payment switch and file server are all reachable from one shared credential. Right, green side: the same vendor reaches a PRA appliance which brokers a single audited path to only the billing application; every other system is unreachable. Same vendor, same job — two very different blast radii - VPN: one password = every route vendor laptop hotel Wi-Fi 192.168.1.7 VPN gateway grants ROUTES flat network 10.20.0.0/16 billing app 10.20.8.21 HR database 10.20.9.5 payment switch .12.7 file server 10.20.14.3 contract said ONE app — routes say EVERYTHING PRA: one identity = one application vendor laptop named account: rahul.s PRA appliance policy + recording same network — now app-scoped billing app 10.20.8.21 ✓ HR database ✗ payment switch ✗ file server ✗ ← only the assigned Jump Item is reachable session recorded · credential injected · expiry date set untrusted/attacker trusted/vaulted policy/decision key insight allowed/audited Left: one shared VPN credential reaches everything the routes allow. Right: PRA brokers the same vendor to exactly one application — everything else stays unreachable, and the session is recorded. The textbook case is the 2013 Target breach . Attackers phished a small HVAC (air-conditioning) vendor, stole its credentials for Target's vendor portal, and then — because the vendor's access was network-shaped and the internal network was poorly segmented — walked from a billing/portal foothold all the way to the point-of-sale estate. Roughly 40 million payment cards were skimmed. Note what the pattern needed: no zero-day on the POS, just vendor creds + a network-level grant + a flat network . The US Senate's "Kill Chain" analysis of the incident became required reading for every access architect. The 2024 sequel made the same point from the other side: in December 2024 , attackers (attributed to the Chinese state group Silk Typhoon ) stole a BeyondTrust Remote Support SaaS API key and used it to reset application passwords, reaching 17 SaaS customers including the US Treasury . The same window produced CVE-2024-12356 (CVSS 9.8, unauthenticated command injection in RS/PRA, patched in 24.3.1). Two lessons for this series: third-party access tooling is itself Tier-0 attack surface , and machine credentials (API keys) need rotation, scoping and monitoring just like human ones. We will keep returning to both. The audit finding you WILL see in real life Symptom: the auditor asks "who used vendor_admin on 14 March at 02:10?" and nobody can answer — the VPN account is shared across a vendor team, two members left the vendor last year, and the logs show only a source IP. Cause: shared credentials on a network-level grant. Fix direction: per-human named accounts, app-scoped access, automatic expiry, session recording — which is precisely the PRA feature list. Pause & Predict Predict: the contract says "access to the billing application on 10.20.8.21". After the vendor's VPN login succeeds, what does the network actually let their laptop talk to? Type your guess. Reveal answer Answer: Whatever the VPN's route push and firewall rules allow — typically the whole segment, often the whole 10.20.0.0/16. Unless someone hand-builds per-vendor ACLs (and maintains them forever), the grant is network-shaped. And attribution is an IP address, not a human. Quick check · Q1 of 10 Post-mortem question: in the 2013 Target breach, attackers phished an HVAC vendor and ended up with ~40 million card numbers. What was the bridge between those two facts? a) A zero-day vulnerability in the POS software let them in from the internet b) The vendor's credentials opened a network-level grant, and weak segmentation let attackers walk from the vendor foothold to the POS estate c) Target had no firewalls anywhere on the network d) The HVAC units themselves were exposed to the internet Correct: b. The stolen vendor credential was only the entry ticket — the damage came from what that credential was ALLOWED to reach: a network-shaped grant plus a flat internal network. No POS zero-day was needed for the initial path, Target did have firewalls (rules and segmentation were the gap), and the HVAC hardware was never the vector. 👉 Problem framed: network-shaped vendor access = invisible, over-broad risk. Next: the product BeyondTrust built to replace that pattern — and the one architecture trick that makes firewall teams say yes. ## ② What PRA is: the Bomgar-lineage appliance that dials out on 443 Privileged Remote Access (PRA) is BeyondTrust's product for exactly this job: brokering vendors, remote admins and operational-technology engineers to specific systems — without a VPN, without inbound firewall holes, with every session recorded. Its lineage matters in interviews: PRA (and its sibling Remote Support) descend from Bomgar , which merged with BeyondTrust in 2018 and kept the BeyondTrust name. Old-timers still call the appliance "the Bomgar box", and the appliance still fetches updates from btupdate.com and opens support tunnels to gwsupport.bomgar.com . Deployment comes in two shapes. On-prem: a B-Series appliance , physical or virtual, with the docs recommending placement in the DMZ — it needs a dedicated IP, a DNS record and a CA-signed certificate. Cloud: PRA Cloud , the SaaS form, where BeyondTrust hosts and patches the site for you. Remember from the December 2024 incident timeline: cloud instances were auto-patched on 16 Dec, while on-prem teams had to apply the fix themselves through the /appliance interface. Whichever shape you run, the client-side story is identical. 👉 PRA = Bomgar-lineage appliance (DMZ) or SaaS. Now the architecture trick that defines the whole product: nothing connects inbound to anything. Figure 2 — The dial-out model Three zones left to right: Internet, DMZ, internal network. The vendor's access console on the internet connects outbound on TCP 443 to the B-Series appliance in the DMZ at 203.0.113.40. On the internal network, a Jump Client on a server and a Jumpoint on the LAN also connect outbound on TCP 443 to the same appliance. The appliance splices the two outbound legs into one session. A small panel lists what the appliance itself needs towards the internal network: LDAPS 636, DNS 53, NTP 123, syslog 514. The dial-out model: two OUTBOUND legs meet in the middle INTERNET (untrusted) DMZ INTERNAL 10.20.0.0/16 access console desktop app or browser vendor / remote admin B-Series appliance 203.0.113.40 · TCP 443 policy · recording · Vault (or PRA Cloud, SaaS) app server 10.20.8.21 Jump Client agent installed persistent OUTBOUND 443 Jumpoint (Gateway) one per LAN → many targets dials OUT 443 too TCP 443 → ← OUT 443 ← OUT 443 appliance SPLICES the two outbound legs into one session inbound rule needed: 443 to DMZ ONLY new inbound rules to servers: ZERO appliance → internal (sideband): LDAPS 636 · DNS 53 · NTP 123 syslog 514 / TLS 6514 Docs quote: clients make an outbound connection to the appliance — "the only required ports are 80 and 443" RDP 3389 / SSH 22 happen INSIDE the LAN on the Jumpoint→target leg — never from the internet Follow the arrowheads: the vendor's console dials the appliance, AND the endpoint's agent dials the appliance. The appliance splices the two outbound legs. The internal network never accepts a new inbound connection. The docs state it in one line worth memorising: the connection from each client is an outbound connection from the computer to the B Series Appliance, and "the only required ports are 80 and 443" . The user runs an access console (desktop app, or the browser-based Privileged Web Access Console with near feature-parity) and dials the appliance on TCP 443. On the target side, either a per-endpoint Jump Client agent or a one-per-LAN Jumpoint (renamed Gateway in newer Pathfinder docs) has already dialled out to the same appliance. The appliance authenticates both sides, applies policy, then splices the two outbound legs into one session. RDP 3389 or SSH 22 only ever flow on the short internal leg from the Jumpoint to the target — never across the internet. Lesson 11 dissects Jump technology in depth; today you only need the dial-out idea. Any client network — prove the appliance needs only 443 (openssl, any Linux/macOS box) openssl s_client -connect pra.icici-lab.in:443 -brief Expected output CONNECTION ESTABLISHED Protocol version: TLSv1.3 Ciphersuite: TLS_AES_256_GCM_SHA384 Peer certificate: CN = pra.icici-lab.in Verification: OK ### ▶ One vendor session, end to end Rahul, an engineer at a TCS partner firm, needs RDP to one ICICI app server. Watch the two outbound legs meet at the appliance — and watch what breaks it. Press Play for the healthy path, then Break it to see the failure. ① Sign in rahul.s → SAML IdP + MFA → access console (desktop or browser) ▼ ② Policy appliance checks group policy + Jump Policy → schedule + approval pass ▼ ③ Meet server's Jump Client already dialled OUT on 443 → appliance splices both legs ▼ ④ Session RDP to 10.20.8.21 — credentials injected, screen recorded Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset /login vs /appliance — two doors, never confuse them /login is the admin web console: users, policies, Jump Items, reports. /appliance is the appliance/OS interface — networking, certificates, and where on-prem PATCHES are applied. In December 2024, "patch via /appliance" vs "cloud auto-patched" was the difference between a quiet week and an incident bridge. Interviewers love this distinction. ### Four anchors before we compare products Tap each card — these four keep every later lesson honest. 📦 B-Series appliance tap to flip Hardened box (physical/virtual) hosting the PRA site, DMZ-recommended. All sessions terminate on it. So: one place to police and record everything. ☁️ PRA Cloud tap to flip Same product as SaaS — BeyondTrust hosts and patches it. Clients still dial out on 443. So: less patch burden, same client architecture. 🖥️ Access consoles tap to flip Desktop console (Windows/macOS/Linux) or the browser Privileged Web Access Console. So: vendors need zero special network — just HTTPS out. 🔁 Dial-out on 443 tap to flip Consoles, Jump Clients and Jumpoints ALL connect outbound to the appliance. So: zero inbound rules to targets — the firewall team approves in one meeting. Quick check · Q2 of 10 Meera's firewall team at ICICI asks: "Which ports do we open INBOUND from the internet so the on-prem PRA appliance in the DMZ can work?" a) TCP 443 plus TCP 3389 and TCP 22 for the RDP/SSH sessions b) None — PRA only ships as cloud SaaS c) TCP 443 (TCP 80 optional — it only redirects to HTTPS) d) UDP 500 and 4500, like any IPsec VPN Correct: c. The docs are explicit: all session traffic rides TCP 443 to the appliance; 80 is optional and merely redirects. RDP/SSH never traverse the internet — they happen on the internal Jumpoint→target leg — so no 3389/22 inbound. PRA absolutely ships on-prem (B-Series), and it is not an IPsec tunnel, so 500/4500 are irrelevant. Pause & Predict Predict: a PRA session must reach a server in a locked-down VLAN that allows almost nothing inbound. How many NEW inbound firewall rules does that VLAN need? Type your guess. Reveal answer Answer: Zero. The Jump Client on the server (or a Jumpoint in the VLAN) dials OUT on TCP 443 to the appliance. The only firewall work is outbound: permit 443 from those hosts to the appliance FQDN. That is the single biggest reason network teams accept PRA where they fought VPN exceptions for years. 👉 Architecture done: appliance (DMZ or cloud), everything dials out on 443, sessions spliced in the middle. Next: PRA is one of FOUR tools people confuse — time for the architect's decision tree. ## ③ PRA vs Remote Support vs VPN vs Password Safe — the architect's decision BeyondTrust sells two remote-access products off the same appliance lineage, and your company already owns a VPN and (if you followed lessons 1–9) Password Safe. Mixing them up is the most common early-career mistake — and a frequent interview filter. Remote Support (RS) is for the helpdesk: representatives fixing end users' devices , with chat, a public support portal, and typically concurrent (shared-pool) rep licensing. PRA is for privileged humans reaching infrastructure : vendors and admins jumping to servers, switches and web consoles, with Vault credential injection and named-user licensing (a per-asset SKU also exists). Same DNA, different humans, different licence math. Then there is Password Safe's session proxy — the one that confuses everyone, because it ALSO gives recorded RDP/SSH without exposing passwords. The difference is the centre of gravity. Password Safe is vault-first : an internal admin requests a credential, an approval workflow releases it, and the session rides the PS proxy on ports 4422 (SSH) / 4489 (RDP) , with rotation on check-in. PRA is access-first : built for third parties and remote engineers who must cross the network boundary, with vendor onboarding, per-app Jump Items and the dial-out appliance. PRA even carries its own built-in Vault (up to 100,000 accounts) so injection works without Password Safe — and the two integrate (via the Endpoint Credential Manager, or directly since PRA 25.3) when you want the full platform. Figure 3 — Four tools, one decision Four-column comparison. VPN: grants network routes, licensed per tunnel or user, little session audit, fit for site-to-site links. Remote Support: helpdesk fixing end users' devices, concurrent licences, chat and screen share, public portal. PRA: privileged humans and vendors reaching infrastructure, named-user licences, Jump Items with credential injection and recording. Password Safe sessions: internal admins checking out vaulted credentials with approval, asset-based licence, RDP and SSH proxied on ports 4489 and 4422. Four tools people confuse — match the tool to the human VPN grants: NETWORK routes made for: employees, site-to-site audit: flows, not actions creds: user still types them − vendor on VPN = over-broad by design Remote Support grants: help session to a DEVICE made for: helpdesk → end users licence: concurrent reps extras: chat, portal, surveys + same Bomgar lineage + same appliance tech PRA ★ grants: ONE app / system (Jump Item) made for: vendors + remote admins licence: named user (per-asset SKU too) extras: Vault injection, recording + outbound-443 only + sponsored vendor expiry Password Safe proxied sessions grants: vaulted cred + session made for: internal admins, checkout licence: asset-based, users free proxy ports: SSH 4422 · RDP 4489 + approval workflow + rotation on check-in Rule of thumb: end-user device → RS · third party / remote human → infra → PRA · internal checkout + approval → Password Safe VPN survives for whole-network needs (site-to-site, employee fleet) — never as the vendor front door Read the columns, then the green rule of thumb. The fastest tell in any scenario question: WHO is the human (helpdesk rep, vendor, internal admin) and WHAT are they touching (end-user device, infrastructure, credential)? Here is what the Password Safe lane looks like in practice — an internal Infosys admin reaching a switch through the PS proxy, never learning the rotated password. Notice the port and the stacked identity in the connection string: Password Safe session proxy — Direct Connect SSH (internal admin's workstation) ssh -p 4422 sneha.r+netadmin@icici.in+coresw01@ps.icici-lab.in Expected output sneha.r+netadmin@icici.in+coresw01@ps.icici-lab.in's password: *** This session is being recorded *** Last login: Tue Jun 09 21:14:08 2026 from 10.20.4.15 netadmin@coresw01:~$ And the VPN? It keeps its honest jobs: site-to-site links between offices, and broad network access for managed employee laptops where the device itself is trusted and instrumented. The decision rule an architect actually uses: end-user device being fixed → Remote Support. Third party or remote human touching infrastructure → PRA. Internal admin needing checkout + approval on a vaulted credential → Password Safe. A whole network for a trusted site or fleet → VPN. When a scenario fits two lanes, ask who owns the identity lifecycle — if the human is not your employee, PRA's sponsored, expiring vendor accounts win. 👉 Decision tree locked: RS = end-user devices, PRA = privileged access to infra, PS = vault-first internal checkout, VPN = networks not vendors. Quick check, then identity and onboarding. Quick check · Q3 of 10 Aditya at Airtel runs two teams: a helpdesk fixing employees' laptops, and network vendors managing core routers remotely. Which product split matches BeyondTrust's intent? a) Remote Support for the helpdesk (end-user support, concurrent licences); PRA for the vendors (privileged infra access, named users) b) PRA for both — it can share screens too c) Remote Support for both — routers are just endpoints d) Password Safe alone — its proxy records sessions anyway Correct: a. RS is built (and licensed concurrently) for representatives supporting end users' devices; PRA is built (and licensed per named user) for privileged humans reaching infrastructure, with vendor onboarding and Jump Items. Using PRA for helpdesk wastes named licences; using RS for vendor infra access loses the privileged-access controls; Password Safe's proxy is vault-first for internal admins, not a vendor front door. Pause & Predict Predict: an internal admin sitting INSIDE the office needs RDP to a managed server with approval and recording. PRA or Password Safe? Type your guess. Reveal answer Answer: Password Safe. The human is internal, the credential is vaulted, and the ask is checkout-with-approval — vault-first territory (proxy ports 4489/4422, rotate on check-in). PRA earns its named-user licence when the human is remote or third-party and must cross the network boundary to reach infrastructure. ## ④ Identity & onboarding: SAML, MFA, sponsored vendors, named-user licences PRA only delivers "one identity → one app" if the identities are real. The lanes you will actually use: local users (created under /login → Users & Security → Users , on the appliance itself), and external providers configured under Users & Security → Security Providers — LDAP/Active Directory (the appliance queries your DC over 389/LDAPS 636 — exactly the DMZ→internal sideband ports from the matrix), Kerberos , and SAML for modern SSO against Entra ID or Okta. Production guidance: SSO via SAML for humans, groups mapped to PRA group policies , and one or two local break-glass admin accounts — vaulted, MFA-protected — so an IdP outage cannot lock you out of /login. /login → Users & Security → Security Providers → Add → SAML For Users . Map the IdP's group attribute, and never leave the default policy permissive. (Recreated for clarity — your console matches this.)"> 🖥️ Where identity plugs in — /login → Users & Security → Security Providers → Add → SAML For Users . Map the IdP's group attribute, and never leave the default policy permissive. (Recreated for clarity — your console matches this.) pra.icici-lab.in/login · Users & Security → Security Providers 1 Provider Type SAML For Users 2 Identity Provider Metadata Upload metadata XML (Entra ID) Username Attribute NameID 3 Group Lookup Attribute memberOf → maps to group policies 4 Default Group Policy No Access (deny by default) Save MFA stacks in layers. The cleanest: enforce it at the IdP (Entra/Okta) so every SAML login is already MFA-verified — like an Aadhaar-OTP step before the gate. Local accounts get TOTP on the appliance. And independently of login, a Jump Policy can demand a 2FA challenge at session start — a second checkpoint right before the most sensitive doors, even for an already-logged-in user. The browser console adds FIDO2 passwordless support (fully on Windows; roaming keys like YubiKey on macOS/Linux desktop consoles). Karthik at HCL faces this First SAML vendor logs in successfully — but the access console is empty. No Jump Items, no teams, nothing to click. Likely cause The SAML assertion carried no group value the appliance recognises, so the user landed on the default group policy — which (correctly) grants nothing. Diagnosis Capture one SSO login and compare the asserted group attribute against the Security Provider's group lookup; check which group policy the test user actually resolved to. /login > Users & Security > Security Providers (SAML For Users) · then Users & Security > Group Policies Fix Map the IdP group (e.g. Entra group "PRA-DB-Vendors") to a PRA group policy granting the vendor's Jump Group membership and session policy; keep the default policy at No Access. Verify Fresh SSO login now shows the assigned Jump Group in the console, and the session report lists the vendor under their own named identity. 👉 Identity sorted: SAML for humans, deny-by-default for strangers, break-glass for outages. Now the part interviewers call "vendor onboarding" — and the licence shape behind it. For third parties, PRA has a dedicated lane: /login → Users & Security → Vendors . You create a vendor group per supplier, attach the group policy that scopes what its members reach, and appoint sponsors — internal employees who approve each vendor user and own the relationship. Vendor accounts expire automatically (fixed end date or after inactivity), which quietly solves Sneha's audit finding from section ①: the engineer who left the vendor last year stops existing in your system without anyone remembering to act. It is the society visitor register, upgraded: entry only when a flat owner (sponsor) confirms, pass valid for today, every entry timestamped. For one-off emergencies there is also Access Invite — a time-boxed invitation instead of a standing account. /login → Users & Security → Vendors → Add (vendor group) . Sponsor + expiry are the two fields that end shared-forever vendor accounts. (Recreated for clarity — your console matches this.)"> 🖥️ The vendor onboarding screen — /login → Users & Security → Vendors → Add (vendor group) . Sponsor + expiry are the two fields that end shared-forever vendor accounts. (Recreated for clarity — your console matches this.) pra.icici-lab.in/login · Users & Security → Vendors 1 Vendor Group Name TCS-DB-Support 2 Group Policy Vendor — Billing Jump Group only 3 Account Expiry Remove after 30 days of inactivity 4 Sponsor meera.k@icici.in (approves vendor users) Add Vendor Group Onboarding is GUI work, but everything has an API equivalent — the PRA Configuration API authenticates with OAuth client credentials and lets you script audits, like listing exactly which endpoints exist for a vendor's Jump Group before an access review: PRA Configuration API — what can vendors actually reach? (admin workstation) curl -s -X POST "https://pra.icici-lab.in/oauth2/token" \ -u "$CLIENT_ID:$CLIENT_SECRET" -d "grant_type=client_credentials" curl -s "https://pra.icici-lab.in/api/config/v1/jump-item" \ -H "Authorization: Bearer $TOKEN" | head -c 400 Expected output {"access_token":"eyJhbGciOiJSUzI1NiIs...","token_type":"Bearer","expires_in":3600} [ {"id": 7, "name": "BILLING-APP-01", "hostname": "10.20.8.21", "jump_group_id": 3, "jumpoint_id": 2} ] Finally, the licence shape — because procurement questions reach L2 engineers faster than you expect. PRA is sold per named user (a 2023 US GSA price list shows the "Privileged Remote Access Per Named User License" perpetual SKU at roughly USD 3,235 list), and a per-asset SKU (PRAA-LIC) also exists. Contrast with Remote Support's concurrent rep pool, and Password Safe's asset-based model with unlimited users. A named-user licence is a gym card with your photo on it: only Rahul can use Rahul's — so 30 vendor engineers means 30 named accounts, not one shared login. That cost is the point: it buys attribution. Career note: BeyondTrust University's PRA Administration course leads to the product cert (40 questions, 75% to pass, two attempts) — the docs portal and Beekeepers community are free, so you can build paper-skills before an employer funds the exam. Quick check · Q4 of 10 A vendor engineer quits her firm without telling anyone at the client. In the PRA model, what limits the damage compared with a VPN account? a) PRA automatically blocks logins from unfamiliar IP addresses b) Vendors share one account anyway, so there is nothing to remove c) The VPN concentrator would also have auto-expired her account d) Her sponsored account auto-expires on its end date, a named sponsor owns its lifecycle, and it only ever reached the Jump Items in her vendor group — with every session recorded Correct: d. The vendor lane is built for exactly this: per-human named accounts inside a vendor group, automatic expiry (date or inactivity), an accountable internal sponsor, and app-scoped Jump Item access with recording. IP-based blocking is not the mechanism; shared accounts are the anti-pattern PRA removes; and classic VPN accounts famously do NOT expire themselves — that is how Sneha's audit finding happened. Pause & Predict Predict: your IdP is Entra ID and every human signs in via SAML. Where do LOCAL appliance accounts still make sense? Type your guess. Reveal answer Answer: Break-glass. If the IdP is down (or the SAML trust breaks), SSO users cannot reach /login — including the admin who must fix it. Keep one or two local admin accounts with TOTP MFA and long vaulted passwords, tested quarterly. Everything else goes through SAML so joiner/leaver hygiene lives in one place. Figure 4 — The PRA pocket card Two-panel cheat sheet. Left panel lists the PRA port matrix: inbound from internet to the DMZ appliance only TCP 443 required and TCP 80 optional redirect, optional STUN and TURN ports; appliance to internal network LDAPS, DNS, NTP, syslog, SMTP; appliance to internet 443 towards btupdate.com and gwsupport.bomgar.com. Right panel lists core vocabulary: slash-login admin console versus slash-appliance patch interface, access console, Jump Item, Jump Client, Jumpoint also called Gateway, Vault, vendor group with sponsor, named-user licence. PRA fundamentals — the pocket card PORTS (on-prem appliance, DMZ) Internet → appliance (inbound) TCP 443 — required, ALL session traffic TCP 80 — optional, redirects to HTTPS 3478 / 5349 — optional STUN-TURN Appliance → internal (sideband) LDAP/S 389·636 DNS 53 NTP 123 syslog UDP 514 / TLS TCP 6514 SMTP 25·465·587 KMIP 5696 Appliance → internet (optional) TCP 443 → btupdate.com (updates) TCP 443 → gwsupport.bomgar.com Endpoints & consoles → appliance: OUTBOUND 443 Inbound holes to servers: NONE. RDP 3389 / SSH 22 / VNC 5900 ride the internal Jumpoint→target leg only. Interview answer: "only 80/443 are required" SIX WORDS THAT RUN PRA /login vs /appliance admin web console vs OS/patch interface (patches = /appliance) access console desktop app or Privileged Web Access Console (browser) Jump Item a pre-defined endpoint — RDP, SSH, web app, tunnel… Jump Client / Jumpoint (Gateway) per-endpoint agent / one-per-LAN broker — both dial OUT Vault + credential injection built-in store; password injected, never shown to the user vendor group + sponsor sponsored accounts that auto-expire; sponsor owns lifecycle named-user licence PRA = per named human (RS = concurrent; PS = per asset) Heritage: PRA + RS descend from Bomgar (merged 2018) old-timers and interviewers still say "the Bomgar box" untrusted/attacker trusted/vaulted policy/decision key insight allowed/audited Screenshot this one. Left: the port matrix the firewall team will ask about. Right: the six vocabulary anchors lesson 11 builds on. Prove the offboarding actually works Once a quarter, pull /login → Reports → Vendors and the access-session reports: list every vendor account, its sponsor, its expiry, and its last session. Any account with no sponsor, no expiry, or no sessions in 90 days is your finding — kill it before the auditor does. Five minutes, and it is the exact evidence external audits ask for. 🎮 Hands-on: BeyondTrust PAM Essentials room Next: Jump Clients, Jumpoints & Jump Items 👉 Full circle: the vendor problem from section ① is answered by named, sponsored, expiring identities reaching app-scoped Jump Items over a dial-out appliance. Lesson 11 opens the Jump toolbox itself. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Why not just ACL the VPN down per vendor? Is PRA the same thing as the old Bomgar? Do RDP/SSH targets need an agent installed? PRA Cloud or on-prem appliance — how do I choose? What licence trap should I warn my manager about? PRA has its own Vault — so where does Password Safe fit? 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 statement about PRA's network model is TRUE? a) The appliance opens an inbound RDP 3389 connection to each target as sessions start b) Endpoints listen on a dedicated BeyondTrust port that the appliance connects to c) Every client — console, Jump Client, Jumpoint — connects OUTBOUND to the appliance, and only ports 80/443 are required d) PRA Cloud requires a site-to-site VPN into the customer data centre Correct: c. Straight from the docs: each client makes an outbound connection to the B-Series appliance and "the only required ports are 80 and 443". Nothing listens inbound on endpoints (that is the VPN/agent-listener anti-pattern), RDP rides the internal Jumpoint→target leg only, and PRA Cloud uses the same dial-out model — no VPN. Q6 · Apply Priya at Flipkart must give a database vendor two weeks of access to ONE SQL Server (10.20.8.40), with session recording and without ever disclosing the password. Best fit? a) A PRA Jump Item for that server, the vendor in a sponsored account with an expiry date, and the Vault credential injected at session start b) A VPN account restricted by NAC, then RDP straight to the server c) Share the local admin password over email and rotate it afterwards d) Install a consumer remote-desktop tool on the server for the fortnight Correct: a. Every requirement maps to a PRA primitive: app-scoping = Jump Item, two weeks = sponsored-account expiry, no disclosure = credential injection, recording = built-in. VPN+NAC still grants network routes and types real passwords; emailing credentials is the breach pattern itself; consumer tools bypass policy, identity and audit entirely. Q7 · Apply Infosys needs: (1) internal admins checking out server credentials with an approval workflow, and (2) third-party vendors reaching the same estate remotely. Which pairing matches BeyondTrust's product intent? a) Remote Support for both teams b) PRA for the internal checkout workflow, Password Safe for the vendors c) A VPN for the admins and PRA for the vendors d) Password Safe (checkout + approval + 4422/4489 session proxy) for the internal admins; PRA (sponsored vendor accounts + Jump Items) for the remote vendors Correct: d. Vault-first internal checkout with approval is Password Safe's home turf (release workflow, proxy on 4422/4489, rotation on check-in); remote third parties crossing the boundary are PRA's (vendor groups, expiry, dial-out appliance). Option b reverses the products; RS is for end-user support; and putting admins on plain VPN abandons the credential-release controls Infosys asked for. Q8 · Analyze December 2024: attackers used a stolen Remote Support SaaS API key to reset application passwords across 17 customers, including the US Treasury. Interactive logins already required MFA. Which control gap mattered MOST? a) End users had chosen weak passwords b) Machine credentials sat outside the MFA path — API-key rotation, scoping and usage-anomaly monitoring were the missing controls c) TLS was not enforced on the SaaS portal d) Customers had failed to patch their on-prem appliances in time Correct: b. The stolen object was an infrastructure API key — a machine credential that never passes through interactive MFA. Keys need their own lifecycle: short rotation, narrow scope, vaulting, and monitoring of anomalous use. User password strength and TLS were not the vector, and the affected instances were SaaS — BeyondTrust patched those centrally, so on-prem patch lag is the wrong lesson here. Q9 · Analyze A hardening sprint adds a strict egress ACL to the server VLAN (only DNS and established flows allowed out). Next morning every PRA Jump Client in that VLAN shows offline. Why? a) The appliance can no longer reach an inbound agent port on the endpoints b) Jump Clients require UDP 3478 to remain registered c) The ACL must allow inbound TCP 443 from the appliance to each server d) Jump Clients hold a persistent OUTBOUND TCP 443 connection to the appliance — the new ACL stopped them re-establishing it Correct: d. The agent's lifeline is its own outbound 443 session to the appliance; block egress 443 and the client drops offline with no leg for the appliance to splice. There is no inbound agent port (a — that is the model PRA avoids), STUN 3478 is optional peer-to-peer plumbing (b), and 'inbound 443 to servers' (c) reverses the direction — the fix is an OUTBOUND allow to the appliance FQDN. Q10 · Evaluate Two designs for 30 vendor engineers. (A) Keep the VPN: add NAC, a hardened jump server, and one shared admin account rotated monthly. (B) PRA: named sponsored accounts with auto-expiry, per-app Jump Items, injected credentials, recorded sessions. Evaluate. a) A — fewer moving parts means equal security at lower cost b) B — per-engineer identity with automatic expiry, app-scoped (not network-shaped) access, passwords never disclosed, every session on tape; A still funnels 30 humans through one credential on a network grant c) A — NAC posture checks make the network grant equivalent to app scoping d) They are equivalent as long as the jump server is patched monthly Correct: b. Test A against section ①'s failure modes: the shared account still kills attribution (who was it on 14 March?), monthly rotation leaves a 30-day stolen-credential window, NAC validates the DEVICE but still grants routes, and the jump server is a credential-rich pivot. B answers each one structurally — identity, scope, disclosure, evidence. Patching the jump server (d) fixes none of the design flaws. 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 PRA safer than a VPN for a vendor who manages exactly one application? Then compare to the expert version. Compare with expert answer Expert version: Because PRA brokers a named, expiring identity to that ONE application through an appliance everything dials OUT to on 443 — credentials injected, session recorded — while a VPN grants the laptop network routes, shared logins and no tape. ### 🗣 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 Fundamentals at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary PRA (Privileged Remote Access) BeyondTrust's product brokering vendors/remote admins to specific systems — no VPN, no inbound holes, sessions recorded. B-Series appliance The hardened physical/virtual box hosting the PRA site; DMZ placement recommended; all sessions terminate on it. PRA Cloud The SaaS form — BeyondTrust hosts and patches the site; clients still dial out on TCP 443. Dial-out model Consoles, Jump Clients and Jumpoints ALL connect outbound to the appliance; only ports 80/443 are required. Access console The app a PRA user works in — installable desktop console or the browser-based Privileged Web Access Console. Jump Item Umbrella term for any pre-defined endpoint a user can jump to (RDP, SSH, web app, tunnel…). Jump Client Per-endpoint agent holding a persistent one-to-one encrypted OUTBOUND connection to the appliance. Jumpoint (Gateway) One broker installed per known LAN reaching many targets agentlessly; renamed Gateway in Pathfinder-era docs. Vault (PRA) PRA's built-in credential store (up to 100,000 accounts) powering injection — passwords used but never shown. Credential injection The appliance types the password into the session for you — the human never sees or copies it. Vendor group + sponsor Onboarding lane for third parties: sponsored accounts that auto-expire, owned by a named internal employee. Named-user licence PRA's primary licence shape — one licence per named human (RS = concurrent pool; a per-asset PRA SKU also exists). #### 📚 Sources BeyondTrust Docs — PRA network infrastructure & considerations (outbound-only model: "the only required ports are 80 and 443"; DMZ placement; full port matrix). docs.beyondtrust.com/pra/docs/on-prem-network · /on-prem-network-considerations - BeyondTrust Docs — PRA Administrative Guide, /login menu tree (Users & Security: Vendors, Security Providers, Group Policies, Access Invite; Reports). docs.beyondtrust.com/pra/docs/on-prem-admin-guide - BeyondTrust Docs — Privileged Web Access Console guide (browser-console parity, FIDO2 support notes). docs.beyondtrust.com/pra/docs/web-access-console - NVD / BeyondTrust BT24-10 — CVE-2024-12356 (CVSS 9.8 unauthenticated command injection in RS/PRA, fixed 24.3.1; cloud auto-patched 2024-12-16). nvd.nist.gov/vuln/detail/cve-2024-12356 - The Hacker News — Dec 2024 stolen Remote Support SaaS API key incident: 17 SaaS customers incl. US Treasury, Silk Typhoon attribution. thehackernews.com/2024/12/chinese-apt-exploits-beyondtrust-api.html - US Senate Commerce Committee — "A Kill Chain Analysis of the 2013 Target Data Breach" (vendor credentials → flat network → POS); KrebsOnSecurity — "Target Hackers Broke in Via HVAC Company". commerce.senate.gov · krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company - Carahsoft 2023 GSA price list — "Privileged Remote Access Per Named User License" SKU (~USD 3,235 list); CDW — PRA Per-Asset License (PRAA-LIC). static.carahsoft.com · cdw.com/product/6412131 - BeyondTrust University — Privileged Remote Access Administration course + certification (40 questions, 75% pass, 2 attempts). beyondtrust.com/services/beyondtrust-university/privileged-remote-access-administration - PeerSpot — BeyondTrust vs CyberArk PAM comparisons (PRA ↔ CyberArk Remote Access mapping); identityskills.com — "Which PAM tool should you learn in 2026". peerspot.com · identityskills.com ### What's next? You now know WHY the appliance model wins. Next we open the toolbox that does the actual reaching: Jump Clients vs Jumpoints, every Jump Item type from Shell Jump to Web Jump, and the policies that gate them. Next · Jump technology: Jump Clients, Jumpoints & Jump Items → 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