In situations where there is an intensive use of A2A as well as Credential Management, the following use case is possible:
A targetserver (PA) is created using Command Line Interface (CLI) with short name as hostname and fqdn as the domain name (e.g. mydevice and mydevice.broadcom.net)
Then a requestserver (A2A) is also created using CLI with same fqdn as hostname and device name, obviously with the same names as before (e.g. mydevice.broadcom.net and mydevice.broadcom.net)
This leads in the host table to 2 devices: one with the short and one with the fqdn name, and both with the same device name (fqdn).
In pratice this amounts to a "duplicate" entry, as both should have the same IP
The way that these entries have been created, one of them (the one with the short name) should have credential management capacies, and the other one (with fqdn as the hostname) should work to perform A2A commands
If then the A2A device is marked as PA as well (by editing the device in the GUI), the result is that PAM will attempt to create a new entry in the targetserver table using the IP which is already there, resulting in an error.
If the opposite operation is done, that is, the device for which Password Authority capabilites are enabled is also marked as A2A, the product accepts it and disables the existing A2A record, whereby all references to it are lost for the scripts using it.
CA PAM 3.4.X and 4.X
For the time being this is working as designed. Advice would be to be consistent in the CLI registration to avoid having duplicate devices in related tables with either the short name or the fqdn.
This is a change of functionality which SE are evaluating and a correction to this behaviour will be ready in the future
This KB scenario can happen in the UI as well. If you define on A2A Device with the IP and another with the servername.