User-ID in FIPS-CC

[G.Williamson789500]

Hello,

I am having an issue setting up user-id when the firewall is in FIPS-CC mode. Here is the following issue:

Environment:

• PA-3440, PAN-OS 11.2.10-h7, FIPS-CC mode enabled
• Windows User-ID Agent v11.0.3-134 (identical version on both hosts)

Issue:
I have two Windows-based User-ID Agents configured under Device > Data Redistribution > Agents, pointing to two domain controllers (DC-A and DC-B) with identical config (same port 5007, same vsys, both enabled). DC-B connects fine. DC-A has never connected, and it looks like the firewall isn't even attempting a connection to it.

Key diagnostic finding:

> show user user-id-agent statistics
Name    Host     Port  Vsys    State       Ver
DC-B    ...      5007  vsys1   conn:idle   5

> show redistribution agent statistics
Name    Host     Port  Vsys    State           Ver
DC-A    ...      5007  vsys1   not-conn:idle   6

DC-B is registering under the legacy User-ID Agent (protocol v5) handler and connects successfully. DC-A is registering under the newer Redistribution Agent (protocol v6) handler, and show redistribution agent state DC-A shows num of connection tried: 0 — zero attempts, ever.

Already ruled out:

• Network path — clean ping to DC-A, 0% loss, tested both default and sourced from mgmt interface
• Agent software version — confirmed identical on both DCs
• Config/commit — DC-A entry exists, enabled, commits without error; also tried full delete + clean re-add, no change
• Collector Settings (Device > Data Redistribution > Collector Settings) — unconfigured on both, ruled out as a factor
• Unrelated LDAPS/group-mapping connections to both DCs (port 636) are working fine, so it's not a broader connectivity/cert issue to that DC

Has anyone run into this issue and any suggestions. 

[JayGolf]

Hi @G.Williamson789500 ,

There might be a mismatch or incompatibility in the secure communication settings between the firewall in FIPS-CC mode and DC-A which could be why youre not seeing any connection attempts. I would run a packet capture, Even if number of attempts is reported at 0, it's possible that very early SSL negotiation attempts are failing before a full connection attempt is logged. Also, If you enter "less mp-log distributord.log" , do you see any related ssl/tls errors?