User-ID suddenly stops recognizing Users

[ghafari47057]

I'm using PA-5020 as a Perimeter firewall with User-ID implementation for 5000+ users with multiple User-ID Agents across network.

Palo Alto Version : 7.1.8
User-ID Agent Version : 7.0.7-13

Problem i'm facing is the User-ID Agent, all of a sudden it stops recognizing users and it causes the users distruption in services accessing different applications. I'm monitoring this issue for a week now, i've upgraded my firewall from 7.0.x to 7.1.8 and User-ID agents from 6.x to 7.0.7-13 to mitigate this issue.
I've deployed a backup server also to overcome this issue that if server 1 doesn't recognize the user so it'll go to 2nd server. But still the issue exists.

Since my firewall policy is set that if the right policy doesn't hit, it falls to the policy which restricts access to all applications and denied applications gets block page and i get lots of requests from users complaining.

 

As shown in screenshot taken from my firewall.

Please suggest a fix to this issue.

Regards

[Hithead]

Hi,

check the User-ID Agent logs. May the "User Identification Timeout" value is to low...

Can you please share the User-ID agent settings?

we run this settings for years, without any trouble:

<timeout enabled="1" entry-timeout="840"/>

[ghafari47057]

Hi,

Find the screenshot below shows setting of User-ID Agent, the timeout value is set to 45 mins.

[bmorris1]

Hi ghafari47057,

It may be worth increasing the timeout value to 8-9 hours (a full working day) to try and prevent this issue from occuring. It could be that the user times out.

Additionally unless you have a genuine use case for WMI probing to be enabled, I would disable it as it a failed WMI probe will cause the user mapping to be removed. This could also be a cause of your issue.

hope this helps,

Ben

[BPry]

@ghafari47057,

I would lead more towards your WMI probing isn't returing a user, which clears the user-id from the table. That would explain why it's getting cleared out and why they start showing back up in a relatively short amount of time. 

If your clients don't move around between machines that often I would increase the timeout value as well; if you do have users switching machine on a regular basis then I would leave this the same, but most enviroments are fairly static when it comes to what user is using a given station. 

[ghafari47057]

@BPry

I've observed in my network both things, clients are moving often and many users are static and many users are loggedin to multiple machines simultaneously. So i 'm concerned that if i'll put the higher value (8-12 Hours), how'd it impact to dynamic users and the ones loggin in to multiple stations simultaneously.

[BPry]

@ghafari47057,

If that's the case then I would just turn off WMI probing and see if that solves your issue. Since you are reading the security logs though you can still have multiple users mapping to the same machine, and the user will be able to move around perfectly fine. The disadvantage of increasing the time-out value at that point would be more around a new user comming in and retaining the old users permissions until the user-id is updated in your firewall user cache. This would vary in concern based on your other settings; for example would they have the imporper user-id for 5 seconds or 5 minutes until the log gets read on the server and the update gets pushed out to the firewall. 

You can likely solve your issue as it sits with simply disabling WMI probing. If that fixes it then great, if not then we can dive into the advantages and disadvantages of raising your timeout value and if doing so would actually make sense in your enviroment based on how your security policies are designed. 

[Mike.ship]

I don't think setting the timeout longer would affect dynamic users as an authentication event is an authentication event. Also the user-id agent in 8.0 will now set the mappings timeout to never instead of applying the User Identification Timeout setting when the API sends user mappings with no timeout value.