Utility Appliance v2.0 in Azure cannot start microservices
search cancel

Utility Appliance v2.0 in Azure cannot start microservices

book

Article ID: 410409

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

A v2.0 Utility Appliance (UA) has been deployed in Azure using as IP the public-facing Azure Static IP

UA has been added fine to the Utility group and k8-core and pam-distribution- software have been deployed to it, but on checking Status none of the microservices (a2a, dh, loginintegration...) is able to start with a message that it could not retrieve the activemq password. This despite the ActiveMQ password having the default value under Server Control --> Settings

Checking under Credentials --> Manage A2A --> Clients, we see an entry for the UA but not with the Azure Static public-facing IP but with the internal Azure UA address which is showing as inactive. In the same way, if checking devices, one can see that a new device of type Linux made of the UA and its internal IP has been created, besides the already existing UA device with the Static public-facing IP

Environment

CA PAM 4.2.X

Cause

This is due to how the deployment works: once the services are deployed to the UA, it will try to register itself as an A2A client but using its internal IP. That will cause the appearance of the entry in the Clients screen under Manage A2A, marked as inactive, and it will also make a device of type Linux to be inserted into PAM once again with the internal Azure IP for the UA.

The existing UA device, with its Static public-facing IP will still be there as for PAM it is a different device. The catch 22 is that since the new registered device is not registered as type Utility Appliance and it is not a member of any Utility Group, it won't be possible for it to work as a UA, so the situation is inconsistent

Resolution

In Azure, as well as AWS, when added the UA must be added with its internal IP address, not the public-facing Static IP. While documentation states so clearly for AWS, as of the writing of this document, this is not the case for Azure. A defect has been opened as of the writing of this document so that this is adequately corrected