A standalone AWS PAM instance using a single CPU became slow and eventually unresponsive after installing an A2A client on a Linux host. The A2A client never showed as active. While the PAM server was accessible, we saw very high CPU usage and the hard drive was filling up.
PAM 3.0.2 in AWS with security option "TLS v1.0/1.1 Connection Allowed" disabled on the Configuration > Security > Access page. PAM 3.0.1 A2A client installed on a Linux host.
The problem was caused by a known issue with the A2A Linux/Unix client for PAM 3.0.1. By default it connects to web servers using TLS 1.0, which will not be allowed by a PAM server that has TSL 1.0 and 1.1 connections disabled. See community post https://communities.ca.com/community/ca-security/ca-privileged-access-management/blog/2018/04/27/tech-tip-ca-privileged-access-manager-pam-301-a2a-unix-client-not-working-after-disabling-tls-10-and-11.
On failed connection attempts the A2A client keeps trying to reconnect w/o pause. On a PAM server will limited resources, such as a single-CPU server, a single A2A client stuck in the connection loop can make the PAM server almost unresponsive. It will also lead to a rapid growth of the local A2A client log, and a web service log on the PAM server. The latter may grow to several GB in size within a day and fill up all available disk space on a small volume. At that point the PAM server will become completely unresponsive.
We resolved the problem with the A2A agent by updating the cspmclientd service script following instructions at https://communities.ca.com/community/ca-security/ca-privileged-access-management/blog/2018/04/27/tech-tip-ca-privileged-access-manager-pam-301-a2a-unix-client-not-working-after-disabling-tls-10-and-11. CA PAM support was engaged to resolve the disk full condition. This included removal of the huge log file, and an increase of the volume size which was slightly below the recommended minimum. With PAM 3.X the latter is possible and can be accomplished w/o engaging support.