Wingate7: Problems with Assumed Users

[fpuded]

Hello all,

Actually I'm testing the 30 day trial of Wingate7.
While testing I noticed that the assumption list isn't working, if I use the "Web:Authentication" Policy.
I've assumed my Workstation by IP and it is working, if I exclude the Policy. But as soon as I include it into my Test Policy, I need to authenticate.

I took a look at the Activity screen and noticed, that Wingate showed my name, instead of 'unknown' user. But when I view the properties of this connection, it has the security level 'Unknown User'.
So it seems that the problem is related to the missing security level.

Is there a way to get the assumption working?

Kind Regards,
Torsten

[adrien]

Hi Torsten

WinGate 7 is bit different to WinGate 6 in this respect. With WinGate 6, we had 3 "security levels", unknown, assumed and authenticated.

For years this was a source of confusion, especially when we did things like decide that plaintext auth methods would only raise your level to assumed.

So in WinGate 7 we decided a user was either unknown or known. They can be known by authentication or a credential rule (assumption).

The way it works in WinGate 7 is the same way the OS does it. When a user logs on, they get a token, which contains all the SIDs of all the groups they are a member of. When they authenticate, they will get a SID also for "Authenticated users". There are a number of other automatic "groups" that the OS maintains in this way.

When you set up a credential rule, we create a token on behalf, since there was no auth for the OS to do it for us. The SIDs we add are all the groups the user is a member of, but since they did not actually auth, we don't add the SID for Authenticated users. So, if a user is assumed, and you test for membership of "authenticated users", it won't match.

The auth policy does such a test, so it won't match on assumed users, and will therefore prompt them for authentication.

So if you don't want assumed users to be required to auth, and you're using policy (rather than web access control), then you'll need to do a check in policy before the check for Authenticated users, or do a check for some other group (e.g. users, or Internet allowed or similar).

Regards

Adrien

[fpuded]

Hi Adrien,

thanks a lot for the explanation! I managed to get the assumed Users to work.

But unfortunately I'm having the next problem and hope you can help me once more. :-)
I created a policy set, which works great when using http connections, but doesn't seems to apply to HTTPS connections.
The policiy uses lists to block specific sites. It works for e.g. http://mail.google.com, but doesn't for https://mail.google.com

From the Policy view, where you can see the "way" a connection has been processed, it looks like the site request has never been processed through my policy. Neither I can see the way to my reject, nor to my Accept result.
Is HTTPS handled different, than HTTP? I guess I can only use {{Request.Server}} value, because the {{Request.url}} won't work, when using https, doesn't it?

Regards,
Torsten

[adrien]

Hi

if you have your browsers set to use WinGate as proxy for https, then in order to make https requests, they use a method called tunnelling, which is where they send a CONNECT command, and basically bypass a heap of the processing of the proxy. This allows the client to negotiate SSL with the server.

In this case, the event that is pushed in WinGate is not ProxyRequest, but instead ConnectRequest.

If your browsers aren't set to use WinGate as a proxy for https, they will just use NAT to connect to servers on port 443, and you can't intercept this without creating problems (certificate warnings on the client).

Adrien