UserID present on Agent but not Palo Firewall

Reply
L4 Transporter

UserID present on Agent but not Palo Firewall

Does anyone know under what conditions a Palo firewall will not be tracking a user ID, when said ID is being tracked by a Palo agent that is active and operational?

I have had experience of the agents themselves losing an ID for various reasons, but currently I have a scenario where a user is being prompted via a Captive Portal (a console session validates that the PA does not have a map for their PC), yet the Palo agent does have a valid record for that user at that IP address.

Highlighted
L4 Transporter

Re: UserID present on Agent but not Palo Firewall

Note: Should add that the IP range is not being filtered, and we have other valid maps on the same subnet.

Highlighted
L4 Transporter

Re: UserID present on Agent but not Palo Firewall

Hello,

Captive Portal should only be prompted for user's that do not have an active ip-user-mapping.

Did you confirm the user-id-agent has the ip mapping for the user?

Did you check the mapping via CLI on the device?

> show user ip-user-mapping ip <ip address>

It would be strange behavior for a user with a mapping to receive a Captive Portal prompt. I would recommend contacting your support team so we can perform some live debugging on the device.

- Stefan

Highlighted
L4 Transporter

Re: UserID present on Agent but not Palo Firewall

Stefan,

That is the issue - the agent *does* have a mapping, but the PA itself does not pick it up (even though it does for the other 500 odd accounts being tracked).  It is transient issue, so its not the host IP, or the account itself, it just sometimes doesn't get reflected accurately.

Will prob have to raise an official support call, but was looking for any hints first in case there are known scenarios when this may happen.

Rgds

Highlighted
L4 Transporter

Re: UserID present on Agent but not Palo Firewall

Is WMI or NetBIOS probing enabled?

Here is excerpt from User Identification Tech Note: https://live.paloaltonetworks.com/docs/DOC-3120

"If the probe succeeds and then subsequently fails for the same host, the IP will be re-classified as unknown."

If enabled, you may want to disable for testing.

It doesn't sound like a timeout issue, but you can enable 'Open Server Sessions' to see if that helps the problem.

- Stefan

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!