Dual Approval policy is not working on secondary CA PAM site

Products

• CA Privileged Access Manager (PAM)

Issue/Introduction

Whenever a Password View Policy (PVP) is defined to enforce so, usage of a target account to do autologin to endpoints will trigger Dual Authorization and an approver will be notified. In a multisite cluster environment, this will happen no matter if access is done from an appliance in the primary or one of the secondary sites.

A rare condition may arise where the Dual Authorization will be skipped in the secondary site appliances. That is: trying to do autologin to a target server will result in requiring to complete the reason for connect in the PAM screen provided to this effect, but instead of holding access and logon until authorization is provided, the process will be engaged right away. If the same operation is carried out from a primary site appliance, the approval workflow follows the correct process.

Environment

CA PAM all versions

Cause

There may be other causes for this behaviour, but in the present article we are discussing the one which will result in the following message being logged in the session logs of the secondary appliance from which the login with Dual Authorization is being attempted

2022/01/24 14:00:19,seven,admin, --,"GroupName,Sysadmin,TAP Administrators", --, --, --,XXX.XXX.XXX.XXX,YYY.YYY.YYY.YYY, --, --, --, --, --,"PAM-CMN-1806: Password view request returned warning code 452. Message was PAM-CM-0615: Primary site is unavailable. Any workflow tasks associated with the account's password view policy (dual authorization, change password, or check-in/checkout) have not been performed.. Request ignored.",0, --,,0

Basically the secondary site members cannot communicate properly with the primary site and therefore the primary site is unable to validate the request for authorization.

To avoid causing a major operational problem, the default action of CA PAM is to allow access if the data requested is valid for login to the remote endpoint. In the tomcat log of the secondary site member the following entry will be reported

Jan 24, 2022 2:00:31 PM com.cloakware.cspm.server.app.impl.CommandProxyTransmitter transmitProxiedCommands
SEVERE: CommandProxyTransmitter.transmitProxiedCommands Error communicating with primary site: Read timeout

If in a cluster environment this may mean that the secondary site has lost communication to the primary site and this should be verified.

However, it is also possible that cluster replication and synchronization is perfectly fine and that all nodes are showing in green color in the cluster management GUI.

In this case the most likely cause for this error is that the primary site has lost the cluster VIP.

That is: the cluster or primary site (and also possibly secondary sites) are not reachable by their VIP, but the nodes can be accessed by their IP just fine.

All ports are open and SQL replication is working seamlessly, which means all indicators are showing in green in the cluster manager.

To verify if this is the use case faced, please try the following

https://<Cluster_VIP>/cspm/home

or from one of the nodes try scanning the VIP for ports open, notably 8443, 443 and 3307

The reason why losing the primary site VIP may be causing this issue is because, as stated in the documentation, the primary site VIP is used for communications between the secondary site members and the primary site master. Failure to be assigned at cluster startup results in cluster not starting, but if for some reason the VIP is dropped when the cluster is already in operation, SQL replication will not be affected, but other operations requiring communications through the VIP will.

Resolution

In this particular case a cluster restart will sort out the problem.

If a cluster restart is not possible, please raise a case and engage Broadcom Support.