Part 1 · Foundations
Architecture Overview
Before you touch a single setting, you need a mental model of what PRA actually is and how its pieces talk to each other. Everything else in this course — appliance config, jump technology, policies — is just filling in the boxes of the diagram below.
What PRA actually does
Privileged Remote Access (PRA) is BeyondTrust's product for controlling, monitoring, and recording remote access to critical systems for privileged users — internal admins, IT staff, and third-party vendors. It sits in the Privileged Access Management (PAM) family: the job is not just "let people connect remotely," it's "let the right people connect to the right systems, with the right level of privilege, while everything is logged and, if needed, watched live."
Three ideas repeat throughout every lab and every exam item in this course:
- Least privilege. Users get access to specific assets, not the whole network — enforced through Jump Items, Group Policies, and Session Policies.
- Approval and accountability. Sensitive access can require a manager's sign-off (asset policies), and every session can be recorded and reported on.
- No inbound holes in your firewall. Every connection PRA makes is outbound from the endpoint to the appliance — this single design choice shapes almost every other architectural decision.
The B Series Appliance: the hub everything routes through
The B Series Appliance (physical, virtual, or cloud-hosted) is the centralized routing point for all communication between PRA components. Reps don't connect directly to endpoints, and endpoints don't connect directly to reps — both sides make an outbound TLS connection to the appliance, and the appliance relays the session. This is why PRA works through firewalls without opening inbound ports: nothing outside your network ever has to initiate a connection into it.
Both the rep and the endpoint dial out to the appliance — neither side accepts inbound connections. That's why a laptop on a hotel Wi-Fi network can reach a server behind three layers of corporate firewall: the server already has an open outbound tunnel to the appliance, and the appliance just relays the rep's session down that same tunnel.
Where the appliance lives on your network
BeyondTrust supports three placements, and the exam expects you to know the trade-off, not just the name.
| Placement | Pros | Cons |
|---|---|---|
| DMZ (recommended) | Security best practice; access control, segmentation, and logging at the perimeter | Requires changes to the perimeter firewall/access control device |
| External (outside the firewall) | No firewall changes needed | Harder to apply access control to the appliance itself |
| Internal | Ideal when every user is already inside the firewall or on VPN | Can't support endpoints external to the corporate firewall |
TCP 443 carries all session traffic and is the only port BeyondTrust Cloud requires. TCP 80 is optional (portal page, redirects to 443). UDP 3478 is only needed if the appliance is used as a peer-to-peer server. Everything else — LDAP (389/636), syslog (514/6514), NTP (123), SNMP (161) — is for management and integrations, not core remote-access traffic.
The moving parts you'll configure in this course
- /login web interface — the browser-based admin portal for the appliance and site configuration (Module 2).
- Access Console — the desktop application reps use to run sessions, browse Jump Items, and access the Vault (Module 10).
- Jump Technology — Jump Clients (installed agents) and Jumpoints (agentless, gateway-style access to a subnet) that let a rep reach an endpoint without the endpoint initiating anything (Module 15).
- Vault — stores and injects credentials into sessions so reps never see the actual password (Module 16).
- Session Policies / Group Policies — the permission and behavior rules applied to users and Jump Items (Modules 17–18).
- Vendor Groups — a way to segment third-party access with its own portal and approval flow (Module 20).
New admins assume the Access Console is PRA. It's just the client. The appliance is the brain — sites, policies, users, and security settings all live there, and the Access Console simply authenticates against it and reflects whatever permissions the appliance hands back.
Cloud vs. on-premises
Everything above applies to both deployment models. The difference is who manages the appliance layer: in on-premises, you own the B Series Appliance (physical or virtual) and are responsible for its network placement, patching, and failover pair. In Cloud, BeyondTrust hosts and manages the appliance for you, and you interact almost entirely through /login and the Access Console. The lab environment used in this course (and the BCIE practical exam) is on-premises, which is why appliance placement, backup, and failover get their own modules — those are exactly the concerns Cloud customers don't have to manage themselves.