Users have no access.
[Debug 988]: Reached max allowble probes, adding IP 10.100.xxx.xxx to queue for later processing. Probing 40 IPs, list contains 117 entries
Reached max allowble probes, adding IP 10.100.xxx.xxx to queue for later processing. Probing 40 IPs, list contains 117 entries
Probing IP 10.100.xxx.xxx failed. For initial probing, try again after 3 min
[ Info 938]: IP 10.100.xxx.xxx is already in the probing queue
[Debug 484]: IP 10.100.xxx.xxx for acme\user cannot be probed. List is full of 201 entries, currently probing 40
+0500 Error: pan_user_id_agent_proc_ipuser(pan_user_id_uia.c:444): pan_user_id_agent_send_ip_user_to_dp() failed for user acme\user
+0500 Error: pan_user_id_uia_handle_ip_msg_i(pan_user_id_uia_v5.c:141): pan_user_id_agent_proc_ipuser(vsys 1, ip 10.100.xxx.xxx, user acme\user, timestamp 1466142528) failed
What we can do?
Solved! Go to Solution.
Having debug on in a scaled deployment can sometimes cause problems. You could try disabling or lower the debug level to alleviate the problem.
Alternatively you could disable probing :
Splitting the load over multiple agents is also a good idea in a scaled deployment.
The problem because of NetBIOS probes have queue
When we disable NetBIOS probes all users have no access after relogon.
Than we enable WMI probes the problem of User-ID disapear
for correct user rights for WMI probes we use: wmic /node:(IP address) computersystem
The installation is about 1500 users and 2 User agents.
First of all the user to IP mapping should be refreshed at user logon. Please make sure that every logon is generating security events on the LDAP servers and the the agent is able to map them,
Seems that almost all of your user to ip mapping relies on windows probes which is not ideal, As an alternative method you could enable kerberos SSO in captive portal.
Probing is more of an active user mapping to verify a user is still linked to a certain IP address. The LDAP server creates user-to-ip mappings where WMI probing actively verifies a user is still valid. The probing variable can be changed from the default setting to a longer duration so that clients are not probed as often or possibly disable probing altogether. When changing the duration, you may set the timer to half the value of your DHCP renewal timer
By Palo Alto technical 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 Live Community as a whole!
The Live Community thanks you for your participation!