UserID Factor Completion Time - Bad Data

[apackard]

We are seeing some random UserID entries being fed into our firewall that have a Factor Completion Time of "1969/12/31 19:00:00"; these always have a timeout of "0" so effectively kill the user mappings for that user.

Has anyone seen this before?  We have quite a convoluted setup for many reasons, one if which is that the UserID's generating these feeds are not under our direct control, and while we're only 8.0.x the source agents are 2-3 years old, so wondering if it's a version mismatch issue

[Mick_Ball]

1969/12/31 19:00:00     is the unix epoch. its what server times are calculated on, day 1 in affect...

something must be sending or the PA is wrongly recording the time stamp of the record.

I have never seen this but of course... if this is when the mapping was recorded then in todays date, it has expired.

perhaps find out where the record was sent from or adjust your user-id timeout to 1,577,847,600 Seconds

[BPry]

@Mick_Ball,

You made me spit coffee on my monitor...

[apackard]

Cheers - yep we'd assumed it was an Epoch time (the source is EST so also 5 hours behind GMT).

We are unable to access the UserID services generating the raw data - much as I'd like to ask them to change their 7,200 second timeout to something more palatable and stop (their) users being blocked by (our) firewalls.

The interesting aspect is that we pick these up on a Palo, redistribute back to Panorama and from there push out to other firewalls (I said it was convoluted).  As part of that sequence these entries seem to get filtered as if something along the way assumes they're corrupt and discards them - we've actually got it setup so that the 'least important' firewalls get the direct updates and push out to the important ones so we can use this (undocumented!) feature to fix the data.