Deployment Architecture to Scale Session Manager

This article discusses different deployment architecture scenarios to scale Privileged Access Management (PAM) utilizing multiple session manager components.

Component Architecture

PAM contains several components. When PAM is deployed on a single host all components are installed on the same server and they communicate between each other inside this server.

One of these components is Session Manager.

PAM communicates with Session Manager using PAM proprietary protocol through the port 4822.

Session Manager, in turn, communicates with remote computers using RDP, SSH, Telnet or VNC protocols depending of the remote computer.

ArchDiagram01-3

Session Manager can be installed on a separate host than PAM WEB application.

Then PAM can be instructed to use this Session Manager instead (or together) with the one installed on the PAM computer.

This way, RDP (or SSH) session will be established from Session Manager server to a remote server and PAM will communicate with Session Manager server using port 4822 (the port should be opened in Session Manager Server firewall).

This architecture is not specifically related to RDP. Any protocol will work in the same way.

Session Manager Deployment

There are two applications of this deployment:

  1. Performance optimization.

    2. PAM can automatically load balance sessions between multiple Session Managers (there could be more than two) each time selecting one with least number of currently active sessions. This architecture also supports high availability requirement.

    PAM-Session-Managers-performance-768x384.png

  2. Network isolation.

    3. PAM could be configured to select a specific session managers group out of several configured groups (called Proximity Groups) to serve remote computers located on a specific PAM Vault, in specified IP range or in a specific domain. For example, computers from the network 10.0.0.x/24 could be served by SERVER SM1 or SERVER SM2 (balanced) while computers from the network 10.1.1.x/24 could be served by balanced session managers SERVER SM3 or SERVER SM4.

    PAM-Session-Managers-groups-768x384.png

    For the end user there will be no visible differences – the sessions will open as usual.

Configuring

Practically, to support this scenario install Session Manager as an individual application on the Session Manager host.

 

To do that,

  1. Run the regular installer on this host but only select one option: Session Manager.

  2. The installer at some point will ask about certificates.

  3. In a test environment ignore it leaving the communication channel between PAM and Session Manager over the port 4822 insecure.

 

Alternatively,

  1. Bring file certbundle.zip from $PAM_HOME folder of PAM WEB application host. These certificates are generated during the installation and they keep the communication channel encrypted.

  2. Open the PAM GUI, navigate to the menu Administration / Settings / Proximity Groups, edit Default Group and add a new server (host, port 4822).

  3. Make sure that port 4822 is accessible from PAM server.

  4. After saving the configuration PAM will check connection automatically displaying whether the communication channel is established (blue), failed (crossed-out) and whether it is secured (green).

 

Optionally,

  1. Remove localhost or keep it so PAM will load balance between localhost and an external one.

  2. Add more proximity groups for remote servers in specific IP ranges of with specific domain masks.

 

Each proximity group might contain multiple session managers so PAM will load balance between them inside a group.

Using Proximity Groups with multiple session managers is the way that PAM scales for large or busy environments.