Privileged Remote Access - Getting Started

What is Privileged Remote Access?

Privileged Remote Access (PRA) controls how people connect to your most important systems from somewhere else. It gives secure remote access to admins, IT staff, and outside vendors without a VPN.

PRA is part of the BeyondTrust Privileged Access Management (PAM) family and provides three main roles:

• Access control: Only approved users can reach a system. They get only the level of access they need, and only when they need it.
• Credential security: Vault stores your privileged passwords and keys. PRA can inject a credential into a session so the user never sees or types the password.
• Session oversight: PRA records and logs sessions. You get a searchable audit trail, and you can watch a live session and end it if something looks wrong.

PRA capabilities and benefits

You can use PRA to do the following:

• Secure Privileged Remote Access: Give administrators and IT teams secure remote access to servers, desktops, network devices, and databases without broad VPN access to the network.
• Third-Party & Vendor Access: Provide vendors and external users with controlled, time-bound access only to required systems. Set expiration dates to automatically remove access when no longer needed.
• Credential Security: Inject stored credentials directly into privileged sessions, allowing users to access systems without seeing or knowing the underlying passwords.
• Privileged Credential Management: Discover, store, manage, and rotate privileged credentials in the built-in Vault, supporting up to 200,000 accounts.
• Just-in-Time Access Controls: Require controls such as a ticket number, business justification, manager approval, or multi-factor authentication before granting privileged access.
• Time-Based Access: Restrict privileged access to approved days and hours, preventing users and vendors from connecting outside authorized windows.
• Session Control: Control privileged-session activities, including clipboard use, file transfers, screen sharing, and command execution.
• Broad System & Protocol Support: Secure access to Windows, macOS, Linux, Android, and iOS systems, plus SSH and Telnet devices such as switches, routers, and other infrastructure.
• Session Recording & Audit: Record privileged sessions and capture activity to audit who accessed a system, what they did, and when.
• SIEM Integration: Send privileged-session and audit events to SIEM platforms through syslog for centralized monitoring, investigation, and compliance reporting.

Prerequisites

Before you start, you need to make a few decisions. The right answers depend on your organization's size, network, and security rules. This is not a full checklist, but it is a good place to start.

• Pick your deployment model, Cloud or on-premises. Your choice usually depends on who you want to manage the infrastructure. See Deployment methods below.
• Choose your site name and set up DNS. Every PRA site has a URL, and that URL is where users and client software connect. Cloud sites get a yoursite.beyondtrustcloud.com address, and you can point your own name at it with a CNAME record. On-premises appliances need a static IP address and a DNS A record.
• Get an SSL/TLS certificate. PRA needs a valid certificate before BeyondTrust can build your client software. Use a public certificate authority (CA) or your own internal CA. Cloud sites cannot use self-signed certificates. You create the certificate request on the appliance itself, at /appliance > Security > Certificates.
• Confirm your firewall settings. TCP 443 is required in every deployment. On-premises deployments may need more ports, including STUN and TURN ports for peer-to-peer traffic. Before you file a firewall request, see Network considerations.
• Decide how users sign in. PRA can use local accounts, or it can connect to a security provider such as Active Directory, LDAP, SAML, Microsoft Entra ID, OpenID Connect, or Kerberos. This choice affects how you create users and group policies.
• Plan your two-factor authentication. PRA supports TOTP apps and FIDO2 keys, which you turn on in group policies.
• Plan for retention. Session recordings and text logs are kept for up to 90 days. If the disk fills up, the oldest data is deleted first, even if 90 days have not passed. Use the Integration Client to export data if you need to keep it longer.

Deployment methods

You can deploy PRA in the cloud, or on-premises on a BeyondTrust B Series Appliance.

PRA Cloud

With PRA Cloud, BeyondTrust hosts runs for you, so you do not manage servers, storage, or the operating system. Your site runs on a single-tenant instance in the BeyondTrust cloud, with a 99.9% monthly uptime commitment.

BeyondTrust applies critical security updates for you, and you can pull other software updates whenever you want from the Updates page. Cloud sites use port 443 only, which keeps your firewall changes small.

Cloud customers sign in through Pathfinder, the shared BeyondTrust console at app.beyondtrust.io. Pathfinder is not a separate hosting model. It is a single front door for your BeyondTrust products, and it handles users and identity providers for all of them.

On-premises (B Series Appliance)

The B Series Appliance is a self-contained system that includes the operating system, the database, and the PRA software, already installed and configured. You run it in your own data center. You can buy it as physical hardware, or run the SRA Virtual Appliance on VMware, Hyper-V, Nutanix AHV, Red Hat OpenShift, Azure, or AWS.

An on-premises appliance has a second web interface at /appliance, where you manage the hardware, networking, storage, encryption, and base software. You control your own updates, backups, network placement, and clustering.

BeyondTrust recommends placing the appliance in a DMZ if you need to reach systems outside your network.

Compare the two methods

The following table describes what each deployment method provides.

PRA essentials

When you set up PRA, you build a small set of objects that control who can reach what. Add these during initial setup so access control and auditing work from day one.

Asset types

Not every Asset is reached the same way. Some need software on the target system, and some need a Gateway on the target network. Knowing the difference helps you plan your rollout.

The /login interface versus the access console

PRA has two interfaces, and they serve different people. Knowing which one to open saves a lot of time.

On-premises deployments have a third interface, /appliance, which you use to configure networking, storage, certificates, and base software. Cloud deployments have a smaller version of this interface.

Initial setup

1. Sign in

Use a supported browser to sign in to your PRA site.

• Cloud on Pathfinder: Go to app.beyondtrust.io and sign in, then open Privileged Remote Access.
• Standalone Cloud: Go to your site URL followed by /login. Your URL is in the BeyondTrust welcome email.
• On-premises: Go to your appliance URL followed by /login. The first sign-in uses the default administrator account, and you must change the password right away.

2. Install your SSL certificate and license

You do this before anything else because you cannot download client software without it.

1. Go to /appliance > Security > Certificates.
2. Create a certificate request, and send it to your certificate authority.
3. Import the signed certificate, along with the intermediate and root certificates. Many CAs do not send the root certificate, so ask for it.
4. Send your site name, the root certificate, and your appliance details to BeyondTrust Support so they can build your license package. Never send a private key.
5. When Support notifies you, install the license and base software packages from /appliance > Updates.

Cloud sites already have a certificate for yoursite.beyondtrustcloud.com, so you only do this if you want to use your own hostname. Let's Encrypt is also supported in both models.

3. Connect your identity source and create users

Next, decide how people sign in.

1. Go to Users & Security > Security Providers, and add your provider. Use Test settings to check it before you save.
2. Assign a default group policy to the provider. Every user who signs in from an outside identity source must belong to at least one group policy.
3. Go to Users & Security > Users to add any local accounts you still need.

In Pathfinder, you manage users and SAML identity providers at the platform level instead, under Administration. The Security Providers page inside PRA is read-only.

4. Create group policies

Group policies are how you grant permissions in PRA. Create them before you create Assets, so you have somewhere to assign access.

1. Go to Users & Security > Group Policies, and click to add a policy.
2. Set Account Settings, including whether TOTP or FIDO2 is required.
3. Set General Permissions, such as whether members are administrators or can manage Vault.
4. Set Access Permissions, including which connection types members can use.
5. Add members. You can add local users, or whole groups from your security provider.

5. Build Asset Roles, Asset Policies, and Asset Groups

Create these three objects in this order, because each one is used by the next.

1. Asset Roles. Go to Asset Management > Asset Roles. Create roles that match the jobs people do. A read-only Auditor role ships with the product.
2. Asset Policies. Go to Asset Management > Asset Policies. Create policies for your access rules, such as requiring approval or limiting access to business hours.
3. Asset Groups. Go to Asset Management > Asset Groups. Create a group, give it a code name, and list the users and group policies allowed to use it. Assign each one an Asset Role.

6. Deploy Jump Clients, install a Gateway, or both

Now connect PRA to your systems.

To deploy Jump Clients:

1. Go to Asset Management > Jump Clients, and start the Mass Deployment Wizard.
2. Choose the Asset Group. This is the only required field.
3. Set how long the installer stays valid, and choose the Asset Policy and session policy you want applied.
4. Distribute the installer. You can send a link, run a script, or push the Windows MSI with a tool such as Intune, SCCM, or Group Policy.

To install a Gateway:

1. Go to Asset Management > Gateway, and add a Gateway.
2. Name it, set the platform, and turn on the connection types you need, such as SSH or Protocol Tunnel.
3. Download and run the installer on a computer inside the target network. The installer link expires in 7 days.

7. Set up Vault and credential injection

With systems connected, store the credentials people need.

1. Go to Vault > Accounts, and add your shared accounts. You can enter them by hand, or run a discovery job under Vault > Discovery to find them.
2. Group related accounts under Vault > Account Groups, and apply an account policy to control rotation and checkout.
3. Set Asset Association on each account so the credential is only offered on the Assets it applies to. For more information about Asset Association, see Asset Association options.
4. Give users the Inject role, or Inject and Checkout if they also need to check the credential out. Assign these through group policies.

Asset Association options

Asset Association controls which Assets a Vault account can be injected into. Without it, every credential in Vault would appear as a choice on every system, and your users would have to pick the right one from a long list.

You set it when you add or edit an account. Go to Vault > Accounts, then click Add. To change an account you already have, find it in the grid, click the ellipsis, and select Edit. Asset Association is a section on that page. The same section appears on the account group page, which is what makes the inherited option work.

Choose one of the following types.

If you choose Assets Matching Criteria, you can pick Assets from the list and click Add Asset. You can also filter on four Asset attributes: Name, Hostname / IP, Tag, and Comments. Assets you pick and Assets that match a filter are combined, not replaced. Each attribute holds up to 32 values, and each value can be up to 64 characters.

Filters accept these patterns.

Credential injection works with the Jump Client, Remote RDP, Remote Jump, SSH, Database Connection, and Website connection types. It does not work with personal Assets, or with TCP tunnel and IP tunnel database connections.

8. Configure session policies

Session policies control what users can do once they are connected.

1. Go to Users & Security > Session Policies, and add a policy.
2. Set Availability to say where the policy can be applied: to users, to Assets, or to access invites.
3. Set your permissions. Leave a permission as Not Defined if you want a lower policy to decide it.
4. Use the Session Policy Simulator to confirm the result before you roll it out.

9. Install the access console

Finally, get your users the app they will actually use.

1. Go to Consoles & Downloads.
2. Choose the platform and download the access console.
3. For a large rollout, install the MSI silently with msiexec.

The desktop console has every feature but only runs on the computer it was downloaded to. The privileged web access console runs in any browser, but it does not include features that need deep access to the operating system.

10. Back up your configuration

Go to /login > Management > Software, set a backup password, and download your configuration backup. Download your Vault encryption keys as a separate file. Repeat this every time you change your settings. You need both files to restore PRA to a new appliance.

Next steps

• Onboard your third parties with Vendors and Access invite.
• Walk through a real task with Add a Jump Client to an endpoint.
• Confirm your systems are covered in Supported platforms.
• Send session data to your SIEM with Syslog.
• Look up any term you are unsure about in the Privileged Remote Access Glossary.