08-07-2018 05:57 AM - edited 08-08-2018 05:33 AM
PAN-OS 8.1.2, User-ID configured with Windows AD single domain. There are security rules built, based on users/user groups. It is mostly working as intended, but specifically there's [at least] one user that has a different behavior - some user-based (not group) rules are occasionally missing, even through they did hit the policy a few moments ago. Same traffic, same packet fields - IPs/ports, etc., but suddenly it goes through Deny, instead of hitting the Permit policy. At the same time same rules works fine for a different user. After a moment, it may start hitting the proper rule again.
When checking via CLI, faulty user is registered properly- there is user-ip mapping, user-group mapping, etc.
If creating additional rule, based on IP only, without username used - it hits that rule if it is missing the user-based rule, so there should an issue with User-ID, but not widely seen as there are a bunch of user/group rules used and they are working fine. Issue have been noticed with one specific user, but it is no different than any other user seen around.
useridd.log shows such an message, where <domain> - proper domain and <username> - username for the tricky user:
Warning: pan_user_group_user_prime_uid_lookup(pan_user_group_multi_attr.c:1306): For <domain>\<username> user, domain <domain> does not exist in group-mapping
I've tried resetting, clearing, refreshing, etc., but that didn't help.
Don't want to overwhelm with configuration, but maybe spew some ideas where to look?
Thanks!
08-07-2018 10:53 AM
Are you using the agent or agentless setup? I upgraded to version 8 not too long ago and ran into problems with the agentless setup. My problem was that the logged in user suddenly became unknown per the palo alto. Turns out I had two problems.
1. The default domain contorller policy for logins was only logging failure, not success. I changed this in the default domain controllers gpo.
2. I use the WMI Authentication for the User-ID Setup. The AD account used requires special permissions to work. My missing piece for that was that the account needed to be a member of the Remote Desktop User group on computer without local admin rights. I can't recall the special permission needed exactly, but that was the easy way to solve it.
08-07-2018 11:04 AM
Just one question for clarification....
In your detailed post you mention that if the ip address hits the rule that you added for ip only, it is allowed...
my question is ,,, when this happens, what user id is assosiated with this ip address when it is allowed via ip address.
is it the expected user id or blank or something else...
08-13-2018 01:40 AM
Thank you for the advices guys, somehow missed all the notifications.
As far as I know (not working directly with the end user) - nothing specifically fancy, but there could be something unnoticed though - no one was really sitting behind his back. But definitelly nothing major - same setup, just different time.
Yes, it is clientless (moslty, one agent as well). User is kind of known to the Palo - it is not lost at any time, but will check through updates documents regarding requirements anyway as initial setup is pre 8.0 era. Although given this concerns only one specific user - company wide issue should be seen more often I believe.
These is expected user-id associated with the IP in the logs and user-ip mappings. User field is not blank. If looking at the logs - they are exactly the same, with the difference of rule being hit. In one case - used-id base, in another case - backup IP-only based rule. User-ID mapping is still present in the cache - at least as far as I've checked from the CLI.
08-13-2018 02:21 AM
quick question,
when you created the rule for "IP" below the "user group" one, did you create a new rule from scratch.
it may be best to clone the user rule and just edit the source ip and user fields.
Also, (clutching at straws here). I would create a couple of cloned rules before the IP one to eliminate group membership issues...
1. source user = domain\username
2. source user = username
this may show some interesting results..
Or.. it may not...
just to see if the user matches to one of these...
08-13-2018 06:21 AM
Cloned the rule, yep. Left everything the same, but removed source user statement.
Will try poking around, yep.
08-12-2021 05:34 AM
I'm also facing issue like this.
User id not fetching in traffic logs. we created user base rule on that basis mapped ip address shows user id for same rule .but some time user is not authenticated from that user base policy rule and it is moving from next any any rule. if it is moving from any any rule that time it is not showing user-id mapping.
10-25-2021 02:33 PM
Has anyone found a solution to this issue?
10-25-2021 04:03 PM
What issue are you actually running into, can you describe your particular problem? Usually when users report an issue like this what you're running into is the user-id mapping aging out because you aren't seeing any authentication events in a timely manner so your user based entries won't match traffic anymore.
10-26-2021 05:51 AM
yeah, basically the same issue as @nikoo described above. We have about 10 users (out of 300+) that randomly get denied internet access for 5 to 15 minutes because none of policies catch them and they get the default policy. The useridd.log says that the user doesn't belong to any AD groups during these times.
10-26-2021 05:59 AM
check the User-IP mapping to see if it is againg-out correctly, if not check your User-ID Sources and change the time-out accordingly if needed.
10-26-2021 11:40 PM
@rlambright, at my specific case it was noted as a bug and fix was provided. General issue was with mixing UPN and SAM type of usernames in the policies. PAN-153614, fixed in 9.1.8 & 10.0.5.
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
