Section 01
What Are These Two Launchers?
Both launchers provide privileged remote desktop access managed through Delinea Secret Server. They differ fundamentally in architecture, use-case, and the level of control they provide over session security.
Secret Server Built-in
RDP Launcher
The native RDP Launcher in Secret Server launches a standard Microsoft Remote Desktop Protocol session directly from the browser or Windows client. It automates credential injection into the Windows RDP client (
mstsc.exe), so administrators can connect to servers without ever seeing the plaintext password. The connection is a direct network path from the admin's endpoint to the target machine over TCP port 3389. This is the default tool for internal server access within a trusted network.
Delinea PRA
Privileged Remote Access Launcher
The Delinea PRA Launcher uses BeyondTrust-heritage technology integrated into Delinea's platform to create a proxied, brokered remote access session. It does not require a direct network path between the helper and the target. Instead, all traffic routes through a PRA Jump Client or PRA infrastructure, enabling browser-based support sessions, endpoint-to-endpoint remote assistance, and connections into air-gapped or highly restricted network segments. It supports both IT-to-server and IT-to-end-user-desktop use cases.
Key Mental Model: Think of the RDP Launcher as a smart shortcut for admin-to-server connections on your internal network — it manages passwords, you still dial direct. The PRA Launcher is a secure relay — traffic flows through Delinea's infrastructure, enabling connections across network boundaries without opening firewall rules.
At-a-Glance Comparison
| Attribute | RDP Launcher | PRA Launcher |
|---|---|---|
| Connection Type | Direct (client → target) | Proxied / Brokered |
| Primary Use Case | Admin-to-server (internal) | Admin-to-server + Admin-to-user desktop |
| Requires RDP Port Open | ✓ TCP 3389 required | ✗ No inbound port needed |
| Agent on Target | Agentless | Jump Client (optional or required) |
| Credential Injection | Via Secret Server launcher | Via Secret Server + PRA credential injection |
| Session Recording | Screen capture / keystroke | Full video, keystroke, metadata, chat log |
| End-User Support Capable | ✗ No | ✓ Yes — user can share screen |
| Cross-network / Firewall Traversal | ✗ Requires VPN or direct route | ✓ Works across NAT/firewall |
| License Complexity | Included with Secret Server | Separate PRA license required |
Section 02
Architecture Differences
Understanding how each launcher routes traffic is essential for network planning, security posture design, and troubleshooting connectivity issues.
RDP Launcher — Direct Path
Admin Browser / SS Desktop Client
Secret Server Credential Injection
Secret Server (On-Prem or Cloud)
Launches mstsc.exe / RDP Client
Admin Endpoint (Local RDP Client)
TCP 3389 — Direct Network Path
Target Server / VM
PRA Launcher — Proxied / Brokered
Admin Browser (HTML5 — No Client Needed)
Authenticated via Secret Server + PRA
PRA Infrastructure / Jump Relay
Outbound HTTPS (443) only from target
Jump Client (on Target / Jumpbox)
Proxied RDP or Screen Share
Target Server or End-User Desktop
| Architecture Factor | RDP Launcher | PRA Launcher |
|---|---|---|
| Traffic Flow | Point-to-point. Admin endpoint establishes direct TCP session to target over port 3389. | All traffic routed through Delinea PRA relay/cloud. Admin never has direct IP route to target. |
| Agent Requirement | Agentless — no software required on target. Uses native Windows RDP service (RDS role). | Jump Client software installed on target or an intermediate Jump Host. Can use Jump Items for pre-defined access points. |
| Protocol Used | Microsoft RDP (MS-RDPBCGR). Standard Windows Remote Desktop Protocol. | Proprietary PRA protocol tunneled over HTTPS/TLS 443, with RDP initiated on backend from Jump Client to target. |
| Network Dependency | Requires L3 routing between admin endpoint and target. VPN or same subnet typically needed. | Only requires target (Jump Client) to have outbound HTTPS to PRA relay. Admin needs HTTPS to PRA console. |
| Credential Handling | Secret Server injects credentials into the Windows RDP client before launch — plaintext never exposed. | Credentials from Secret Server injected by PRA into the RDP session brokered at the Jump Client level. |
| Session Broker | No broker — admin's workstation is the RDP client endpoint. | PRA infrastructure acts as full session broker and mediator for all session data. |
| Scalability | Scales with network infrastructure and RDP licensing on target servers. | Scales with PRA instance size/licensing. Supports concurrent sessions across geographies. |
Architecture Implication for Security Teams: With the RDP Launcher, if an admin's workstation is compromised, a threat actor could capture the live RDP session. With PRA, the session is fully brokered — the admin workstation only renders a browser view, reducing lateral movement risk significantly.
Section 03
When to Use Each Launcher
Click each scenario below to reveal the recommended launcher and rationale. Use this as a quick reference during planning or incident response decisions.
Scenario Decision Guide
"I need to RDP into a Windows server on our internal corporate LAN to perform routine maintenance."
+
→ USE: RDP Launcher
The RDP Launcher is ideal here. The target is reachable via direct network path, you need a full desktop session with standard Windows tools, and PRA's overhead (agent, relay, licensing) is unnecessary. Secret Server will inject credentials automatically and log the session.
"A remote employee's laptop has a software issue. I need to view and take control of their screen to troubleshoot it."
+
→ USE: PRA Launcher
RDP Launcher cannot support end-user workstation scenarios — consumer machines are not RDP servers. PRA was specifically built for this: the user runs a small client, shares their screen, and the IT admin takes control through the PRA brokered session. Credential injection can still apply if admin escalation is needed.
"I need to access a server in a DMZ or isolated network segment where we can't open inbound firewall rules to port 3389."
+
→ USE: PRA Launcher
PRA Jump Clients only need outbound HTTPS (443) to the PRA relay — no inbound firewall rules required on the target. This makes PRA the correct choice for DMZ servers, OT/ICS environments, cloud VPCs without VPN, or segmented PCI/HIPAA zones where opening RDP is prohibited.
"We're doing a bulk server patching cycle across 200 internal Windows servers this weekend."
+
→ USE: RDP Launcher
For high-volume admin work on accessible internal servers, RDP Launcher is simpler, lower-latency, and doesn't consume PRA concurrent session licenses. Use it for all internal domain-joined servers reachable on the corporate network. Reserve PRA for scenarios where direct connectivity isn't available.
"A third-party vendor needs temporary access to a server for a support engagement, but we don't want to give them VPN."
+
→ USE: PRA Launcher
PRA supports vendor/third-party access with time-limited Jump Items, full session recording, and no VPN requirement. The vendor receives a link, connects through the PRA relay, and you maintain full audit control. Credentials are still managed by Secret Server and injected at session start — the vendor never sees the password.
"I need to access a server via RDP but I'm currently working from a managed device on the corporate network."
+
→ USE: RDP Launcher
When you have network connectivity, the RDP Launcher provides a full-fidelity session with lower latency than a proxied connection. It leverages the native Windows RDP stack, supports clipboard, drive redirection, and printer mapping that may be restricted in PRA. Use RDP Launcher for day-to-day internal admin work.
"We need compliance-grade session recording with video playback, chat logs, and metadata for an upcoming audit."
+
→ USE: PRA Launcher
PRA's session recording captures full video, keystrokes, chat transcripts, file transfer logs, and session metadata (duration, participants, jump item used). This provides richer audit evidence than Secret Server's built-in screen capture for RDP sessions. For regulated environments, PRA's recording is significantly more defensible in an audit.
"I need both — some servers are internal, some are in isolated networks, and we also support end users."
+
→ USE: Both — Complementary Deployment
This is the most common production scenario. Deploy RDP Launcher as the default for internal server access (fast, agentless, included with Secret Server). Deploy PRA for isolated/OT/cloud segments, third-party vendor access, and all end-user help desk scenarios. Both integrate with Secret Server for unified credential management and audit logging.
RDP Launcher Best Fits
Internal domain-joined servers · Routine admin maintenance · High-volume batch access · Low-latency requirements · Simple network topology
PRA Launcher Best Fits
Isolated / DMZ / OT networks · End-user desktop support · Third-party vendor access · Compliance-grade audit trails · Cross-geography remote access
RDP Launcher Limitations
Cannot cross NAT without VPN · No end-user screen sharing · Limited session recording metadata · Requires TCP 3389 open · Client software needed
PRA Launcher Limitations
Requires Jump Client deployment · Separate PRA license · Slightly higher latency (proxied) · Additional infrastructure complexity · Concurrent session limits
Section 04
Session Recording Quality
Session recording is a key control for privileged access. The two launchers differ significantly in recording depth, playback fidelity, and what data is captured for forensic or compliance review.
RDP Launcher Recording
Screen Capture + Keystroke Logging
Secret Server's RDP recording captures a series of screenshots at configurable intervals (typically every 1–5 seconds) plus a keystroke log. The result is a near-video replay within the Secret Server UI. Recording quality depends on configured interval and screen resolution. For fast-moving terminal sessions, low-frequency capture may miss brief window activity.
Recorded data includes: screenshot frames, typed keystrokes (including passwords if typed manually), session start/end times, and the Secret Server user who launched the session.
Recorded data includes: screenshot frames, typed keystrokes (including passwords if typed manually), session start/end times, and the Secret Server user who launched the session.
PRA Launcher Recording
Full Video + Rich Session Metadata
Delinea PRA captures a continuous video recording of the session at the native screen resolution, along with the full keystroke log, clipboard content, file transfers, and chat messages (if a support chat occurred). The session is stored as a proper video file with a complete metadata envelope.
Recorded data includes: full-motion video, all keystrokes, chat transcripts, file transfer logs, screen resolution changes, session participants, Jump Item used, credential injected, duration, and exit code.
Recorded data includes: full-motion video, all keystrokes, chat transcripts, file transfer logs, screen resolution changes, session participants, Jump Item used, credential injected, duration, and exit code.
Recording Capability Comparison
Compliance Note: For regulatory frameworks like PCI-DSS, SOX, or HIPAA that require full session audit trails for privileged access, PRA's continuous video recording and rich metadata provide substantially stronger evidence. RDP Launcher recording may satisfy basic PAM audit requirements but can fall short in forensic investigations where precise timing matters.
| Recording Feature | RDP Launcher | PRA Launcher |
|---|---|---|
| Recording Format | Screenshot frames + keystroke log stored in Secret Server DB | Compressed video file (proprietary format) with searchable transcript |
| Playback Interface | Built-in Secret Server session player (frame-by-frame) | PRA console video player with timeline, search, and jump-to-keystroke |
| Storage Location | Secret Server database or configured file store | PRA appliance/cloud storage, exportable to SIEM or external storage |
| SIEM Integration | Session metadata events forwarded via Syslog/SIEM | Full session event stream, including in-session events, to SIEM |
| Tamper Evidence | Relies on Secret Server audit controls | Cryptographically signed recordings in PRA |
Section 05
Credential Injection Method
Both launchers ensure privileged credentials are never exposed to the person initiating the session. The mechanism and injection point differ by launcher type.
RDP Launcher
Client-Side Injection via Windows API
When the RDP Launcher is triggered from Secret Server, the platform fetches the stored credential from the Secret Server vault and passes it to the Windows Remote Desktop client (
If using the browser-based launcher (HTML5 RDP viewer via Secret Server's web client), credentials are injected server-side at the Secret Server level before the session is proxied to the browser, similarly keeping credentials hidden.
Injection Point: At the admin's endpoint (or Secret Server web server for HTML5). Credentials leave the vault, are used to authenticate the RDP session, and are not logged in transit.
mstsc.exe) using the Windows Credential Manager API or DPAPI. The password is injected programmatically into the RDP client process — the admin never sees or types it.
If using the browser-based launcher (HTML5 RDP viewer via Secret Server's web client), credentials are injected server-side at the Secret Server level before the session is proxied to the browser, similarly keeping credentials hidden.
Injection Point: At the admin's endpoint (or Secret Server web server for HTML5). Credentials leave the vault, are used to authenticate the RDP session, and are not logged in transit.
PRA Launcher
Server-Side Injection via Jump Client
In PRA, Secret Server provides the credential to the PRA infrastructure, which uses it to authenticate the RDP session established from the Jump Client to the local target. The credential is injected at the PRA broker/Jump Client level — the admin's browser is never involved in authenticating to the target. The admin connects to PRA; PRA connects to the target.
For end-user sessions (screen share), credential injection still applies when the admin needs to perform elevated actions. PRA supports injecting a separate admin credential while the end-user remains logged in.
Injection Point: PRA relay/Jump Client side. Admin's device has zero credential access — all auth handled server-to-server.
For end-user sessions (screen share), credential injection still applies when the admin needs to perform elevated actions. PRA supports injecting a separate admin credential while the end-user remains logged in.
Injection Point: PRA relay/Jump Client side. Admin's device has zero credential access — all auth handled server-to-server.
| Credential Aspect | RDP Launcher | PRA Launcher |
|---|---|---|
| Who Holds the Credential | Secret Server vault; passed to Windows Credential Manager on admin endpoint | Secret Server vault; passed to PRA infrastructure — never reaches admin endpoint |
| Where Injection Occurs | On the admin's workstation (Windows API or browser plugin) | At PRA relay or Jump Client, server-side |
| Admin Can See Password | No — masked in Secret Server UI; injected programmatically ✓ Secure | No — admin never has credential on their device at all ✓ More Secure |
| Credential Checkout Required | Can be configured with Check-Out enforcement in Secret Server | Integrated with Secret Server Check-Out; session tied to lease |
| Dual Account Support | Single credential injected per session | Supports injecting admin credential alongside user session (elevation use case) |
| Password Rotation Post-Session | Triggered by Secret Server RPC on session close (if configured) | Triggered by Secret Server via PRA session close event |
| MFA Before Launch | Secret Server MFA enforced at login; optional step-up for launch | Secret Server MFA + PRA can enforce additional authentication at session start |
| Risk if Admin Endpoint Compromised | Credential exists in Windows Credential Manager during session — potential extraction risk ⚠ Risk | Admin endpoint only has browser session — no credential on device ✓ Lower Risk |
Security Consideration — Credential on Endpoint: With the RDP Launcher, the credential is briefly present in the Windows Credential Manager on the admin's workstation during injection. A sophisticated attacker with access to that workstation could attempt to extract it during the session window. PRA eliminates this exposure entirely since no credential ever reaches the admin device — only a browser session to the PRA relay exists.
Section 06
Network & Firewall Requirements
One of the most operationally significant differences between the two launchers is their network model. RDP requires direct IP connectivity; PRA only requires outbound HTTPS from target systems.
RDP Launcher — Firewall Needs
Direct Network Path Required
The admin's workstation must have a routable path to the target server's IP address on TCP port 3389. For internal networks, this is typically already available. For remote admins, a VPN connection is required to establish this routing. The firewall between the admin and target must permit TCP 3389 inbound on the target side.
Additionally, Secret Server itself must be able to reach the target on relevant management ports for heartbeat and rotation (WMI TCP 135, RPC, etc.).
Additionally, Secret Server itself must be able to reach the target on relevant management ports for heartbeat and rotation (WMI TCP 135, RPC, etc.).
PRA Launcher — Firewall Needs
Outbound-Only from Target
The Jump Client installed on target systems requires only outbound HTTPS (TCP 443) to the PRA cloud or on-premise appliance. No inbound firewall rules need to be opened on the target. The admin connects to the PRA console (HTTPS 443), and the session is brokered entirely over this outbound channel.
This model is ideal for DMZ, OT, cloud VPCs, or any segment where security policy prohibits inbound access. PRA's relay architecture means the two endpoints never communicate directly.
This model is ideal for DMZ, OT, cloud VPCs, or any segment where security policy prohibits inbound access. PRA's relay architecture means the two endpoints never communicate directly.
Port Reference Table
| Port / Protocol | Direction | Required For | Launcher |
|---|---|---|---|
| TCP 3389 | Admin → Target (inbound on target) | Microsoft RDP connection for session | RDP Launcher only |
| TCP 443 HTTPS | Admin → Secret Server | Secret Server web UI, launcher API | Both |
| TCP 443 HTTPS | Admin → PRA Relay | Admin session to PRA console | PRA Launcher only |
| TCP 443 HTTPS | Target → PRA Relay (outbound) | Jump Client registration and session tunnel | PRA Launcher only |
| TCP 135 + high RPC | Secret Server → Target | Secret Server heartbeat / password rotation (Windows) | Both (via Secret Server) |
| TCP 22 SSH | Admin → Target | SSH Launcher (separate protocol, for Linux) | RDP Launcher analog (SSH) |
| UDP 3389 | Admin → Target | RDP UDP transport (optional, performance) | RDP Launcher only |
Network Topology Use Cases
| Network Scenario | RDP Launcher | PRA Launcher |
|---|---|---|
| Internal LAN / Corporate Network | ✅ Works natively — direct route available | ✅ Works — slightly higher latency due to proxy |
| Remote Admin (No VPN) | ❌ No direct route — 3389 typically blocked at edge | ✅ Works — only needs outbound 443 from both sides |
| Remote Admin (With VPN) | ✅ Works if VPN provides full tunnel routing | ✅ Works — VPN not required but doesn't conflict |
| DMZ / Perimeter Network | ⚠️ Requires firewall rule opening 3389 inbound — high risk | ✅ Ideal use case — Jump Client needs only outbound 443 |
| OT / ICS / Air-Gapped Network | ❌ Cannot reach admin endpoint from highly isolated segment | ✅ Jump Client or Jump Proxy handles isolated segment traversal |
| Cloud VPC (AWS / Azure / GCP) | ⚠️ Requires peering, VPN gateway, or public IP + NSG rule | ✅ Jump Client in VPC; only outbound 443 to PRA relay needed |
| Third-Party / Vendor Network | ❌ Infeasible without complex firewall coordination | ✅ Vendor installs Jump Client; no customer network change required |
Network Design Best Practice: In a mature Delinea deployment, configure PRA Jump Clients as the standard access method for any target in a segment you don't fully control or that sits behind a security boundary. Reserve the RDP Launcher for the "green zone" — servers in your primary internal network segment where IT has full routing control and VPN is enforced for remote admins.
Section 07
User Experience Differences
The experience differs significantly between IT administrators (the helpers) and end users (being supported). Toggle between perspectives below to understand what each party encounters.
RDP Launcher — Admin Experience
1
Log in to Secret Server web portal or desktop client. Navigate to the target server's secret via folder structure or search.
2
Click the RDP Launcher button on the secret. Secret Server fetches and injects credentials into Windows RDP client (
mstsc.exe).
3
Windows Remote Desktop window opens — full native RDP session with all standard features: clipboard, drive redirection, multiple monitors.
4
Work in the session normally. All screen activity and keystrokes are being captured by Secret Server in the background.
5
Close the RDP window. Secret Server logs session end. Password rotation triggers automatically if configured. Session recording saved.
PRA Launcher — Admin Experience
1
Log in to Secret Server. Navigate to target secret or use the PRA Jump Client inventory. Both Secret Server and PRA are accessible from a unified interface.
2
Click the PRA Launcher. Browser opens the PRA representative console (web-based or downloadable app). No RDP client required on the admin's machine.
3
Session opens in the PRA console — a proxied RDP view rendered in the browser. Navigation, controls, and keyboard shortcuts work as expected.
4
Additional PRA tools available: in-session chat, file transfer panel, session notes, co-browser option, ability to invite other admins to observe.
5
End session. PRA saves the full video recording and metadata. Post-session survey can be sent to end user if applicable. Auto-rotation fires via Secret Server event.
| Admin UX Factor | RDP Launcher | PRA Launcher |
|---|---|---|
| Client Software Required | Windows RDP client (mstsc.exe) — standard on Windows; macOS needs Microsoft Remote Desktop app | Browser-only option available (HTML5); optional downloadable representative app for advanced features |
| Session Performance | Full native RDP performance — bandwidth-efficient, low latency on LAN | Proxied — slightly higher latency, especially over WAN. Quality depends on PRA infrastructure proximity. |
| Multi-Monitor Support | Full multi-monitor RDP support via mstsc flags | Single window in browser; downloadable PRA client supports multi-monitor |
| Clipboard Sharing | Full clipboard redirect (text, files, images) via RDP protocol | Text clipboard in browser mode; full clipboard in PRA app; file transfer via dedicated panel |
| Drive / Printer Redirection | Supported via RDP redirectors if policy allows | File transfer via PRA file transfer feature; printer redirection limited |
| Session Invitation | Not available — single admin session | Admin can invite another admin to observe or take control |
| Access Without VPN | Not possible (requires direct network path) | Fully supported — browser + HTTPS only |
Context: The end user perspective only applies to the PRA Launcher in a help desk / remote support scenario. The RDP Launcher is an admin-to-server tool — the server has no "end user" experiencing the session.
RDP Launcher — End User Experience
—
Not applicable for end-user support. The RDP Launcher connects an IT administrator to a server. End users working on their own workstation are not accessible via the RDP Launcher.
—
If an admin uses RDP to connect to a server that users are actively logged into (e.g., a terminal server), the admin's session does not interact with the user's session — it is a separate admin session.
—
For end-user desktop support scenarios, you must use PRA Launcher. RDP to a workstation requires the user to be logged out in most configurations, making it unsuitable for live support.
PRA Launcher — End User Experience
1
IT admin initiates a support session in PRA. A session link or PIN is generated and sent to the end user via email, chat, or phone.
2
End user visits a web URL (e.g.,
support.company.com) and enters their session PIN — or clicks a direct session link. No prior software installation required in browser-based mode.
3
A small PRA Customer Client runs (or runs from browser). The user sees a consent prompt confirming that IT will be viewing their screen, and can choose to allow or deny.
4
During the session, the user can see a toolbar showing the session is active. They can chat with the admin via the built-in chat window and observe everything being done on their screen.
5
When the session ends, the user receives a notification that IT has disconnected. An optional post-session satisfaction survey may appear. No software remains installed permanently.
| End User UX Factor | RDP Launcher | PRA Launcher |
|---|---|---|
| User Can See Session | N/A — Admin-to-server connection; no user desktop involved | Yes — user sees everything the admin does in real time on their own screen |
| Consent Mechanism | N/A | Explicit consent prompt before admin takes control; user can deny access |
| User Can Interact During Session | N/A | Yes — dual control; both user and admin can use mouse/keyboard |
| Session Visibility to User | N/A | PRA taskbar icon visible during session; user knows they're being supported |
| User Consent to Terminate | N/A | User can end the session at any time by closing the PRA client |
| Software Installation Impact | N/A — user's machine not involved | Zero persistent installation (browser mode); lightweight client auto-removes post-session |
| Post-Session Feedback | N/A | Optional satisfaction survey; configurable by PRA admin |
| User Privacy Awareness | N/A | User is informed when recording begins; privacy-compliant consent workflow |