PRA Jump Technology Deep-Dive: — Jump Clients, Jumpoints & Every Jump Item Type

① The Jump model — a saved doorway, a wing, a gate pass and visiting rules

Start with the vocabulary, because BeyondTrust’s docs are precise about it. A Jump Item is, in the docs’ own words, “an umbrella term for any pre-defined endpoint, regardless of how it is reached.” One Jump Item = one saved doorway to one machine — a Windows server, a switch CLI, a vCenter page. A Jump Shortcut is “any Jump Item that is not a Jump Client” — that distinction matters in every exam and interview. Think of an apartment society: each flat’s door is a Jump Item; the society register at the gate is the appliance.

Where do you touch all this? Two consoles. Engineers live in the access console (desktop app or the Privileged Web Access Console): its Jump interface lists Jump Items organised by Jump Group — select an item, press the Jump button, the session starts. Admins live in /login: classic versions put everything under the Jump menu, while the 2025+ Pathfinder-era console renames the menu to Asset Management and the objects with it: Jumpoint → Gateway, Jump Item → Asset, Jump Group → Asset Group, Jump Policy → Asset Policy. Functionality is unchanged — names only.

Three objects control people. A Jump Group organises items and is the visibility boundary — if Priya is not a member of net-core, those items don’t appear in her console at all. A Jump Item Role is “a predefined set of permissions regarding Jump Item management and usage” — the defaults are Administrator, Start Sessions Only, and (since v25.2) Auditor, whose single permission is View Reports. The role’s checkboxes are literal: “Start Sessions”, “Move and Copy”, “Remove existing”, “Edit Tag”, “Edit Comments” and so on. One resolution rule to memorise: the user↔Jump Group relationship beats a group-policy↔Jump Group relationship, which beats the user’s default role.

The fourth object controls time and ceremony. A Jump Policy is the society’s visiting rules: a Jump Schedule (visiting hours, optionally force-ending sessions outside them), Jump Approval (the flat owner’s phone call before the visitor enters — requester gives a reason and duration, named approvers say yes/no), a required ticket ID, a per-policy 2FA challenge, start/end notification emails, and a Disable Recordings override. One documented constraint trips everyone: a schedule and an approval cannot both be enabled on the same policy — pick the control that matters, or split into two policies.

Four words you will use every single day

Tap each card — these four objects ARE the Jump model. Everything else in this lesson hangs off them.

② Jump Clients — the installed agent that dials out and stays reachable

A Jump Client is an installable agent that establishes “a one-to-one encrypted connection between a B Series Appliance and a remote Windows, Mac, or Linux system.” Two properties make it special. First, the connection is persistent and outbound — the agent dials OUT to the appliance on TCP 443, so the laptop is reachable from home Wi-Fi, a hotel, or a 4G dongle with no VPN and no inbound firewall hole. It is a SIM card inside the phone: wherever the phone roams, the tower can ring it. Second, it is state-aware — it knows whether a user is sitting at the box, which matters before you take over a production console.

Nobody installs 1,200 agents by hand. The Jump Client mass deployment wizard in /login builds an installer (MSI/EXE/script) that is valid for a duration you choose, with the Jump Group and Jump Policy pre-pinned — push it through SCCM/Intune and every laptop lands in the right wing with the right visiting rules on first dial-in. Scale is a sizing question, not a licence question: appliance tiers run from Small (up to 1,000 endpoints) through Enterprise (35k–50k) to Atlas clusters at 50,000–250,000 endpoints.

The lifecycle is where production pain lives. Online means the outbound tunnel is up. Offline means it is not — laptop asleep, off network, or (very common) host security software killed the service. Then come the two maintenance timers in /login: after N days unconnected a client is marked lost — a diagnostic label, nothing is removed — and after M days it is automatically deleted from the console. Set lost-days < delete-days, or clients skip the warning and just vanish. Separately, the “Uninstalled Jump Client Behavior” setting decides whether a locally-removed agent stays visible as an Uninstalled tombstone — keep tombstones, because “The specified Jump Client has been uninstalled” is evidence, and a user removing the agent from a vaulted server is a finding, not housekeeping.

Upgrades have their own physics: when the appliance is upgraded, every Jump Client auto-upgrades — but under the “Maximum bandwidth of concurrent Jump Client upgrades” throttle, a 50,000-endpoint estate upgrades in waves. Mid-wave, consoles see “The Jump Client is running a different version. Please try again after the upgrade completes.” That message is normal; the panic move — mass-redeploying mid-upgrade — is what creates duplicate entries. Bonus ops features worth knowing: admin-selectable statistics (CPU, console user, disk, screen thumbnail, uptime) and Wake-on-LAN, where another Jump Client on the same subnet broadcasts the magic packet.

Finally — when is an agent on every box the wrong answer? When the targets sit on a network you control and that never changes: a datacenter VLAN, a branch server room, a POP. There, 800 agents mean 800 lifecycles, 800 EDR exclusions, 800 upgrade-wave members — pure overhead, because ONE gateway host inside that segment can reach every neighbour agentless. Also, network gear (switches, firewalls, iLO/iDRAC) cannot run an agent at all. The docs’ decision rule, which the next section builds on: unknown or roaming network → Jump Client; known fixed network → Jumpoint + Jump Shortcuts.

③ Jumpoints — one gateway host for the whole network segment

A Jumpoint is “a conduit for access to computers on a known remote network” — ONE install inside the segment, and every neighbour becomes reachable with no software on the targets. It is the mobile tower serving every phone in one locality, where the Jump Client was the SIM inside each phone. The Jumpoint itself dials OUT to the appliance on 443 like everything else; the protocol legs (RDP 3389, SSH 22, VNC 5900, HTTPS) happen inside the LAN, between the Jumpoint and its neighbours. For availability you can run a clustered Jumpoint — up to 10 redundant nodes of the same Jumpoint on different hosts in the same LAN, alive while at least one node is online.

The part everyone underestimates: service-account rights. A Windows Jumpoint installs running as Local System — an account with exactly zero authority on other machines. For agentless pushes to Windows targets (Remote Jump), the Jumpoint’s service account needs local admin on the targets, and the targets need the ADMIN$ and IPC$ shares exposed, the Remote Registry service running, and TCP 135/445 reachable from the Jumpoint host. Change the service log-on to a dedicated domain account (services.msc) — that account is the watchman who must hold real keys, and like the Password Safe functional account, it deserves vaulting and monitoring of its own. Two more facts for the design notebook: a Jumpoint cannot access itself (“unsupported loopback connection”), and Linux Jumpoints handle RDP, SSH/Telnet and VNC (plus Kubernetes tunnels) — but Web Jump and Vault discovery need a Windows Jumpoint.

# Can this host reach the target’s admin shares (SMB)?
Test-NetConnection -ComputerName 10.20.8.41 -Port 445

# Is Remote Registry running on the target?
Get-Service -ComputerName 10.20.8.41 -Name RemoteRegistry

ComputerName     : 10.20.8.41
TcpTestSucceeded : True

Status   Name             DisplayName
Running  RemoteRegistry   Remote Registry

Real estates run both families at once: Jump Clients on roaming laptops and the odd DMZ box, a clustered Jumpoint pair per datacenter and per branch. Sizing is honest work, not guesswork — the docs’ guidance puts an 8–12 core / 32–64 GB Jumpoint host around 20–25 concurrent Jump Client/RDP sessions, or up to roughly 200 SSH/Telnet sessions, and RDP recording costs about 4 CPU cores per 5 RDP sessions. Watch the 9:00 AM pile-up too: 20+ users starting sessions simultaneously can overload a thin Jumpoint — stagger shifts, add cluster nodes, or scale the host.

④ The Jump Item type tour — pick the doorway by what the target speaks

Every type is created the same way: access console → Jump interface → Create → pick the type (names cap at 128 characters). The full on-prem type list: Jump Client, Local Jump, Remote Jump, Remote RDP, Remote VNC, Shell Jump, Protocol Tunnel Jump, Web Jump. Two often-confused ones first: Local Jump pushes an agentless session from your own machine across your local network — no Jumpoint, but the target needs Remote Registry enabled; Remote Jump is the same push performed by a Jumpoint on the far network. Everything below rides a Jumpoint.

Remote RDP is the workhorse for Windows: default port 3389 (override as host:port), a Quality selector, and checkboxes that matter in audits — Console Session (attach to the physical console), Ignore Untrusted Certificate (lab use only), and Session Forensics. Credential injection from the Vault works here, so the engineer never types a password. Shell Jump covers everything with a CLI — SSH on 22 or Telnet on 23, terminal type xterm or VT100, keep-alive 0–300 s — and the Jumpoint must be configured for open or limited Shell Jump access. Remote VNC (default 5900) is the legacy-GUI fallback; the target’s VNC server must speak RFB protocol 3.8+.

Web Jump is the one with the surprising architecture: it opens browser-based consoles — vCenter, firewall and switch GUIs, iLO/iDRAC — but the browser does not run on your laptop. A CEF embedded browser runs on the Jumpoint (Windows Jumpoints only), and you watch a rendered, recorded view of it. Credential injection fills the web login form — and when a non-standard form defeats auto-detection, you supply the Username Field Hint / Password Field Hint / Submit Button Hint as exact CSS selectors. The Verify Certificate flag checks the target site’s TLS cert from the Jumpoint.

Last family: Protocol Tunnel Jump — for when engineers insist on their own thick tools. It opens a listener on your machine (Local Address default 127.0.0.1) and forwards it through the audited path to the remote service. Six variants: plain TCP Tunnel (local port → remote port); MySQL (server must use the caching_sha2_password auth plugin); PostgreSQL (username + database required); SQL Server (Windows auth and SQL login both supported — and PRA 25.3 injects Vault credentials into SQL tunnels); Kubernetes Cluster Tunnel (https:// URL, and it requires a Linux Jumpoint — the mirror image of Web Jump’s Windows rule); and Network Tunnel, which carries any TCP and non-TCP protocol (e.g. UDP) but needs at least one IPv4 filter rule and DHCP (or defined IP scopes) on the endpoint network. It is the Mumbai dabbawala: the tiffin is picked up at your doorstep (127.0.0.1), relayed through a trusted network, delivered to exactly one desk (host:port) — never opened, every handoff logged.

# 1. OAuth2 token (API account: /login > Management > API Configuration)
curl -s -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  https://pra.icici.example/oauth2/token

# 2. Configuration API — Shell Jump items
curl -s -H "Authorization: Bearer $TOKEN" \
  https://pra.icici.example/api/config/v1/jump-item/shell-jump

{"access_token":"eyJhbGciOiJSUzI1NiIs...","token_type":"Bearer","expires_in":3600}
[{"id":12,"name":"pop-sw-01","hostname":"192.168.40.11","protocol":"ssh","port":22,
  "jumpoint_id":3,"jump_group_id":7,"terminal":"xterm"}]

Creating doorways at scale: the Jump Shortcuts Mass Import Wizard in /login takes a per-type CSV template — max 5 MB, one Jump Item type per file — so an 800-server segment becomes a spreadsheet exercise, not a clicking marathon. And one operational note that saves audit pain: name items by what they ARE (db-win-prod-04), pin them to the right Jump Group at import time, and your Jump interface stays searchable at 3 AM.