PAM node credential manager rebooting after adding node to cluster
search cancel

PAM node credential manager rebooting after adding node to cluster

book

Article ID: 383113

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

It is possible that at a certain point a new node needs to be added to an existing cluster

Apparently this works fine and the GUI is showing the nodes in sync, but the node never comes up. It just shows the PAM is starting up message and unable to log in

If checking the catalina.out- assuming it is available, and the following error messages appear

2024-11-29T08:45:25.341+0000 WARNING [Catalina-utility-1] com.cloakware.cspm.server.security.ApplicationClusterManager.initialize ApplicationClusterManager.initialize Adding local bind interface and address <ip_address_node>:5900
2024-11-29T08:45:25.399+0000 SEVERE [Catalina-utility-1] com.cloakware.cspm.server.app.CryptoHelper.decryptBC BouncyCastle Decrypt failed
    javax.crypto.BadPaddingException: Error finalising cipher data: pad block corrupted
        at org.bouncycastle.jcajce.provider.BaseCipher.engineDoFinal(Unknown Source)
        at org.bouncycastle.jcajce.provider.BaseCipher.engineDoFinal(Unknown Source)
        at javax.crypto.Cipher.doFinal(Cipher.java:2115)
        at com.cloakware.cspm.server.app.CryptoHelper.doBCDecrypt(CryptoHelper.java:152)

Environment

CA PAM all 4.1.X versions up to 4.1.7

Cause

This may be caused by the new node being added to the cluster not having the vulnerability security patch applied. There is a version for every CA PAM version published, from 4.1.2 to 4.1.7 (for instance in 4.1.7 it is patch 4.1.7.50)

This security patch modifies, as part of its remediation, the way in which keys are distributed and shared, and hence what is happening is that clustering together patched and unpatched nodes leads to problems sharing the cluster keys and this causes cspm to boot on end, leading to the problem observed

Resolution

If the ssh debug patch has not been installed so that support can work on it, the best option is to reinstate the appliance being added to cluster and to make sure the same level of patches is applied there than in the already clustered one(s) and in particular hotfix 4.1.7.50 or equivalent

If this is not possible please engage Broadcom Support to help you reset database manually and redefine cluster. However please bear in mind that the ssh debug patch will have to be loaded and ssh enabled in order for Broadcom Support to be able to help.