node_type+ showing different values for registration in PAM SC endpoint
search cancel

node_type+ showing different values for registration in PAM SC endpoint

book

Article ID: 262914

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

During PAM SC endpoint operation when both UNAB and PAM SC are installed in the same endpoint, agent_debug in the agent, and the DH/policyorchestrator log show different values for the node type.

For instance:

2023-03-28T11:43:48.446050050Z 2023-03-28 11:43:48.445  INFO 13 --- [nio-9091-exec-1] c.b.s.p.p.e.rest.EndpointDeviceAPI       : The message receieved from the end point device is editres HNODE ("test.broadcom.com") node_type+("ACU") latest_keep_alive("03/28/23@11:43") node_version+("ACU:14.10.40.23") node_ip+("x.x.x.x") node_info("Linux 4.4.73-5-default x86_64, SUSE Linux Enterprise Server 12 (x86_64)") Attributes+(REGISTERED_NAME=test.broadcom.com  MAC_ADDRESS=x-x-x-x-x-x) bypass_exist- ac_id("f9080159-55ff-0001-c1a6-1d64ca000000")

for the DH/Policyorchestrator log, but the agent_debug log in UNAB...

20230328113429.514587 T552103936 L 5: Scheduler: Sent heartbeat to DMS - editres HNODE ("test.broadcom.com") node_type+(ACUNAB) latest_keep_alive("03/28/23@11:34") node_version+("UNAB:14.10.40.137") node_ip+("x.x.x.x") node_info("Linux 4.4.73-5-default x86_64, SUSE Linux Enterprise Server 12 SP3") unab_id("f9080159-4d11-0001-a843-1c64ca000000")
20230328113429.514594 T552103936 L10: Scheduler: Closing current message queue connection.
20230328113529.578785 T552103936 L 5: Scheduler: registered with CA PAMSC

As highlighted UNAB reports the node to be of type ACUNAB, whereas PAM SC lists it as ACU. This article discusses this difference

Environment

PAM SC 14.X all versions

Resolution

This is normal behaviour. The HNODE itself will contain both types of node, that is, it will be of type (ACUNAB, AC), but since UNAB and regular seos operation work with different flows, and each one sends its specific information to its server (ActiveMQ in the case of UNAB, and the DH in the case of seos), which afterwards consolidates it in the HNODE registry in the DMS/DH. So this is a valid behaviour