firstly I would take a note of one of the source IP's.
then run a filter on just that source ip to see if any user has ever been observed with that address...
if so then check your user mapping timeouts. they may be too low.
if your timeout is set to 45 mins and no AD activity in that time then user to ip will be removed.
are you using the device/user mapping or user-id agent.
i dont think reducing the timeout resolved your other problem....
@MP18 suggests 4 hours. this is a good suggestion.
I have mine set to 8 hours but 4 should suffice providing the PC has some domain activity within that 4 hours.
@BPry not to hijack but is there a list of sources that can be used for UserID? I knew of a few, including AD of course, but we ended up setting our timeouts to indefinate as that seemed to be the answer for domain joined machines that might have users that stay logged in to (I just lock mine everyday for example). The UserID for that IP would then only clear if the user logged off the machine.. although I'm assuming we may end up with stale data due to IP address changes.
That would work depending on your environment and your security requirements, but wouldn't generally be recommended due to the fact that the UserID information isn't likely to be accurate.
The sources that I know of are the following:
- Active Directory
- Exchange Server
- eDirectory Servers
- Syslog Servers
- Terminal Servers
Really since you have the ability to get syslog information and import information with the API, you can technically get user-id information from pretty much anything. For example the Cisco ISE and Cisco WLCs easily through this method.
@BPrythanks for the reply.
We were running into an issue where the User IDs were timing out and we'd start to see inconsistent logging... some logs would have the UserID, some wouldn't, then some would again. Obviously this would make UserID security based policy very difficult.
Our wireless and ResNet areas (basically all BYOD) use SafeConnect for NAC and we're already using their implementation to update Palo Alto UserID (they recommend an API user account be created for SafeConnect to use). We had to change the default timeout here because users on these networks only have to log in devices once every 120 days right now. Since they are BYOD, these devices don't usually change users.
The remainder of our network is academic and office spaces. For academic areas, lab computers and teacher workstations are logged in and out for class periods. Assuming a logoff event triggers a UserID clear event through the user agent connected to the AD controllers, UserID should be fairly up-to-date here. If not, the next user logging in should update it. For the office areas, I believe we had a lot of people leaving their computers logged in and just locked when they weren't around (I'm included here). I don't believe an unlock generates an AD security event so UserID here was eventually expiring on the Palo Alto and not populating.
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!