topic Re: Issues getting ip-user mapping with probing error in General Topics

Issues getting ip-user mapping with probing error

vinesh — Fri, 01 Mar 2013 17:04:34 GMT

Hello,

I've got UI agent 4.1.6 configured on PanOS 4.1.9.

We have around 3000 users and in agent we see only around 700 user-mapping count.

in the logs we get the below error for a lot of IPs and i guess that's why we dont get all users. I've tried to disable WMI but still doesnt work.

Have anyone experienced a similar iissue?

2/22/13 08:17:29:688[ Info 856]: IP 10.76.15.140 is already in the probing queue

02/22/13 08:17:29:688[ Info 856]: IP 10.76.45.123 is already in the probing queue

02/22/13 08:17:29:688[ Info 856]: IP 10.76.15.205 is already in the probing queue

02/22/13 08:17:29:688[ Info 856]: IP 10.76.15.196 is already in the probing queue

Re: Issues getting ip-user mapping with probing error

scantwell — Fri, 01 Mar 2013 17:38:30 GMT

I have not seen it, but I am curious what your probing interval currently is set at.

At the same point in time, I am not sure I understand why disabling this would attempt to resolve this issue.

Remember that active probing is for anyone that is NOT known.

So before you troubleshoot that portion, you need go back to step 1.

There are 2 steps to get UserID working (FW connecting to LDAP server) and (getting user to IP mappings).

There are 6 ways (at least) to get IPs (Security Login/Logff from AD/Exchange, WMI, CP, XML API, etc) So...

I think the question you should ask is: WHY is the UserID agent not able to query your AD to determine who your IP users are?

Remember that active probing is for anyone that is NOT known, and to confirm that a User still has IP address that is cached.

What is your user id cache set for? Is it the default (45 minutes)?

Maybe you can increase to 1/2 of your DHCP time(which is when users will ask for their same IP from your DHCP server).

Re: Issues getting ip-user mapping with probing error

vinesh — Fri, 01 Mar 2013 18:01:13 GMT

Hi,

The agent settings are set to default.

Part of the log also shows below. So, should we be probing ips like that?

Using only AD method and could it be a problem with an inability to read the security log?

02/21/13 11:37:47:675[Debug 838]: Unable to probe IP 10.74.45.81, list is full with 201 entries, currently probing 40 IPs

02/21/13 11:37:47:675[Debug 838]: Unable to probe IP 10.74.17.21, list is full with 201 entries, currently probing 40 IPs

02/21/13 11:37:47:675[Debug 838]: Unable to probe IP 10.74.58.111, list is full with 201 entries, currently probing 40 IPs

02/21/13 11:37:47:675[Debug 838]: Unable to probe IP 10.74.96.188, list is full with 201 entries, currently probing 40 IPs

02/21/13 11:37:47:675[Debug 838]: Unable to probe IP 10.74.96.224, list is full with 201 entries, currently probing 40 IPs

02/21/13 11:37:47:675[Debug 838]: Unable to probe IP 10.74.110.78, list is full with 201 entries, currently probing 40 IPs

02/21/13 11:37:47:675[Debug 838]: Unable to probe IP 10.74.51.184, list is full with 201 entries, currently probing 40 IPs

Re: Issues getting ip-user mapping with probing error

scantwell — Fri, 01 Mar 2013 19:39:25 GMT

Hmmm, this gets tough to answer. I think that if you are getting some AD information, then you are reading security logs. I think I would turn OFF probing entirely (for now), so that you can focus on troubleshooting the UserID issue. I would change the timeout to 1/2 of your DHCP timer (so if DHCP is 8 hours, change cache to 4 hours), you need to effectively make some change to see if it a positive change or no change. I do not know the limits of how many IPs can be probed, but maybe the 201 entries is the max amount. So, I would stop probing. The net effect is that you have not lost any UserID information, because that is what we are troubleshooting. Make sure your UserID has the proper permissions to reach the Security Logs on the AD. Do you have the FW communicating to the LDAP server directly, or are you using the UserID agent in LDAP proxy mode? Is the FW and the DC in the same location (not across a WAN link, etc)? Ultimately, I would not have a problem creating a TAC case in this issue. That is why there are here. We the in the community can provide guidelines to help, but of course TAC will be the best to T-shoot and resolve this. Let me know what you find.