How Primary and Backup PAM works

Hi Everyone,

Let Say, I have configured PAM Backup Server by using below:

Primary PAM Manager:

IP : 10.0.0.1
Hostname : ppam

Backup PAM Manager:

IP : 10.0.0.2
Hostname : bpam


I have installed PAM manager on a server 10.0.0.2(bpam).
registered that PAM Manager(bpam) to primary PAM Manager(ppam) with command unifid regclnt register

1) Once we have configured backup PAM server then, all the data of primary PAM like configs including videos of all sessions etc will continuously be replicated to Backup PAM(bpam)?
I mean we need same storage requirement in Backup PAM as in Primary PAM?

Now let me know what will PAM do If disaster happens I mean if my primary PAM manager goes down(because of RAM was problematic):

2) once my primary PAM is down then backup PAM manger will take charge automatically ? we don't need to do any thing?
3) after the disaster, users will continue access /myaccess(/pam) page using the same IP/hostname of Primary PAM manager or they would use IP/hostname of backup PAM Manager?
4) After resolving physical hardware issue(i.e. old RAM replaced with new one) of Primary PAM Manager(pman) then booted, will it automatically take charge of primary Manager, I mean will it accept requests or backup pam manager(bpam) will accept requests?

Regards,
  • Audit data is delivered from Agents to all Audit Managers in their configured Audit Zone simultaneously. So audit data isn't sent to one Audit Manager and then replicated to others in the Audit Zone. This is because there could be audit loss if that central audit manager server went down. So this is why Agents deliver their audits to all Audit Managers in their Audit Zone. So if on Audit Manager goes down, the audits may still be available on the other Audit Manager in that zone.

    Same for authorization requests, etc. The Agents determine the optimal communication route as they need to.

    Now, when making changes to PAM in the Administration Console, etc. Changes can only be made to the Primary Manager since these changes are replicated to backup managers. So if Primary goes down, it'll be important to Promote some Backup Manager to be the new Primary, which will communicate with all the backups and will push the data it has to all the backups. For more details on this scenario, please refer to the following:
    https://www.netiq.com/documentation/privileged-account-manager-35/npam_admin/data/blmtqgd.html#hosts_promote_mgr
    Promoting Managers When the Primary Manager Fails.

    Details regarding Load Balancing and Failover can be found below:
    https://www.netiq.com/documentation/privileged-account-manager-35/npam_admin/data/bjh0sq0.html
  • Audit data is delivered from Agents to all Audit Managers in their configured Audit Zone simultaneously. So audit data isn't sent to one Audit Manager and then replicated to others in the Audit Zone. This is because there could be audit loss if that central audit manager server went down. So this is why Agents deliver their audits to all Audit Managers in their Audit Zone. So if on Audit Manager goes down, the audits may still be available on the other Audit Manager in that zone.

    Same for authorization requests, etc. The Agents determine the optimal communication route as they need to.

    Now, when making changes to PAM in the Administration Console, etc. Changes can only be made to the Primary Manager since these changes are replicated to backup managers. So if Primary goes down, it'll be important to Promote some Backup Manager to be the new Primary, which will communicate with all the backups and will push the data it has to all the backups. For more details on this scenario, please refer to the following:
    https://www.netiq.com/documentation/privileged-account-manager-35/npam_admin/data/blmtqgd.html#hosts_promote_mgr
    Promoting Managers When the Primary Manager Fails.

    Details regarding Load Balancing and Failover can be found below:
    https://www.netiq.com/documentation/privileged-account-manager-35/npam_admin/data/bjh0sq0.html
  • Audit data is delivered from Agents to all Audit Managers in their configured Audit Zone simultaneously. So audit data isn't sent to one Audit Manager and then replicated to others in the Audit Zone. This is because there could be audit loss if that central audit manager server went down. So this is why Agents deliver their audits to all Audit Managers in their Audit Zone. So if on Audit Manager goes down, the audits may still be available on the other Audit Manager in that zone.

    Same for authorization requests, etc. The Agents determine the optimal communication route as they need to.

    Now, when making changes to PAM in the Administration Console, etc. Changes can only be made to the Primary Manager since these changes are replicated to backup managers. So if Primary goes down, it'll be important to Promote some Backup Manager to be the new Primary, which will communicate with all the backups and will push the data it has to all the backups. For more details on this scenario, please refer to the following:
    https://www.netiq.com/documentation/privileged-account-manager-35/npam_admin/data/blmtqgd.html#hosts_promote_mgr
    Promoting Managers When the Primary Manager Fails.

    Details regarding Load Balancing and Failover can be found below:
    https://www.netiq.com/documentation/privileged-account-manager-35/npam_admin/data/bjh0sq0.html
  • After promoting Backup PAM as primary. It means that users must access IP or domain of Backup PAM to login myaccess  page ? and Most configuration aren't  still changed ?

  • The User Console / MyAccess can be accessed by users on any primary or backup managers as long as the requisite packages/modules are installed - it won't matter if it is primary or backup. You can also use the Administration Consoles as needed and as available on any manager servers, either primary or backup, it shouldn't make a difference.

    When promoting a backup manager to become the new primary manager within the framework, the data it has will be pushed to all other managers within the framework and will overwrite any data they have relating to the modules/packages that were promoted. So your configuration will stay the same as it was on whichever manager you have chosen to promote. When you promote a backup, it's data is now the authority within the framework and it gets replicated to the other managers and they are notified it has become the new primary manager.