History shows SYSTEM account

[DBeard]

Since I've started distributing WGIC for our organization, I've noticed that half of the time, the user is reported to be the SYSTEM account for all the machines.

At first I thought this was realative to what was happening. For example Weatherbug or Norton AV would report as the system with they kicked off for an Internet update.

But I see that this occurs with normal browsing with the webbrowser as well. 50% of the time the user is correctly represented by who is logged in, and the other 50% of the time, Wingate logs the users as the SYSTEM account.

Any ideas on how to report the correct user for all activity?

[adrien]

What this means is that there is some application that is running as a service on the client machine, that is authenticating with the WGIC first. Then, when a user logs in on that machine, since their IP is already associated with a login, WinGate does not request one so the user's further activity is logged as SYSTEM.

You will need to look in the history and see what applications are first used in the SYSTEM account.

Ones to look for are things like winlogon.exe

If you then set this to local access only on the client, you can stop this happening.

Adrien

[DBeard]

Well actually it's all kinds of different applications. Half the time for example IE is coming through as SYSTEM.

[adrien]

What happens is that the first app that connects is the one that authenticates. If this app is running in the SYSTEM account (i.e. it is a system service), then any subsequent app that is run whilst the first one still holds it's WRP control connection, will also be deemed SYSTEM.

This is how IE could show as SYSTEM. What you would need to do is find the first app that starts up and logs in as SYSTEM, stop this, then if you only have apps able to use the WGIC once the user is logged in, then it should show the correct account.

Adrien

[francescmas]

Hi Adrien :

I have some similar problems, since Wingate 6.0 it seems that software is not as stable as it should be...

First. I'm using WGIC with password authentication, so I mean, any of the office users that try to connect to internet have to input their password in the WGIC window.

Second. We have a list of software inside WGIC with 'local access', so any software inside this list will not awake WGIC window and the software will think only local network exists.

But since WGIC 6.0, and since we have two separated lists inside WGIC (one for user and one for system applic.) this doesn't really work.

We have to serious problems :

First. In one computer, the user is ASSUMED by WG, BUT in our configuration we DON'T ALLOW ASSUMED users, so they must be authenticated. (!!!!!) But we can clearly see the assumed user in the WG screen.

Second. We can not stop some software awaking WGIC. We added this software to the 'local access' list (like GoogleDesktopIndex.exe, or other software...) but anyway when we log into Windows, we have to see those annoying WGIC password windows with a SYSTEM user asking for internet access... (I would like to remember it worked perfectly with WG 4.0 & WG 5.0, and stopped working with WG 6.0).

Third. Sometimes we have to RESET the WGIC because it just stops working, loosing access to internet...

I wish you'll solve all this bugs that appeared since 6.0. I wish go on working as happy as I was with 4.0-5.0.

Best regards,

Francesc Mas

[adrien]

Hi

The main thing that changed in WGIC with WinGate 6.0 is that since we added Central Config in the Winsock Redirector Service, the WGIC must always connect to the server first to determine if the application is allowed to run, and in what mode the administrator may have centrally configured that application to run.

This means that there will always be a connection to WinGate for all applications. However, if the application is configured for local access by way of central configuration or client configuration, it should then not redirect connections out through WinGate - it should only involve the control channel connection. This may still require authentication since the central configuration may be user-specific, so we need to see which user it is as well.

I'll have a discussion with the architects about WGIC asking for authentication on the client machines for these applications that are set to local mode. That must be a real pain.

Adrien

[francescmas]

Hi Adrien :

Now I've seen the light ! Yes, it's true, the problem started happening as soon as the WG 6.0 added central configuration possibility.

So I see there is a conflict between central and local configuration way of working.

I tried a long time ago to use the central configuration possibility, but it didn't work because I had to input the user password in WGIC window anyway, so it wasn't a solution. Of course, what user wants is not to see the WGIC password window when a 'listed for local access' software is trying to get access.

I really really wish your arquitects will understand this is a "very real plain", and once more, the reason I could just sleep 4 hours this night trying to make this work (finally I had to reinstall an old WGIC version again).

Best wishes,

Francesc Mas

[adrien]

Hi

Are you using the WinGate user database?

If so, have you considered using the windows one? In that case, authentication of WGIC can become transparent, so no username/dialog is presented.

there will still be the problem of SYSTEM account authenticating - if you want to prevent WinGate from deeming all users to be SYSTEM, you could try adding their IP to the list of multi-user machines. then you would see the system processes under SYSTEM, and their other applications under their actual user names.

If that works for you it could be a workaround until we sort this issue out.

Adrien

[francescmas]

NOW I saw I started asking about this annoying problem last 16th October 2005, so one year ago the problem was there with WINGATE 6.0.4 and you sent us an update version that didn't work. So the problem is known to be there since one year ago, but WINGATE team haven't solved it yet. (not nice... is it ?)

Yes we're using user database, because we want the user knows the computer is trying to connect to internet, so the WGIC password window is a very clear way to know it's getting connection.

So we don't like the idea to use windows users. If WGIC becomes transparent, then we will not know when some trojan or virus software is trying to get access to internet (WGIC saved us in two ocasions from trojans e-mails, because suddenly the WGIC window appeared).

It's just a way of controlling the software that access internet (IExplorer.exe...) and the software that must not access (antivirus clients, word, 'intelligent' updating software like acrobat...).

I don't like the idea of multiuser... I would like Wingate team would make Wingate Internet Client work as it did before version 6.0.

And I would like to know why sometimes, when Administrator user has logged in a workstation, WGIC stops working for normal users until administrator logs again and forces a RESET to WGIC...

I think (please beleive me) wingate was more stable one year ago than now. I wish you will help us. (please, I don't want to make provisional improvements to wingate while waiting for a new version).

Best regards,

Francesc Mas

[adrien]

Hi

One of the main reasons we added central config, and the options to terminate applications etc was to cover the scenario of viruses.

If you use a white-list approach with central config, then when any application tries to run that is not allowed because you didn't add it to the whitelist, then it will be blocked. So as long as you don't add viruses to the whitelist, they won't be able to run. Your users in this case will get a message saying the application will be terminated because they don't have rights to run it.

I'm sorry it has taken so long for me to get the message about the problem you are seeing. We have already had discussions about possible solutions. We won't be able to stop the WGIC connecting, but we should be able to stop it from requiring authentication in most cases.

Adrien

[francescmas]

Hello again Adrien :

It has been a long time since I have Wingate WGIC working bad (from october2005) and no real solution yet.

I wish you try to read again all my e-mail (search user:francescmas) as I'm still loosing night hours to solve a WGIC BUG.

With WGIC 6.2.2 still the same. If I want to use a list of application withiout access to internet, it will not work. I have tried to use Windows User DB and not Wingate User DB as you recommend, but it didn't work,

After installing WGIC 6.2.2 I had to see again the "You have no been granted rights to access this server" windows repeated for about 20 times one over the other on screen. It's really terrible.

I have to reinstall WGIC 5.2.2 to 12 machines to go on working tomorrow morning. WGIC 6.0, neither 6.1 neither 6.2.2 don't work with program and user list.

I wish to know if you'll finally solve the problem. I can not wait more.

I wish this e-mail will not desappear from the forum (as the last one, 6 months ago, did). Users have rights to know.

Best regards,

Francesc Mas

[quote="adrien"]Hi

One of the main reasons we added central config, and the options to terminate applications etc was to cover the scenario of viruses.

If you use a white-list approach with central config, then when any application tries to run that is not allowed because you didn't add it to the whitelist, then it will be blocked. So as long as you don't add viruses to the whitelist, they won't be able to run. Your users in this case will get a message saying the application will be terminated because they don't have rights to run it.

I'm sorry it has taken so long for me to get the message about the problem you are seeing. We have already had discussions about possible solutions. We won't be able to stop the WGIC connecting, but we should be able to stop it from requiring authentication in most cases.

Adrien[/quote]