DL
Delinea // PRA Training
Progress
0%
Product Training Module · PRA-101

Privileged
Remote Access
Without VPN

Secure, credential-injected RDP, SSH, and web sessions to any server or desktop — clientless, MFA-enforced, and fully recorded. No jump servers required.

6
Modules
~45
Minutes
3
Protocol Types
10
Quiz Questions
MOD-01

PRA Architecture Overview

Session Flow — Credential-Injected Remote Access
👤
Privileged User
Browser Only
HTTPS/443
🔐
MFA Gateway
TOTP · Push · FIDO2
Verified
🛡️
PRA Connector
Access Zone · Vault
Injected Creds
🖥️
Target System
RDP · SSH · Web
Privileged User
MFA Enforcement
PRA Connector / Vault
Target System
✓ No VPN Required   ✓ Credentials Never Exposed
🔌

PRA Connector

Lightweight agent deployed inside your network perimeter. Establishes outbound-only encrypted tunnel to the PRA cloud broker — no inbound firewall rules needed.

🏗️

Access Zones

Logical groupings of resources (servers, subnets, applications) mapped to connectors. Each zone enforces its own policy, MFA requirements, and session recording rules.

💉

Credential Injection

Credentials are fetched from the Secret Server vault at session time and injected transparently. Users never see or handle passwords — eliminating credential theft risk.

MOD-02

PRA vs Traditional VPN + Jump Server

Dimension ✦ Delinea PRA ⚠ VPN + Jump Server
Client Requirement Browser only — zero agent install VPN client + RDP/SSH client required
Credential Exposure Injected silently — user never sees password Users must manually enter (and often know) credentials
Lateral Movement Risk Zero-trust per session — no network broadcast VPN grants broad network access; jump server is pivot point
MFA Enforcement Mandatory before every session, per-zone policy ~ VPN may have MFA; jump server often does not
Session Recording Full video + keystroke capture, tamper-proof Requires additional tooling; often not enforced
Access Granularity Per-server, per-account, time-limited Subnet or host-level at best
Audit Trail Who, what, when — searchable playback ~ Log files only — no visual replay
Attack Surface No inbound ports; no exposed RDP/SSH Jump server = high-value target with open ports
Deployment Complexity Connector + cloud config; minutes to deploy VPN infrastructure + jump server hardening required
Scalability Cloud-native; add connectors as you grow Jump servers become bottlenecks
✦ Delinea PRA Security Model
🎯

Zero Trust Per Session

Every session is independently authenticated and authorized. No standing network access is granted. Sessions are bound to specific accounts and targets — access expires the moment the session ends.

🚫

No Exposed Attack Surface

The PRA Connector makes outbound-only connections. No RDP (3389) or SSH (22) ports exposed to the internet. The target systems remain unreachable except through PRA.

🔑

Credential Isolation

Secrets are retrieved from vault at session initiation and never cached on client endpoints. Rotating credentials does not break user workflows.

⚠ VPN + Jump Server Risks
🌐

Broad Network Exposure

VPN access typically grants users access to an entire network segment — far more than needed for a single administrative task. This violates least-privilege principles.

🏴‍☠️

Jump Server as Crown Jewel

Attackers who compromise a jump server gain a highly privileged position with direct access to all downstream systems. Single point of failure for enterprise access.

📋

Credential Sprawl

Users often save credentials locally or reuse passwords. Credential rotation requires manual update of saved configs. High risk of password spray and credential stuffing attacks.

PRA User Experience
1. Open browser, navigate to PRA portal
2. Authenticate with SSO + MFA
3. Browse/search for target system
4. Click Launch Session
5. RDP/SSH/Web session opens in browser tab
6. Work without ever entering credentials
7. Close tab — session ends, recorded automatically
💡
Total time from login to working session: < 30 seconds. Works on any device with a modern browser, including tablets and Chromebooks.
VPN + Jump Server Experience
1. Launch VPN client, enter credentials + MFA
2. Wait for VPN tunnel to establish
3. Open RDP/SSH client application
4. Enter jump server IP + credentials
5. From jump server, connect to target system
6. Enter target credentials again
7. Work; disconnect manually from both hops
Multiple credential prompts, client software required, slow on high-latency connections. Frequently fails on public networks or shared machines.
MOD-03

Configuring Access Zones & Jump Points

Access Zones define logical security boundaries that group resources and apply unified policy. Each zone is associated with one or more PRA Connectors and enforces its own MFA, recording, and authorization rules.

1
Navigate to Access > Zones in the PRA Admin Console
Admin Console → Access Management → Zones → Create New Zone
In the PRA Admin Console, navigate to AccessZones. Click Create Zone. Assign a descriptive name reflecting the network segment (e.g., PROD-DMZ, CORP-Servers, AWS-East-1). Add a description that identifies the zone owner and purpose for future auditing.
2
Assign a PRA Connector to the Zone
The connector is your network bridge — it must be deployed inside the target segment
Under Connectors in the zone settings, select existing deployed connectors or download the connector installer to deploy a new one. The connector runs as a Windows Service or Linux daemon and needs outbound HTTPS (443) to *.delinea.app. No inbound ports required. For redundancy, assign two or more connectors per zone.
# Linux connector install (example)
wget https://downloads.delinea.app/pra-connector/latest/pra-connector.deb
sudo dpkg -i pra-connector.deb
sudo pra-connector configure --enrollment-token <TOKEN>
sudo systemctl enable --now pra-connector
3
Define Zone Policies
MFA requirements, session recording, idle timeout, and allowed protocols
Zone Policies control what happens inside the zone:

MFA Policy — Require TOTP, push, or FIDO2 before session launch
Recording Policy — Enable video recording and/or keystroke logging
Protocol Allowlist — Restrict to RDP only, SSH only, or both
Idle Timeout — Auto-terminate sessions after N minutes of inactivity
IP Restrictions — Limit access to specific user source IP ranges
4
Add Target Systems to the Zone
Individual servers, IP ranges, or Active Directory OUs
Target systems can be added individually (hostname/IP), as CIDR ranges, or via AD connector sync. Each target system gets associated with one or more privileged accounts from Secret Server. The account-to-target mapping determines what credentials are injected during the session.

Supported target types: Windows Server (RDP) Linux/Unix (SSH) Web Applications Network Devices

Jump Points act as protocol proxies within an Access Zone, brokering RDP and SSH connections from the PRA cloud to internal targets. They replace traditional jump servers while providing full session control.

Jump Point Types
🖥 Windows Jump Point — Uses RDP reflector service; supports Windows target systems
🐧 Linux Jump Point — Runs SSH proxy daemon; targets Unix/Linux systems
☁️ Cloud Jump Point — Fully managed by Delinea; for SaaS/cloud targets
🌐 Web Jump Point — Chromium-based headless proxy for web applications
Jump Point Requirements
• Outbound HTTPS 443 to PRA cloud
• Can reach target systems on RDP/SSH ports
• Minimum: 2 vCPU, 4 GB RAM per 50 concurrent sessions
• Recommend 2+ for HA within each zone
• Windows Server 2016+ or Ubuntu 20.04+
Jump Point Health Check
admin@pra-jumppoint-01 $ pra-jump status
✔ PRA Cloud Connection: CONNECTED (relay.us-east-1.delinea.app:443)
✔ Zone Registration: PROD-DMZ (connector: pra-conn-01)
✔ RDP Proxy: LISTENING (internal, port 3389 inbound disabled)
✔ SSH Proxy: LISTENING (internal, port 22 inbound disabled)
ℹ Active Sessions: 7 / 50 (14% capacity)
ℹ Last Health Beacon: 2s ago
admin@pra-jumppoint-01 $ _

Privileged accounts are stored in Secret Server and linked to PRA target systems. At session time, PRA fetches the current credential and injects it — the user is never involved in credential handling.

1
Create or Import Accounts in Secret Server
Use templates for Windows Admin, Unix Root, Service Accounts, etc.
In Secret Server, use a relevant template (Windows Account, Unix Account, Web Password) to create or import privileged accounts. Enable Remote Password Changing (RPC) to auto-rotate credentials after each use or on a schedule.
2
Associate Accounts with PRA Target Systems
Link Secret Server secrets to PRA system definitions
In PRA, navigate to the target system definition and under Credentials, click Link Secret. Browse or search Secret Server to select the appropriate secret. You can link multiple secrets (e.g., local admin + domain admin) and users will choose at session launch time.
3
Configure Checkout & Approval Workflows (Optional)
Require manager approval before sensitive credential injection
For highly sensitive systems, enable Secret Checkout — only one session can use the account at a time, preventing concurrent privilege abuse. Optionally configure Access Request Workflows requiring manager approval before PRA launches the session.

Approvals can be routed via email, Slack, or ServiceNow ticket integration.

Clientless sessions run entirely inside the browser using HTML5 canvas rendering of RDP/SSH output. No Java, no ActiveX, no native client — just a URL.

🖥️

Browser-Based RDP

RDP sessions stream as compressed video frames to the browser canvas. Keyboard and mouse events are relayed back. Supports clipboard sync, file transfer via HTML5 drag-drop, and multi-monitor spanning.

⌨️

Browser-Based SSH

Full xterm.js terminal emulator in the browser. Supports ANSI colors, terminal resize, and paste. SSH key injection supported — no need for password auth on target systems.

🌐

Web Application Access

Chromium headless proxy allows PRA to auto-fill credentials into internal web applications — including legacy apps that cannot integrate with SSO. Supports form-fill, NTLM, and Basic auth injection.

Session Launch URL Format
# RDP Session Direct Launch
https://company.delinea.app/pra/launch
?target=WIN-PROD-DB01
&protocol=rdp
&zone=PROD-DMZ
&account=svc_dba_prod

# SSH Session Direct Launch
https://company.delinea.app/pra/launch
?target=linux-app-01.corp
&protocol=ssh
&zone=CORP-Servers

✔ Credentials injected from vault at session time
✔ MFA prompt triggered automatically
MOD-04

Enforcing MFA Before Session Initiation

Delinea PRA enforces MFA at the session layer — not just at login. Even if a user is already authenticated to the portal, launching a session to a sensitive system triggers a fresh MFA challenge, providing defense-in-depth against stolen session tokens.

MFA Session Enforcement Flow
👤SSO Login
Portal Auth
🔍Request
Session
Target + Account
🔐MFA
Challenge
Per-Zone Policy
💉Cred
Injection
From Vault
🟢Session
Launched
Recorded
📱

TOTP (Authenticator App)

Works with Google Authenticator, Microsoft Authenticator, Authy. 6-digit codes, 30-second window. Supported on all zones; lowest friction for regular users.

🔔

Push Notification

Duo Security or Delinea Mobile push. User taps Approve on phone. Integrates with number matching to prevent MFA fatigue attacks.

🔑

FIDO2 / Hardware Key

YubiKey, Windows Hello, Touch ID. Strongest assurance level; recommended for production systems. Phishing-resistant by design.

Zone MFA Config (JSON)
// Access Zone Policy — mfa_settings
{
  "require_mfa": true,
  "mfa_methods": [
    "fido2", "push", "totp"
  ],
  "mfa_per_session": true,
  "mfa_grace_period_min": 0,
  "step_up_for_accounts": [
    "domain_admin",
    "root", "Administrator"
  ],
  "deny_on_mfa_fail": true
}
💡
Step-Up MFA — Configure higher assurance factors for elevated accounts like Domain Admin or root, while allowing TOTP for standard server access. Balances security with usability.
⏱️

Grace Period = 0

Setting mfa_grace_period_min to 0 ensures MFA is required for every session launch, regardless of recent authentications. Recommended for production and sensitive zones.

🚨

MFA Fatigue Protection

Enable number matching on push notifications. Users must type the displayed number into their phone app — preventing blind approval of attacker-triggered sessions.

MOD-05

Session Recording & Audit

All PRA sessions can be recorded as tamper-proof video with synchronized keystroke logging and metadata. Recordings are stored encrypted and are fully searchable — enabling rapid incident response and compliance reporting.

🎥
Video Session Recording

Full pixel-accurate video of every RDP and SSH session. Frame-level compression stores hours of recording in minimal storage. Playback available directly in admin console.

⌨️
Keystroke Logging

Every keystroke captured and timestamped — fully searchable by keyword. Find any session where a specific command was run or file was accessed, even without watching video.

🔒
Tamper-Proof Storage

Recordings are signed with cryptographic hashes. Any modification to the recording file invalidates the signature — providing court-admissible evidence of privileged activity.

🔎
Full-Text Search

Search keystroke logs across all sessions. Query by user, target, date range, or typed content. Results link directly to the exact timestamp in the video recording.

Real-Time Session Monitoring

Admins can view live sessions in progress and send instant messages to the user, or forcibly terminate a session if suspicious activity is detected.

📊
SIEM & SOAR Integration

Session metadata and keystroke events stream to Splunk, Microsoft Sentinel, or any CEF/syslog SIEM. Trigger automated playbooks on detection of privileged command execution.

Keystroke Search API
# Search for all sessions where 'net user' was run
GET /api/v2/pra/sessions/search

{
  "query": "net user /add",
  "date_from": "2025-01-01",
  "zones": ["PROD-DMZ"],
  "include_video_link": true
}

# Response includes video timestamp deep-link
→ 3 sessions found
→ Video links with exact frame offset
Recording Policy — Zone Config
Enable Recording per Zone
Zone Settings → Recording → Enable Video + Keystrokes
Navigate to Zone → Settings → Session Recording. Toggle on Video Recording and Keystroke Logging. Set retention period (default 90 days, extendable).
2
Configure Storage Destination
PRA Cloud storage or self-hosted S3-compatible bucket
Recordings can be stored in Delinea-managed cloud storage or forwarded to your own S3, Azure Blob, or GCS bucket for data sovereignty compliance. Configure encryption keys (BYOK supported).
3
Set Alert Rules
Trigger alerts on specific commands or unusual patterns
Define behavioral alert rules — e.g., alert if sudo su, rm -rf, or net localgroup administrators is typed. Alerts route to admin email, PagerDuty, or ServiceNow.
LAB-01

Hands-On Lab Exercise

Guided Lab

Configure PRA for a Production Web Server Fleet

Estimated time: 20–30 minutes · Requires: PRA Tenant + Secret Server access

In this lab you will configure a complete PRA deployment for a hypothetical production web server fleet (PROD-WEB zone). Complete each task and check it off as you go — your progress is tracked.

Progress: 0 / 10 tasks completed
Part 1 — Zone Setup
Create Access Zone "PROD-WEB" Navigate to Access → Zones → Create Zone. Name it PROD-WEB. Set description to "Production web server fleet (nginx/IIS)". Assign to the correct network segment.
Install PRA Connector in DMZ Download the connector installer for your OS. Run the installer and use the enrollment token from the zone settings to register. Verify the connector shows as Connected in the admin console.
Set Zone MFA Policy to FIDO2 + TOTP, per-session, no grace period Zone Settings → MFA Policy. Enable both FIDO2 and TOTP methods. Set mfa_per_session = true and grace period = 0 minutes.
Part 2 — Jump Point & Targets
Deploy Linux Jump Point for SSH access Install the PRA Jump Point service on a Linux VM in the DMZ. Verify it can reach target servers on port 22 and connects to PRA cloud on port 443.
Add 3 target web servers to PROD-WEB zone Add web-prod-01, web-prod-02, web-prod-03 (use IPs or hostnames). Set protocol to SSH. Verify each appears as Reachable in the system health check.
Link Secret Server account "svc_webadmin" to all three targets For each target, go to Credentials → Link Secret → select svc_webadmin. Enable Remote Password Changing with 30-day rotation.
Part 3 — Session Recording
Enable Video Recording and Keystroke Logging on PROD-WEB zone Zone Settings → Session Recording → Enable both. Set retention to 180 days. Configure your S3 bucket as the storage destination.
Create alert rule for "sudo su" keystroke pattern Recording → Alert Rules → New Rule. Pattern: sudo su. Action: Email admin@corp.com + create ServiceNow incident.
Part 4 — Validation
Launch a test SSH session to web-prod-01 as a non-admin user Log in as a standard user. Navigate to PROD-WEB zone → web-prod-01 → Launch Session (SSH). Complete the MFA challenge. Verify the session opens without entering credentials.
Verify session recording exists and is searchable After closing the session, go to Reports → Session Recordings. Find the recording for web-prod-01. Play it back. Verify the keystroke log shows the commands you typed.
QUIZ

Knowledge Check

Test your understanding of Delinea PRA. Select the best answer for each question.

1. What is the primary function of the PRA Connector?
It opens inbound firewall ports for RDP and SSH traffic
It establishes outbound-only encrypted tunnels from the internal network to the PRA cloud broker
It replaces Active Directory for identity management
It stores all session recordings locally on-premises
✓ Correct! The PRA Connector makes outbound-only connections to the PRA cloud relay. This means no inbound firewall rules are needed — dramatically reducing attack surface.
2. Why do users never see or handle passwords in a PRA session?
Passwords are stored in the user's browser keychain and auto-filled
PRA uses certificate-based authentication exclusively
Credentials are fetched from the Secret Server vault at session time and injected transparently by PRA
All target systems are configured for passwordless Windows Hello authentication
✓ Correct! Credential injection means PRA fetches the current password from Secret Server and injects it into the RDP/SSH handshake on behalf of the user — the user is never involved in credential handling.
3. A security auditor asks why PRA is more secure than a traditional VPN + jump server approach for lateral movement risk. What is the best answer?
PRA uses stronger encryption algorithms than VPN
VPN grants broad network access enabling lateral movement; PRA grants per-session, per-account access to only the specific target system
PRA does not support remote access to Windows systems, which are the main target of attacks
VPN connections are always unencrypted
✓ Correct! VPN grants users access to an entire network segment, enabling lateral movement after initial compromise. PRA's zero-trust model grants access only to the specific system for the duration of the authenticated session.
4. What does setting mfa_grace_period_min to 0 accomplish?
It disables MFA for emergency break-glass access
It allows users 0 attempts before being locked out
MFA is required for every session launch with no exemption based on recent authentications
Sessions expire immediately after launch
✓ Correct! A grace period of 0 means there is no window during which a recent MFA is considered valid for a new session. Every session launch, regardless of how recently the user authenticated, triggers a fresh MFA challenge.
5. Which of the following is a key advantage of clientless browser-based sessions in PRA?
They provide higher performance than native RDP clients
They require a special PRA browser extension to function
No agent or client software installation is required — sessions work on any device with a modern browser
They bypass MFA requirements for faster access
✓ Correct! Clientless sessions run entirely in the browser using HTML5 canvas rendering of RDP/SSH output. This works on any modern browser — including on tablets, Chromebooks, or any device where installing software is impractical.
6. What mechanism protects against MFA fatigue attacks on push notification MFA?
Requiring users to re-enter their password before approving a push
Number matching — users must type a displayed number into their authenticator app before approving
Limiting push notifications to daytime hours only
Automatically blocking users after 3 push denials
✓ Correct! Number matching requires the user to type a specific number displayed on the authentication screen into their authenticator app — preventing attackers from getting users to blindly approve push notifications.
7. How does PRA's session recording provide court-admissible evidence?
Recordings are stored in immutable cloud storage that cannot be deleted
Recordings are signed with cryptographic hashes — any modification invalidates the signature
A third-party notary service witnesses all recording creation
Recordings are stored in read-only NFS shares
✓ Correct! Cryptographic signing means that any tampering with the recording file will produce a hash mismatch. This provides integrity assurance that the recording has not been altered since it was created.
8. What is the purpose of Access Zones in PRA?
They are network VLANs that segment traffic physically
They replace firewall rules for inbound traffic filtering
Logical groupings of resources that apply unified MFA, recording, and authorization policies to all systems within the group
Geographic regions that determine which PRA cloud datacenter handles the session
✓ Correct! Access Zones are logical constructs — not network segments. They group resources that should share the same security policy, making it easy to enforce consistent MFA and recording requirements across a fleet of similar systems.
9. An engineer wants to ensure only one privileged user can access a production database account at a time. What PRA/Secret Server feature addresses this?
Session Concurrency Limit in the Jump Point config
Secret Checkout — prevents concurrent sessions using the same privileged account
Single Sign-On enforced at the zone level
FIDO2 hardware keys which are physically exclusive to one person
✓ Correct! Secret Checkout in Secret Server allows only one session to check out and use a secret at a time. This prevents concurrent privilege abuse where multiple users could be using the same privileged account simultaneously.
10. Which network ports does the PRA Connector need to have open, and in which direction?
Inbound TCP 443 and TCP 3389 from the internet
Inbound TCP 22 and TCP 3389 from the PRA cloud
Outbound TCP 443 to the PRA cloud — no inbound ports required
Both inbound and outbound TCP 8443 for bidirectional proxy traffic
✓ Correct! The PRA Connector only needs outbound HTTPS (TCP 443) to the PRA cloud relay. No inbound firewall rules are required — this is a fundamental security advantage as it eliminates exposed inbound ports.
Score