AD User Identification lost on random clients. Sophos V10.x to blame?

[ktm530russ]

We are having an issue with some of our clients suddenly losing Internet access in the middle of their work-day, many times while actively browsing the internet.

We have a PA2020, running V4.1.6, with the older PanAgent (3.1.2) on one of our member servers. So far in our troubleshooting, the common thread seems to be the client workstation attempting to access a Sophos site: http.00.s.sophosxl.net/V3/"IP address and/or random characters". We were hoping that someone else out there had experienced this, and has a solution to this issue. We don't think it is using a service-account, at least we have not been able to isolate one from this, so there is nothing to add to the "ignore_user_list.txt" file.  We have a Sophos tech support case open, and will be starting a PA case if nobody here can provide information on this issue.

[rmonvon]

Hi...At the time of the failure, what is the userID being detected for the user?  You can check on the PA2020 and also the PAN Agent by querying on the user's IP address.

The PA2020 is running version 4.1.6, and we would recommend that you upgrade & use the 4.1.X agent.  Thanks,

[ktm530russ]

There is actually NO userID being detected when the failure occurs. I pulled up the Monitor/URL Filtering, and filtered on the IP address of the computer/user having issues. There was a lot of allowed activity, and it showed the IP address and the userID. At the point of failure, when they started getting blocked, the "Source User" column is empty.

We have found they can regain access by locking/unlocking their workstations, or running our old "WebSenseLogon" batch file that forced an AD update of the userID/Workstation pair. Sometimes it works for a long time, other times, it works for only a few minutes or hours.

The only common factor on the ones we did troubleshooting on was the URL that showed up as the first one with no userID: http.00.s.sophosxl.net/V3/(various extensions)

[apackard]

Do you have Server Sessions monitoring enabled on your agents?

I found that this caused similar symptoms to what you describe - apparently if the agent returns a different username from a 'session scrape' to that maintained via the AD logs it 'resets' the mapping to blank (in effect it cannot conclude which one is the valid mapping so clears both and waits for an updated mapping to be setup).

I still have some issues with lost mappings, but disabling this feature certainly stopped a lot (for us).

[rmonvon]

Also, you can extend the User Identification Timeout (min.) to a longer duration on the agent.  Maybe the credential cache has timed out and the user become unknown.

[ktm530russ]

We are using the 3.1 agent still, I see the "timeout" parameter for Server Sessions, but not a configurable enable/disable.

Our 4.1 agent (not in use yet, but being configured), has the Server Sessions checkbox disabled.

I don't see an option on the Group Mapping Settings on the PA for this either. I don't think that this is the issue, as it just started recently, and we have not updated or made changes in about a month, but your explaination helps a lot. We just need to reverse engineer to find out why the PA is clearing the mappings...

"rmonvon", thanks for the input on the timeout, we already have it set to 720 minutes to cover our 8-hour work day, and the issue has random timestamps (sometimes 10-20 minutes between losing the ID, other times 3-4 hours, etc.) It is also just a handful of our 1,000+/- clients that this affects, and those also change almost every time.

Most are "fixed" by locking the workstation, then logging back on, but we had one client that lost her ID 4 times in a couple of hours.

I am considering disabling NETBIOS polling, but not sure how that would affect our identification process...

[moorken]

we are currently experiencing the same issue in our environment,  we have a forest with 15 domains, but currently only the users of 1 domain looks to be affected despite having the same user-ID version running on all systems (4.1.4-3) no solution found yet...

[ktm530russ · Accepted solution]

We have solved our issues, there were a couple of changes that we had to make:

1: We turned OFF NetBios probing. Fixed the issue for a short while, then we upgraded the AD Agent, and it came back.

2: DOWNGRADED the AD Agent. 4.1.4-3 has a BUG if you use an "ignore_user_list.txt" file - it will delete the UserID mapping on the PA firewall.

     (They state a fix will be in 4.1.6, slated for release "soon". Downgrade to 4.1.2-2)

3: AD Authentication was changed during our testing, we HAD set it using the "short" Domain name, it got changed to the FQDN, and our policies stopped working. (But would work if we put the SAME Group/Container in the Policy with the FQDN)

moorken - I believe your issue is the bug, you might need to downgrade the Agent until 4.1.6 gets released.

[moorken]

unfortunately with all above 3 changes we still seem to receive some blank users in the "source user" field.  We will wait for the release of the new client and then try again