PAM360's secondary server model provides a foundational approach to tackle downtime and ensure continual access to privileged accounts. By deploying a PAM360 instance on a secondary server, organizations establish a solution that facilitates smooth transitions in the event of service interruptions on the primary server.
Additional Detail
The High Availability configuration using the secondary server model is exclusively compatible with the PostgreSQL database bundled with the PAM360 product.
Initially, a PAM360 instance is installed on a server and connected to a primary database, serving as the primary PAM360 server. Subsequently, another instance is established on a separate server, linked to a new secondary database, serving as the secondary server. In the event of the primary server's inactivity, operations are seamlessly transferred to the secondary server. Once the primary server resumes operation, database synchronization occurs using the merge replication methodology, restoring it as the primary server.
In PAM360, the secondary server model ensures redundancy of both servers and database instances. Key characteristics of the model include:
The architecture consists of redundant PAM360 servers - one primary server and one secondary server. The secondary server is kept in synchronization with the primary server through server replication.
The secondary server architecture in PAM360 supports two network scenarios:
| Scenario 1 | |
|---|---|
Primary and Secondary Servers on the Same Network | In this scenario, both the primary and secondary servers are hosted within the same network. If the primary server fails, the secondary server assumes read/write responsibility, except for password resets. |
Example | Both servers are deployed in the same location. If the primary server goes down, users can still retrieve passwords and perform relevant operations from the secondary server within the same network. Once the primary server becomes active, the data in both the servers' database will be synchronized. |
| Scenario 2 | |
Primary and Secondary Servers on Different Networks | In this scenario, the primary and secondary servers are hosted in different geographical locations, connected via a WAN link. If the WAN link fails, the secondary server can continue to serve users in its network by providing read/write access (except password resets). |
Example | If the primary server is located in location A and the secondary server in location B, and the WAN link between them fails, both servers will operate independently. Users in location B will access the secondary server until the link is restored, after which both servers' database will synchronize. |
In both scenarios, audit trails are recorded as usual. If users access the secondary server during a primary server failure, actions such as password retrieval, login, and logout will be logged on the secondary server. Once network connectivity is restored, the audit data between the primary and secondary servers is synchronized.
Caution
Make sure that the ports 3456 (database port) and 8282 (web server port) are open between the primary and the secondary application servers.
To establish High Availability for a server running PostgreSQL in PAM360, follow these four essential steps:
Windows:
HASetup.bat <Primary_Server_FQDN> <Secondary_Server_FQDN>
Linux:
sh HASetup.sh <Primary_Server_FQDN> <Secondary_Server_FQDN>
Additional Detail
PAM360 requires the pam360_key.key file to be accessible with its full path when it starts up every time. After a successful start-up, it does not need the key anymore so the device with the key file can be taken offline.
Caution
From PAM360 build 8000 onwards, it is mandatory to retain the pam360_key.key file in the file path specified in the manage_key.conf file for a seamless operation. PAM360 continuously accesses this file to ensure uninterrupted operation. If the pam360_key.key file is not available in the specified path, the service may not startup or certain features such as database backup will not function.
The secondary server configuration for HA is now complete. Start the PAM360 secondary server followed by primary server to activate the HA setup.
Caution
By default, PAM360 uses a self-signed SSL certificate. If you have replaced this with a certificate from an internal CA (other than well-known CAs like Verisign, Thawte, RapidSSL, etc) on the secondary server, follow these extra steps to add the certificate to the primary server’s certificate store:
importCert.bat <Absolute-Path-of-the-Certificate>
Your HA configuration for PAM360 with PostgreSQL is now fully set up and secured.
PAM360 supports monitoring the high availability of your servers to anticipate failures, thereby avoiding costly downtimes. Refer to this help document to learn more about monitoring HA in detail.