Master the jump-box security model and learn how Delinea's Distributed Engine replaces traditional jump servers with a credential-injecting proxy architecture — delivering full session auditability without exposing credentials or creating lateral movement paths.
A jump box (or bastion host) is a hardened, single-entry intermediary that controls all access into an isolated or high-security network segment. Understanding its purpose is the foundation of any PAM architecture.
High-security zones (production databases, OT/SCADA, PCI scope, cloud management planes) are kept off the corporate network. The jump box is the only authorized gateway in — all other inbound routes are blocked by firewall rules.
By funneling every privileged session through one controlled node, organizations can log, inspect, and record all access. Without a jump box, session telemetry is scattered across dozens of endpoints.
Target systems run minimal services and accept connections from the jump box IP only. This dramatically limits the blast radius of a compromised endpoint — the attacker still needs to pivot through the hardened gateway.
Rather than handing out server passwords to individual admins, credentials can be injected transparently at the jump box — meaning no human ever sees or holds the actual secret.
Certain environments and compliance frameworks mandate jump-box architecture as a compensating control.
Delinea's Distributed Engine (DE) replaces the traditional jump server with a credential-injecting proxy that brokers sessions transparently — eliminating credential exposure while maintaining full control and auditability.
The admin requests access to a target system through the Delinea Secret Server web UI or launcher. No credentials are displayed or transmitted to the admin's endpoint — the request is purely a workflow authorization event.
Secret Server instructs the Distributed Engine — deployed inside the target network segment — to accept the inbound tunneled session. The DE lives inside the firewall perimeter, requiring only an outbound HTTPS port 443 to communicate with Secret Server (no inbound rules needed).
The DE retrieves the target credential from the Secret Server vault and injects it at the protocol level (SSH, RDP, SQL). The admin's RDP or SSH client connects to the DE, which presents an authenticated session to the target — the actual password or key is never passed to the client workstation.
All traffic flows through the DE, enabling byte-level session recording, keystroke logging, and live session monitoring. Administrators can view or terminate live sessions from the Secret Server dashboard.
Upon session termination, Secret Server's Remote Password Changer automatically rotates the target credential, making any captured session token useless for subsequent access.
Installing the DE inside a target segment requires no inbound firewall rules. The engine initiates all communication outbound over HTTPS.
Download the Distributed Engine installer from the Secret Server admin portal. Run on a Windows Server 2019+ host with 4GB RAM minimum, positioned inside the target network segment.
After installation, navigate to Admin > Distributed Engine > Manage Sites in Secret Server and approve the new engine. Assign it to the appropriate site (e.g., "PROD-DMZ" or "OT-Network").
Enable the SSH and RDP proxy capabilities on the Distributed Engine site. This configures the DE to accept inbound protocol connections from authorized admin clients.
Every Secret associated with targets in the protected segment must be assigned to the site hosting the Distributed Engine. This ensures credential retrieval happens locally — the vault secret never traverses the external network.
One of the key advantages: the DE requires zero inbound firewall rules. Only outbound HTTPS is required from the DE host.
Every traversal through the Delinea proxy generates a tamper-evident session record. This is the central pillar of privileged access auditability — enabling forensic replay, compliance evidence, and real-time oversight.
Recordings operate at the protocol layer (RDP graphics stream, SSH byte stream) — not a screen recorder overlay. This means recordings are reliable, tamper-resistant, and unaffected by endpoint software.
SSH sessions have all keystrokes extracted and indexed. Auditors can full-text search across
session recordings — e.g., find every session where sudo rm -rf was typed.
Privileged admins (security team) can view active sessions in real time. A single click terminates a suspicious session immediately, and the originating user receives an automatic notification.
Regex-based activity rules trigger alerts when sensitive commands appear — e.g., any command
matching DROP TABLE|passwd|/etc/shadow fires an immediate SIEM notification.
Recording behavior is governed by Security Policy objects attached to Secrets. Multiple policies can coexist for different sensitivity tiers.
Session recordings can be stored in the Secret Server database or offloaded to cloud blob storage for cost-effective long-term retention.
A direct, dimension-by-dimension comparison between the classical jump server model and Delinea's Distributed Engine proxy architecture across security posture, operational efficiency, and compliance coverage.
| Dimension | ⚠️ Traditional Jump Server | ✅ Delinea Proxy (DE) |
|---|---|---|
| Credential Exposure | ✗ Admin receives and types credentials; exposed in memory and potentially in shell history | ✓ Credentials injected at protocol layer; admin endpoint never holds or sees the secret |
| Session Recording | ✗ Requires 3rd-party overlay tools (Citrix, jump-server screen recorder); inconsistent coverage | ✓ Native protocol-level recording on every proxied session; no agent required on target |
| Lateral Movement Risk | ✗ Compromised jump server = keys to the kingdom. Single failure point with large blast radius | ✓ DE has no stored credentials; compromise yields no usable secrets. Rotation invalidates any captured tokens |
| Firewall Complexity | ✗ Inbound rules required on jump server, plus rules from jump to every target; sprawl grows with fleet | ✓ Only outbound port 443 from DE to Secret Server; inbound proxy ports from admin subnet only |
| Credential Rotation | ✗ Manual; often deferred. Long-lived credentials are common after access events | ✓ Automated post-session rotation via Remote Password Changer; configurable per-secret policy |
| MFA Enforcement | ✗ Requires separate MFA solution bolted onto the jump server; inconsistent across protocols | ✓ MFA enforced at Secret Server workflow layer — applies uniformly before any session launch |
| Privileged User Experience | ✗ Two-hop latency; admin must manage jump server login separately from target login | ✓ Single-click launcher from web UI or desktop agent; transparent credential injection |
| Access Request Workflow | ✗ Typically out-of-band (email, ticket) with no automated enforcement or just-in-time capability | ✓ Native workflow with approval chains, time-limited access, and just-in-time provisioning |
| Compliance Coverage | ✗ Partial; separate tools needed for logging, recording, and reporting; gaps require compensating controls | ✓ Unified audit trail: session recordings, keystroke logs, access requests, approvals — all in one platform |
| Scalability | ✗ Jump server becomes a bottleneck; high availability requires complex clustering | ✓ Multiple DEs per site; load balanced automatically. Add engines without reconfiguring firewall rules |
| Zero-Trust Alignment | ✗ Once on the jump server, implicit trust is often extended to the entire target segment | ✓ Per-secret, per-session authorization; no persistent access; continuous verification through policy |
Delinea's proxy model addresses the three most critical weaknesses of traditional jump-box deployments.
Traditional Risk: An attacker who compromises an admin's endpoint can capture credentials from memory (Mimikatz-style), from PuTTY session config, or from bash history files on the jump server. With those credentials, they pivot freely across the entire target segment.
Delinea Mitigation: Since credentials are injected at the protocol layer by the DE, the admin's workstation never holds the plaintext credential. Mimikatz on the admin endpoint yields nothing useful for the target systems. The DE itself holds no credentials between sessions — it fetches them from the vault at session initiation and discards them after injection.
Traditional Risk: The jump server accumulates SSH keys, cached credentials, and network routes to every target. Compromise of this one node provides an attacker with everything needed to traverse the entire protected segment.
Delinea Mitigation: The Distributed Engine is a protocol proxy, not a credential store. A compromised DE node gives an attacker access only to active sessions in progress — not to stored secrets. When credentials are rotated post-session, any token captured during a DE compromise is immediately invalidated. Combined with Secret Server's vault (a separate hardened system), the DE is architecturally less valuable as an attack target.
Traditional Risk: In a traditional model, admins can bypass recording by connecting to target systems directly (if firewall rules are permissive) or by switching to a protocol not covered by the screen recorder. Keystroke indexing is typically unavailable, making forensic investigations slow and incomplete.
Delinea Mitigation: With the firewall configured to block all direct access to the target segment (except from the DE IP), every session must traverse the proxy — and every proxied session is recorded by policy. There is no off-path. Keystroke indexing enables rapid forensic search, and the complete session replay provides irrefutable evidence for compliance audits and incident response.
Test your understanding of the jump-box architecture module. Select the best answer for each question.