Password Sync issue with CAPAM, possible cause from PAMSC

Products

• CA Privileged Access Manager (PAM)
• CA Privileged Access Manager - Cloakware Password Authority (PA)
• CA Privileged Access Manager - Server Control (PAMSC)

Issue/Introduction

A client found this issue after installing the PAM SC endpoint on several Linux machine in one specific environment All machines were running RHEL 7.8 and all used the latest supported version of PAMSC. When the PAM SC Endpoint was started the password verify and password rotations would both fail. After unloading the endpoint service both resumed working fine. 

 

Sample error from the tomcat log on the PAM server

Aug 18, 2020 7:05:27 PM com.cloakware.cspm.server.plugin.SSHUserInfoImpl promptPassword
INFO: jsch: password prompt: 'Password for <username>@<ipaddress>'
Aug 18, 2020 7:05:27 PM com.cloakware.cspm.server.plugin.SSHConnector$1 log
INFO: jsch: Authentication succeeded (password).

...
Aug 18, 2020 7:05:48 PM com.cloakware.cspm.server.plugin.SSHConnector$1 log
INFO: jsch: Disconnecting from <servername> port 22

...

Caused by: com.jcraft.jsch.JSchException: channel is not opened.
        at com.jcraft.jsch.Channel.sendChannelOpen(Channel.java:765)
        at com.jcraft.jsch.Channel.connect(Channel.java:151)
        at com.jcraft.jsch.Channel.connect(Channel.java:145)
        at com.cloakware.cspm.server.plugin.SSHConnector.connect(SSHConnector.java:126)

Environment

PAM 3.x

PAM SC Release : 14.1

Component : PAM SERVER CONTROL ENDPOINT WINDOWS

Cause

We found a network timeout was encounter specific to a failed DNS lookup of the PAM Appliance from its IP. Since the PAM SC endpoint required the hostname this extra time used in name resolution caused a timeout in the process that runs the verification process. The key indicator to the timeout was the error in the tomcat.log " channel is not opened."

Resolution

A temporary fix was used by simply adding the IP and hostname to the /etc/hosts file but the full resolve was to modify the /etc/resolv.conf and add the appropriate NS server into the list of name servers. After resolving this issue all password updates were also faster than previous with or without the PAM SC endpoint loaded