User Authenticated in Current Activities but not being used in Firewall/Web

For mixed environment the non-ad systems should be excluded from polling by defining their networks in the login/logoff exclusion area of the stas agent.

Can you try setting the MACs networks in this area and re-enabling log-off detection wmi.  Even when log-off detection is turned off if you look at the stas log or even look at the system event viewer you will still see stas agent attempting to determine who is "logged in.." and it does this first by attempting to use wmi. its not all correlated based on logon events recorded in the security log of the domain controller, there are more steps before that.

Hi Tom,

As somewhat alluded to in the email, I think we are tangenting off into STAS territority which is far disconnected to the issue I am actually suffering.

However, Macs are on the same network as PCs, suggestion is unfeasible.

To put this thread back on topic, there is not issue with logon and logoff between devices on the network and STAS, the issue lies between the XGs Current Activities > Live Users and the ipset list wherein the user will be authenticated (Mac or Windows), briefly visible in the logging data with their name against actions, then will not be visible against logging data shortly later. You can still see the user in Current Activities > Live Users but ipset is now stating that the ipset IP is unauthenticated. Unless the XG is polling constantly to STAS to constantly check and it's constantly logging out the user from ipset but not Live Users, I think this issue is being caused by something else.

As mentioned in my previous couple of replies, rebuilding it completely and resetting the unauth timeout seemed to drastically help the issue.

Emile

Update: This is being investigated, will provide details as and when they are received. If anyone else discovers this, please feel free to pop your notes and findings down as well :)

Emile,

could you try out a STAS config on the XG with timeout set to 120 seconds and no user inactivity (Enable user inactivity option disabled)? Or even a fresh install with the settings I just specified.

Thanks

Hi Sivu,

Had done both, same behaviour. This does not look to be directly STAS related but how the XG does its unknown IP auth procedure and it looks like it may be interfering with normal log ons in some cases.

Emile

OK, was asking this because I've checked logs provided by Tom, and there there was some continuous login and (shortly after) logout going on, which could explain some side effect in the ipset. 

From what I've seen, this isn't a problem on the STAS side (as you confirmed) and also not on the authentication front, but with wrong information inside the ipset.

If you still face the issue after all this trying out, would be awesome if you could help us reproduce this.

Hi Sivu,

This issue is live in an environment that i can provide access to. I can see you are Sophos Staff so if you can email me then we can organise access to the environment it is currently occurring in.

Since early v17 i have noticed inflated numbers of logout logins but do not seem to be related to ipset.

Emile

Hello Sivu 

I am getting very concerned that we are getting to two weeks till v17.5 GA and I have an issue here which is binning 15% of all logged on traffic and in my eyes, this is quite a serious problem.

If you have managed to re-create this issue, please can you report that here and if you haven't then I have a live system with this issue on I can provide access to.

If v17.5 drops and it kills 15% of authenticated traffic that really isn't going to look good considering how near brilliant each major version deployment has gone in the past.

Emile

Emile has provided access to an appliance and several logs. The issue is being currently investigated offline.

I was having this issue also, when I rolled back to 17.1 users were matched against connections correctly.