Part 2 · Appliance & Site Configuration
Site-Wide Configuration Settings
Where Module 4 locked down security behavior, this module covers the general-purpose plumbing of the site itself — the addresses it answers to, what happens when someone browses to the bare portal, which languages it speaks, and the legal gate a login agreement puts in front of every user.
Site Configuration vs. Security: keeping the two straight
Both pages live under /login > Management, sit next to each other in the same navigation, and both get touched once during initial setup and rarely afterward — which is exactly why they're easy to confuse. Security (Module 4) answers "how does the system behave to protect a session and its data." Site Configuration answers a different question entirely: "how does the system present itself and where does it live." DNS addresses, HTTP/HTTPS ports, the portal's redirect behavior, the pre-login legal agreement, and language support all fall under this second heading. None of it changes what a rep can do once logged in; all of it changes how someone finds, reaches, or first encounters the site.
Site addresses and the HTTP layer
The Site Configuration tab's HTTP section is where you register the DNS name(s) that resolve to your appliance. You enter one or more Site Addresses — the DNS records administrators set up (an A record or CNAME pointing at the appliance's IP, following a scheme like support.example.com) — and PRA uses these to know which hostnames it should consider itself authoritative for.
Alongside that sits Portal Redirect, which decides what a browser sees when someone navigates to the bare site address with no path — i.e., the portal index. Three choices are available:
| Portal Redirect option | Behavior |
|---|---|
| Redirect to /login (default) | Sends anyone hitting the bare domain straight to the admin login screen |
| Redirect to the Privileged Web Access Console | Sends visitors to the web-based access console instead |
| No Redirect | Leaves the portal index page as-is with no automatic redirect |
Below that, HTTP port and HTTPS port let experienced network engineers move traffic off the standard 80/443 ports — a setting that should only be touched in non-standard network environments, since every client build, firewall rule, and piece of documentation assumes the defaults. This capability, along with the DNS address fields, is on-premises only; BeyondTrust Cloud customers don't manage this layer themselves.
The prerequisite login agreement
PRA supports gating access to the login screen behind a legal or policy agreement the user must actively accept before they ever see a username/password field. This is enabled and authored from the same Site Configuration page: an admin checks a box to enable the agreement for the administrative interface, the access console, or both, then fills in an agreement title and body text, saving each independently.
This is a common compliance requirement — organizations that need to show every privileged user affirmatively agreed to an acceptable-use or monitoring-consent statement before authenticating can enforce it here rather than relying on a separate out-of-band process. Because the agreement blocks the login screen itself, it applies uniformly regardless of which authentication provider (local, LDAP, SAML, etc. — see Module 8) the user ultimately authenticates through.
A login agreement is evidentiary, not just decorative. If your organization is later asked to prove that every user acknowledged a monitoring or acceptable-use policy before gaining access, "we have a Word doc we email new hires" is a weaker answer than "the system will not display a login form until the user clicks Accept on this exact text." Configuring this once at the site level removes the burden of re-proving consent for every individual account.
Peer-to-peer server mode
A separate on-premises-only toggle lets you use the B Series Appliance itself as a peer-to-peer server. Enabling it requires the appliance to accept inbound UDP 3478 connections from BeyondTrust clients, which in turn requires opening that port on the perimeter firewall — a deliberate exception to the "everything is outbound" architecture principle from Module 1, and one that should be adopted only when your organization has a specific reason to route peer-to-peer traffic this way rather than through the appliance's normal relay path.
Localization
The Localization page (left-hand menu, separate from Site Configuration but part of the same general "how the site presents itself" category) controls which languages the admin interface and access console can display. PRA supports English, Spanish, Dutch, French, German, Italian, Japanese, Russian, Polish, Simplified Chinese, and Traditional Chinese, with support for international character sets, though some features are limited to single-byte characters and the BeyondTrust Gateway Configuration interface isn't translated.
Configuring localization is a two-step process: first, one or more language packs must be installed (BeyondTrust Support builds these into a software update on request — worth checking the Localization tab first to see if a language is already present before opening a support case), then an admin checks the box for each language to enable it, making it selectable from a dropdown in both the admin interface and access console, and separately picks which enabled language is the default. The currently active default language cannot be disabled. Once enabled, reps choose their preferred language at the login screen, and admins can switch languages from a dropdown in both /login and /appliance.
An admin changes the HTTP/HTTPS port away from the 80/443 defaults to satisfy an internal network policy, without accounting for the fact that client software builds, firewall rules referencing "the standard PRA ports," and existing documentation all assume 443. Reps outside the network suddenly can't connect, and the fix requires either reverting the port or coordinating a much larger set of firewall and client-build changes. Non-standard ports are supported, but they are not a decision to make unilaterally on this one page — they ripple through the whole deployment.