Rdp launcher training guide 1

Overview

Both launchers enable privileged remote access from within Secret Server, but they serve distinct use cases and have fundamentally different designs. Understanding the difference is the first step to deploying the right tool.

🖥️

Secret Server RDP Launcher

BUILT-IN · DIRECT CONNECTION

The native RDP Launcher is baked into Secret Server. It invokes the Windows Remote Desktop client (mstsc.exe) or a compatible RDP app, passing credentials automatically so the IT admin never sees or types them. The connection is a standard Microsoft RDP session from the admin's workstation directly to the target.

🔐

Delinea PRA Launcher

PRIVILEGED REMOTE ACCESS · PROXIED

The PRA Launcher (Privileged Remote Access) is a separate Delinea product integrated with Secret Server. It enables third-party vendors, contractors, or internal staff to access end-user desktops or servers through a fully brokered, clientless session — no VPN or direct network path required.

Feature Comparison at a Glance

Feature	RDP Launcher	PRA Launcher
Connection Type	Direct client-to-target RDP	Fully proxied / brokered session
VPN Required	Usually Yes	No
Client Software	mstsc.exe or RDP client	Browser only (clientless)
Credential Injection	Injected at launch (not shown)	Injected server-side at broker
Session Recording	Video-level (requires Protocol Handler)	Native HD with metadata
Primary User	Internal IT Admins	Vendors, 3rd parties, remote support
Target Support	Windows (RDP targets)	Windows, Linux, web apps, custom
Firewall Requirements	Port 3389 open to target	Outbound 443 only
Agent on Target	Not Required	Optional (enhances capabilities)
Audit Trail	Secret access log + video	Full session audit + keystrokes

Architecture Differences

The most important distinction is direct vs. proxied connectivity. This architectural choice cascades into every other difference: firewall rules, credential exposure, recording quality, and who can use each launcher.

🖥️ RDP Launcher — Direct Connection Flow

Admin Workstation

Gets creds

Secret Server Vault

mstsc launch

Direct RDP :3389

RDP session

Target Windows Server

🔐 PRA Launcher — Proxied / Brokered Flow

User Web Browser

HTTPS :443

Delinea PRA Broker

Injects creds

Secret Server Vault

Brokered RDP/SSH

Target Server / Desktop

⚡

RDP Launcher Architecture

DIRECT / AGENTLESS

1Admin clicks "Launch" inside Secret Server's web interface.
2Secret Server's Protocol Handler (a small browser extension or helper app) invokes mstsc.exe with injected credentials.
3The RDP client opens a native Windows Remote Desktop window connecting directly to the target on port 3389.
4No agent is needed on the target. No brokering occurs — this is a peer-to-peer RDP session.

Key Point: The admin's workstation must have a routable network path to the target. This usually means VPN or being on the same corporate LAN.

🔗

PRA Launcher Architecture

PROXIED / OPTIONALLY AGENT-ASSISTED

1User (vendor, contractor, or IT) opens their browser and logs into Secret Server / PRA portal.
2A session request is sent to the PRA broker. The broker retrieves credentials from Secret Server's vault.
3The PRA broker establishes the RDP/SSH connection to the target on behalf of the user.
4The user sees the remote desktop rendered inside the browser. They never receive or see the credentials.

Key Point: The user's device has no direct network path to the target. All traffic flows through the PRA broker, which sits inside (or securely bridges to) the target network.

💡

Agent vs. Agentless The RDP Launcher is fully agentless — nothing is installed on the target machine. PRA is also agentless by default but optionally deploys a lightweight Jump Client or Jumpoint component on the target network to improve session performance, support non-RDP protocols (SSH, VNC), and enable unattended access to endpoints behind firewalls.

When to Use Each Launcher

Choose the launcher that matches your scenario. Use the interactive decision guide below to identify the right tool for a given situation.

🤔 Decision Guide — Click a Scenario to Explore

🏢 The user is an internal IT admin managing servers on the corporate network▼

→

Use RDP Launcher. The admin has VPN or LAN access, uses a Windows workstation, and needs a full native RDP experience. Secret Server injects credentials so the admin never types a password.

🌐 A third-party vendor needs to access a server without VPN access▼

→

Use PRA Launcher. Vendors should never be granted VPN access. PRA allows scoped, time-limited, brokered access through a browser with full session recording. Credentials are never exposed to the vendor.

🖱️ An end user needs remote desktop support from IT Helpdesk▼

→

Use PRA Launcher. PRA supports attended help desk scenarios where a user initiates or accepts a support session from their own desktop. The PRA Jump Client or support session feature is purpose-built for this use case.

→

RDP Launcher can work if the helpdesk admin knows the target machine name, has credentials in Secret Server for that machine, and has network access. But it is not designed for attended support — the user experience is inferior.

📋 Compliance requires keystroke logging and full session metadata▼

→

Strongly prefer PRA Launcher. PRA records sessions natively with searchable metadata, keystroke capture, and file transfer logging. RDP Launcher video recording is available but lower-fidelity and lacks structured metadata.

🔒 Target machine is in a heavily firewalled DMZ or remote site▼

→

Use PRA Launcher. PRA requires only outbound HTTPS (443) from the PRA broker/Jumpoint to the cloud relay. No inbound firewall rules needed for the target. RDP Launcher would require port 3389 to be open and routable.

⚡ Admin wants the fastest, lowest-latency RDP experience▼

→

Use RDP Launcher. Because the connection is direct (workstation-to-target), there is no broker hop adding latency. Native mstsc.exe also leverages all RDP performance optimizations including RemoteFX and compression.

📱 User is on a non-Windows device (Mac, Linux, iPad, Chromebook)▼

→

Use PRA Launcher. PRA is fully browser-based and cross-platform. The RDP Launcher depends on mstsc.exe (Windows-only) or requires a compatible client — deploying it on non-Windows devices adds complexity and is not officially supported.

✅

Best Uses for RDP Launcher

Internal IT admins performing routine server management
Accessing Windows servers within the same LAN or over VPN
Full native RDP performance with RemoteFX support
Scenarios where the admin already has an established VPN connection
Quick ad-hoc admin access without setting up a brokered session
High-bandwidth tasks: graphics-heavy remote work

✅

Best Uses for PRA Launcher

Third-party vendors, contractors, MSPs needing scoped access
Helpdesk/support sessions on end-user desktops (attended)
Access to targets in DMZs, restricted networks, or cloud environments
Compliance-heavy environments requiring keystroke logging
Non-Windows admin devices (Mac, Linux, browser-only)
Zero-trust access where VPN is not permitted

Session Recording Quality

Session recording is available in both launchers, but they differ significantly in fidelity, searchability, and the overhead required to enable it.

🎬

RDP Launcher Recording

VIDEO-BASED · SCREEN CAPTURE

Secret Server's RDP Launcher records sessions by capturing the screen using the Protocol Handler helper application installed on the admin's workstation. Recording is stored as a video file.

Format	Video file (MP4/WebM)
Keystrokes Captured	Limited / No
Metadata / Search	Not searchable
Recording Dependency	Requires Protocol Handler on admin machine
Tamper Resistance	Standard
Playback	Secret Server UI (video player)

⚠️ Limitation: If the Protocol Handler is not installed or the admin bypasses the launcher, no recording occurs. Recording completeness depends on the endpoint.

🎬

PRA Launcher Recording

NATIVE BROKER-LEVEL · FULL FIDELITY

PRA records sessions at the broker level, meaning every session is always recorded regardless of what the user does on their end. Recording happens inside the proxy — it cannot be bypassed by the user.

Format	Proprietary HD format with metadata
Keystrokes Captured	Yes — full keystroke log
Metadata / Search	Searchable by text/keystroke
Recording Dependency	None — happens at broker
Tamper Resistance	High — user cannot disable
Playback	PRA portal with timeline, search, export

✅ Advantage: PRA recording is always on. Reviewers can search recorded sessions for specific commands typed during the session — invaluable for compliance audits and incident investigations.

📌

Compliance Recommendation: For PCI-DSS, SOX, HIPAA, and similar frameworks requiring privileged session monitoring, PRA's broker-level recording with keystroke capture and tamper-resistant storage is significantly stronger evidence than RDP Launcher's video-only recording. If an audit requires proof that every session was recorded and that recordings cannot be tampered with by the administrator, PRA is the appropriate choice.

Credential Injection Method

Both launchers ensure the user never sees or types the privileged password — but they achieve this in very different ways, with different implications for security and auditability.

🔑

RDP Launcher — Client-Side Injection

INJECTED ON THE ADMIN MACHINE

1Admin clicks Launch in Secret Server. The web app passes a launch token to the Protocol Handler.
2Protocol Handler retrieves the credential from Secret Server over an encrypted API call.
3Credential is passed to mstsc.exe via the Windows /v and credential APIs — it populates the RDP login automatically.
4The password exists briefly in memory on the admin's workstation during the launch handoff.

⚠️ Note: The credential temporarily passes through the admin's machine memory. In most environments this is acceptable, but for ultra-high security scenarios (e.g., privileged access workstations under surveillance), this should be evaluated.

🔑

PRA Launcher — Server-Side Injection

INJECTED AT THE BROKER — NEVER REACHES USER

1User opens a PRA session in their browser. Only an HTTPS session token is issued to the user's browser.
2The PRA broker calls Secret Server's API to retrieve the credential server-side.
3The broker injects the credential into the RDP/SSH session it establishes with the target — entirely in the broker's secure environment.
4The user's browser only ever sees a rendered screen. The password never crosses the network to the user's device.

✅ Zero Credential Exposure: The user (including vendors and contractors) never has access to the credential at any point, in any form. This is the strongest model for third-party and untrusted-endpoint access.

Credential Injection Security Summary

Consideration	RDP Launcher	PRA Launcher
Password visible to user?	No	No
Password transits user's device?	Briefly (in memory)	Never
Password visible on target login screen?	No (auto-filled)	No (broker fills)
Works with MFA on target?	Depends on config	Yes — PRA handles MFA flows
Suitable for untrusted endpoints?	Not recommended	Yes — designed for this
Requires Protocol Handler install?	Yes	No

Network & Firewall Requirements

Network requirements are one of the starkest differences between the two launchers. The RDP Launcher is firewall-heavy; PRA is designed to traverse restrictive environments.

🌐

RDP Launcher Network Requirements

Requires a direct, routable network path from the admin workstation to the target on TCP 3389. This means either being on the same LAN or connecting via VPN.

443HTTPSSecret Server web UI + API

3389TCPRDP to target machine (must be open)

VPNVariousRequired if target is not on local LAN

⚠️ Firewall Challenge: Port 3389 must be open from the admin's IP range to the target. In hardened environments, this may require specific firewall rules per target or use of a jump server.

🌐

PRA Launcher Network Requirements

Users only need outbound HTTPS on port 443 to the PRA cloud relay or on-prem broker. The PRA broker (or Jumpoint) inside the network makes the RDP connection to the target — not the user's device.

443HTTPSUser browser to PRA portal

443HTTPS/WSSJumpoint outbound to PRA relay

3389TCPPRA Jumpoint to target (internal only)

✅ Firewall Advantage: No inbound firewall rules needed for external users. The Jumpoint component makes all connections outbound from the internal network. This works through NAT, proxies, and strict egress-only firewalls.

🗺️

Key Network Architecture Rule With the RDP Launcher: the firewall must allow the admin workstation to reach port 3389 on the target.
With PRA: the firewall must allow the Jumpoint/broker to reach port 3389 on the target, and the Jumpoint only needs outbound 443 to the internet. The user's device needs nothing except a browser.

Scenario: Access from Outside the Corporate Network

Scenario	RDP Launcher	PRA Launcher
Admin on corporate VPN	Works	Works
Admin on public Wi-Fi, no VPN	Fails (no path to :3389)	Works
Vendor on home network	Not supported safely	Works
Target in DMZ (no inbound 3389)	Requires firewall change	Works via Jumpoint
Target in cloud (AWS/Azure VPC)	Requires VPN or peering	Works with cloud Jumpoint
Target behind CGNAT / strict NAT	Very difficult	Works (outbound only)

User Experience Differences

The experience of using each launcher is very different — for IT administrators configuring and launching sessions, and for end users or vendors on the other side of the connection.

For the IT Administrator / Session Initiator

🖥️ RDP Launcher — IT Admin Experience ▼

Admin

Navigates to the target server's secret in Secret Server, clicks the Launch button next to the RDP launcher.

System

Browser triggers the Protocol Handler (a small app installed during onboarding). A native Windows Remote Desktop window opens automatically.

Admin

The RDP session opens directly in the familiar Windows Remote Desktop client. The admin sees the remote desktop immediately — no browser tab, no web interface overhead.

Admin

Works in the native mstsc.exe window: full clipboard, audio redirection, drive mapping, RemoteFX graphics — all standard RDP features are available.

System

Session is logged in Secret Server. If recording is configured, the Protocol Handler captures screen video in the background.

Admin UX Summary: Very familiar, fast, full-featured RDP experience. Feels like any other remote desktop connection — just without typing a password.

🔐 PRA Launcher — IT Admin / Vendor Experience ▼

Admin

Logs into the Secret Server or PRA portal from any browser. Navigates to the target or clicks an access link sent via email/ticket.

System

PRA authenticates the user, checks their authorization policy, and establishes the brokered session with the target. The user waits a brief moment for the connection.

Admin

The remote desktop renders inside the browser window. The user interacts with the remote desktop through the web-based viewer — mouse and keyboard input are forwarded in real time.

Admin

Some native RDP features (clipboard sharing, drive mapping) may have restrictions configured by policy. File transfer uses a dedicated PRA file transfer panel.

System

Session is fully recorded at the broker. All keystrokes are logged. Session duration and all activity is tracked in the PRA audit trail.

Admin/Vendor UX Summary: Works from any device with a browser. Slightly more overhead than native RDP. Clipboard and drive mapping are policy-controlled and may require an extra step.

For the End User Being Supported

👤

End User — RDP Launcher Scenario

In a typical admin-to-server scenario, there is no end user — the admin is logging into a headless server. However, if IT is connecting to a user's workstation to provide support:

→User's workstation must have RDP enabled, and the IT admin must have credentials for that machine.
→The user may see a notification that someone has connected (if they're at the machine).
→There is no built-in screen-share consent flow — the admin simply connects using credentials.
→Not ideal for attended support — the user experience is unintuitive and lacks a "request support" feature.

👤

End User — PRA Launcher Scenario

PRA is purpose-built for attended remote support. It provides a consent-based, user-friendly experience when IT needs to help an end user:

→User visits a support URL or the IT admin sends them a session link via chat/email.
→User is prompted with a clear consent screen: "IT is requesting to view or control your screen."
→User can see and revoke the session at any time from the PRA Jump Client tray icon.
→Session ends cleanly and the user is notified when IT disconnects.

Best practice for helpdesk: PRA's attended support model provides transparency, consent, and a professional experience for the user being helped.

UX Summary Table

Aspect	RDP Launcher	PRA Launcher
Setup for first-time users	Install Protocol Handler once	Nothing to install
Session start speed	Very fast (native app)	Slightly slower (broker setup)
Cross-platform support	Windows-primary	Any OS, any browser
Clipboard transfer	Full native clipboard	Policy-controlled
File transfer	Drive mapping (native RDP)	PRA file transfer panel
End-user consent screen	Not available	Yes — consent flow built in
Vendor/contractor use	Not suitable	Purpose-built for this
Works on mobile/tablet	No	Yes (browser-based)

Quick Reference Card

Use this as a at-a-glance summary for training, onboarding, or when you need to quickly decide which launcher to use.

🖥️ Use RDP Launcher when…

You are internal IT staff with VPN or LAN access
The target is a Windows server you regularly manage
You want the fastest, most native RDP experience
You need full RemoteFX, drive mapping, or audio redirect
You are using a Windows workstation with Protocol Handler installed
The scenario does not involve third parties or vendors

🔐 Use PRA Launcher when…

A vendor, contractor, or MSP needs access
The user has no VPN and must not get one
The target is in a DMZ, cloud, or restricted network
You need end user consent for attended desktop support
Compliance requires keystroke-level audit trails
Users are on Mac, Linux, or non-Windows devices
You need to record sessions that users cannot disable

Full Feature Comparison

Category	RDP Launcher	PRA Launcher
Connection model	Direct (client → target)	Proxied (client → broker → target)
VPN required	Typically yes	No
Agent on target	None required	Optional Jump Client/Jumpoint
Client software	Protocol Handler + mstsc.exe	Browser only
Credential injection	Client-side (admin machine)	Server-side (broker only)
Credential exposure to user	None visible	None — never reaches user
Session recording	Video capture (screen)	HD + keystrokes + metadata
Recording bypass risk	If handler not installed	Cannot be bypassed
Attended support (end users)	Not designed for it	Built-in consent + visibility
Firewall rules required	Port 3389 to target	Outbound 443 from broker only
Cross-platform	Windows-primary	All platforms
Vendor / 3rd party access	Not recommended	Purpose-built
Latency	Low (no broker hop)	Slightly higher (broker)
Native RDP features	Full (RemoteFX, audio, drives)	Policy-controlled subset
License requirement	Included in Secret Server	Separate PRA license

🎓

Training Summary The RDP Launcher is your tool for trusted, internal admins managing known infrastructure with an established network path. The PRA Launcher is your tool for any scenario involving external parties, restricted networks, attended support, or strict compliance. When in doubt, PRA provides a stronger security posture at the cost of some native feature richness.

RDP Launcher vs PRA Launcher

Bert Blevins