Front-End Server Architecture
This article discusses front-end server architecture to make Privileged Access Manager available from the outside of the corporate network.
Front-end Architecture for Production Deployment
For the production deployment of PAM that could be accessed from the outside of the network we usually recommend to install a reversed proxy (load balancer) on the computer in DMZ to handle the inbound HTTPS traffic with SSL certificates.
This reversed proxy will forward all requests to the PAM server inside the network.
HTTPS configuration with SSL certificate is optional for the trial use to test application functionality.
However, if testing with SSL is desirable or for the production use the pre-requisite is to have a fully qualified domain name (FQDN) resolvable to the PAM reversed proxy computer in DMZ (for example pam.company.com) and an SSL certificate for this FQDN signed by an internet certificate authority trusted by browsers accessing the system.
In this example PAM will be accessed at https://pam.company.com/pam/
Front-end Architecture for Test or Trial Deployment
The alternative way to test the external setup is to install PAM itself at the computer in DMZ, optionally load there a trusted SSL certificate mentioned earlier and switch it to bind directly to HTTP(s) port. It is slightly easier to do and will demonstrate PAM functionality for the trial purposes.
The discussion below assumes two-server setup with one computer with reversed proxy at DMZ and the other one with PAM behind the firewall. PAM licensing does not count load balancer / reversed proxy computer as a node to purchase.
When forwarding WEB traffic from a reversed proxy to PAM server using HTTPS protocol make sure that PAM uses trusted certificate or disable certificate check on the load balancer or direct the traffic on the unsecured HTTP port (PAM listens an unprotected HTTP protocol on the port 8080 for test purposes).
Below is an FAQ article to replace generated self-signed certificate of PAM server with the one trusted by the load balancer.
Note that PAM server and load balancers could be installed on similar or on different operating systems (for example, Windows hosting PAM server and Unix hosting the reversed proxy / load balancer). Also, it is possible to utilize existing load balancer in case the one is already in place (for example F5).
If you plan for your users to only use WEB GUI and WEB Sessions then standard HTTPS at port 443 with SSL is enough.
Make sure to enable sticky sessions on the load balancer because RDP and SSH sessions are stateful.
Consider enabling Web sockets since they bring better performance for WEB Sessions (some load balancer might require them enabled separately).
If you plan for your users to use native clients (Putty, mstsc, etc) then you need to open (and load balance) PAM Proxy ports (default are 3388 for RDP proxy, 2022 for SSH Proxy, 8081 for HTTP Proxy).
Keep in mind that there is a constant background port scanning noise in the Internet targeting all ports and all protocols. These events appear in the Audit Log as failed logins with IP address and a user. Deployments might implement white list filtering expected visitors on the load balancer. Deployments might also implement black listing abusers reported in the audit log. Both white and black listing is expected to be on the load balancer side.