User-ID - one user occasionally not hitting the user based policy

Showing results for 
Show  only  | Search instead for 
Did you mean: 

User-ID - one user occasionally not hitting the user based policy

L3 Networker

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?




Cyber Elite
Cyber Elite


It might be worth watching what the user is doing for a bit and seeing if they are doing something that would cause the user-id mapping to age-out or map to an unknown user? 

L2 Linker

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.  

L7 Applicator

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...




L3 Networker

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.

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...

Cloned the rule, yep. Left everything the same, but removed source user statement.

Will try poking around, yep.

L2 Linker

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.

L1 Bithead

Has anyone found a solution to this issue?


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. 

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.

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. 

L3 Networker

@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.

"Fixed an issue where user-based policies did not correctly match if the same user was included in both a policy with the username in NetBIOS format and another policy with the username in FQDN format."
If you are running any of these versions or above - it should be a different case there.
Workaround from my case (use it at your own risk, given we don't know if it is the same issue):
"> Remove User Domain override configuration from the Group-Mapping configuration.
> Configure one specific user-attribute in all the security policies"
  • 12 replies
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!