A2A calls fail with 437 error after upgrade to 4.1.1

Products

• CA Privileged Access Manager (PAM)

Issue/Introduction

Since the upgrade to 4.1.1 many A2A calls fail with a 437 error. The tomcat logs shows "tampering detected" messages. We are not aware of any changes to the A2A client, or the configuration of the A2A script, request groups or mappings.

This affects A2A calls using a mapping defined for a requestor group, where the group was created in a PAM release older than 3.3.

Environment

Release : 4.1.1

Cause

The 4.1 release includes new feature Secrets Management, which uses what is considered an internal index range for internal objects stored in the PAM database, including target and request groups. This range was not internal in old releases, up to PAM 3.2. The 4.1.1 upgrade patch will move any existing groups in that range to a new index and update other tables such as authorization mappings accordingly. But the process could leave an old hash behind that does not reflect the new group ID, resulting in tampering errors.

Resolution

A defect has been raised with PAM Engineering to get it fixed in the next maintenance release.

A workaround after the upgrade to 4.1.1 is to edit the A2A mappings defined with old request groups and save them by clicking the OK button. No change needs to be made. Mappings using request groups show a group name in parentheses in the Client/(Request Group) column, as seen in the screenshot below.

Additional Information

If you are using the remote CLI, you can use the resetDBHash command with object class "c.cw.m.sa" as parameter to have PAM recalculate the hash, which will resolve the problem for all affected mappings in one step:

 

capam_command capam=<pam-instance> adminUserID=<PAM admin> cmdName=resetDBHash objectClass=c.cw.m.sa