Part 2 · Appliance & Site Configuration
Security Providers
Almost no serious PRA deployment authenticates users against a purely local account store. This module covers how PRA delegates authentication to external identity systems — LDAP, RADIUS, Kerberos, and SAML — and the connectivity model that lets an appliance reach a directory server it can't talk to directly.
Why delegate authentication at all
Local PRA accounts work, but they mean maintaining a second, parallel identity store — new hires need a PRA account provisioned separately from their Active Directory account, terminated employees need to be remembered on two systems instead of one, and password policy has to be enforced twice. Security providers solve this by letting PRA authenticate users against an identity system your organization already runs, and — just as importantly — by letting you map groups in that external system directly to permission structures (teams, group policies) inside PRA, so access changes when someone's AD group membership changes rather than requiring a separate PRA admin action every time.
PRA supports several provider types side by side, added from /login or /appliance under Users > Security Providers (exact location varies slightly by whether the provider is site-level or appliance-level): LDAP (directory-based authentication, most commonly Active Directory), RADIUS (typically layered in for multi-factor authentication), Kerberos (single sign-on so a domain-joined rep never sees a login prompt at all), SAML2 (SSO federation against an external identity provider like Okta, OneLogin, or Microsoft Entra ID), plus OpenID Connect and SCIM for provisioning scenarios.
LDAP: the workhorse provider
LDAP is the most commonly configured provider because it's how most organizations already store identity, typically via Active Directory. Setting one up means supplying the LDAP server's Hostname and Port — typically 389 for plain LDAP or 636 for LDAPS, with PRA also supporting Active Directory's global catalog over 3268 (LDAP) or 3269 (LDAPS) when you need to query across an entire forest rather than a single domain — plus an Encryption choice and Bind credentials PRA uses to authenticate to the directory before it can search it.
The encryption choice matters more than it might look: plain LDAP sends bind credentials and directory data in clear text, exposed to anyone who can sniff the network path between the appliance and the directory server. BeyondTrust recommends LDAPS or LDAP with TLS instead — LDAPS wraps the entire connection in encryption from the start, while LDAP with TLS begins in clear text and then upgrades via StartTLS. Either encrypted option requires uploading the LDAP server's Root SSL Certificate in PEM format (no certificate chains), and the certificate's subject name or alternate subject name must match the hostname you entered — a wildcard certificate like *.example.com is acceptable and will validate against any matching subdomain.
Bind credentials use a specific notation: DOMAIN\Username, or USERNAME@DOMAIN if your Active Directory version doesn't support the backslash form. Anonymous binding — skipping a bind username/password entirely — is possible if the directory server explicitly permits it, but it's considered insecure and disabled by default on most LDAP servers for good reason.
RADIUS: usually layered in for MFA
RADIUS configuration looks structurally similar — hostname, port (typically 1812), and a connection method — but adds a Timeout setting and a Shared Secret instead of bind credentials. The timeout matters operationally: if the RADIUS server's response is Response-Accept or Response-Challenge, PRA waits the entire configured timeout before completing authentication, so an unnecessarily long timeout directly slows down every login attempt. BeyondTrust recommends keeping it as low as your network reasonably allows — typically 3–5 seconds — with an absolute ceiling of three minutes. The shared secret is the credential both sides use to trust each other's RADIUS messages, analogous to the LDAP bind password but symmetric rather than a login.
Kerberos and SAML2: single sign-on paths
Kerberos integration lets a domain-joined rep skip the login screen entirely — the access console authenticates transparently using the rep's existing Windows domain session via a Kerberos keytab configured on the appliance. SAML2 takes the opposite shape: it federates authentication out to an external identity provider entirely, so instead of the appliance validating credentials itself, the user is redirected to the IdP (Okta, OneLogin, Microsoft Entra ID, ADFS, etc.), authenticates there — potentially satisfying that IdP's own MFA policy — and is handed back to PRA with a signed assertion. Configuring SAML2 means exchanging metadata in both directions: you either upload the IdP's metadata XML (which auto-fills the Entity ID and SSO URL) or enter those fields manually, and you download PRA's own service-provider metadata to hand to the IdP so it knows how to reach back. An optional SAML payload encryption setting can generate a private key so assertions are encrypted rather than just signed, at the cost of a slightly more involved certificate exchange with the IdP.
The Connection Agent: reaching directories the appliance can't touch directly
A recurring theme across LDAP and RADIUS setup is the Connection Agent. If your directory or RADIUS server sits on the same LAN as the appliance and the two can talk directly, you leave Proxy from appliance through the Connection Agent unchecked and you're done. But if the directory server is behind its own firewall — a very common topology, since directory servers are rarely placed anywhere near a DMZ — direct communication isn't possible, and you instead download a small Win32 Connection Agent, install it on (or near) the directory server, and let it establish an SSL-encrypted outbound connection back to the appliance. This mirrors the exact "no inbound holes" principle from Module 1: rather than opening an inbound port on the internal firewall to let the appliance reach the directory server, the Connection Agent reverses the direction so the directory-side network never has to accept anything inbound at all.
The Connection Agent isn't just a convenience feature — it's what lets you keep your internal directory servers behind firewalls that permit zero inbound access from the DMZ, which is exactly the segmentation most security teams require between a perimeter-facing appliance and core identity infrastructure. Skipping it and instead punching an inbound LDAP/RADIUS hole through the internal firewall defeats the segmentation the DMZ placement (Module 1) was meant to provide in the first place.
An admin configures LDAPS against a directory server, uploads what they believe is the correct root certificate, and authentication fails with the provider showing as unreachable — not because the credentials are wrong, but because the LDAP server's certificate's subject name (or the DNS component of its alternate subject name) doesn't match the hostname entered in the provider configuration. PRA's LDAPS/TLS validation is strict about this match; a certificate that's otherwise perfectly valid but issued for a different hostname than the one you typed will cause the provider to be treated as unreachable, with an error that doesn't obviously point at "hostname mismatch" as the cause.
Firewall considerations
Because security-provider traffic can originate from any IP address configured on the appliance (not just the one hosting the primary DNS record), firewall rules for these providers should apply to every IP on the appliance rather than a single address. The documented example ports are LDAP/LDAPS at 389/636 (both TCP and UDP), and — relevant if the appliance is doing account discovery/rotation against Active Directory or local accounts for Vault — 389, 636, and 445 between internal network segments. If an LDAP server sits entirely outside the DMZ (the appliance's usual home per Module 1), the Connection Agent is the documented mechanism for bridging that gap rather than opening a direct inbound path.