User rights and policies concerning questions and thoughts

[Alen]

First of all I want to post the questions which were answered by Adrien in another topic.

1. Citate: “By default everyone is given access to the Internet (or the appropriate services in WinGate) until restricted by policies”.
Is this because of NAT enabled, Proxies enabled and binded to internal interfaces and Guest user account enabled by default?
Is disabling Guest prevent users from accessing Internet until specially setting up for it and/or granting access? Or in case client computer has necessary settings (DG + DNS ips for NAT and Proxy address for Proxy) he wil be able to connect to the Internet even after Guest is disabled? (Everything else by default)

This is because the default policies grant access to everyone for NAT, and all proxies. So regardless of how a user connects, there have been no restrictions applied by default. You will need to edit policy to apply restrictions. We strongly recommend against disabling the Guest account, as some internal functions require it to be enabled. If you're using the Windows user database, you can disable Guest in the OS, but have it enabled in WinGate. If you don't want guest access to say a proxy, set rules to require authentication, or use groups and/or policy to specify who can use the system.
If you disable Guest, the access won't be granted to users which are using the Guest account for services. However this can have other undesired issues. You can prevent Guest account from using the WWW proxy (say) without having to disable the account. You need to make the policy not grant access to Guest.

2. How can we restrict users access to Internet connected by pure NAT connection method? Only by port filtering on firewall and websites ban?

You can also use the policies in the Extended Networking section. This allows you more control. Be aware however, that the connection is reported to WinGate after the first packet has been sent through. WinGate then evaluates the policy and decides if the connection can be allowed to live. If policy blocks the connection, the connection is terminated. This means there can be the odd packet sneak through.

3. Is it possible to use AD user database for authorizatuions, and somehow keep using PCs ip based restrictions too (like assumed users). I mean for the same users. E.g., domain user JSmith is allowed to have access to Internet, but only from his PC (192.168.0.11). How can this be done on Wingate?

You need to decide whether the users will authenticate, or be assumed. You can set up policy so that an authenticated user can only access from a certain IP, by setting their IP in the locations tab for the policy that applies only to that user. You would need to set up a policy for each user for this though, or at least for each user that you wish to control in this way.

[Alen]

Reading help further I discover ;-) the following:
1. All access methods in Wingate (NAT, Proxy and WGIC) are introduced and working as services, particularly: WRS for WGIC method, NAT method as part of ENS service and Proxies as user services.
2. As is known from documentation in Wingate we have System Policy (also called Default rights) and Services Policies, which can be mixed to get desired results of access rights and restrictions. Important is that default System policy is Everyone “Can access services” with “User may be unknown” option, all other services (including Proxies, WRS and NAT (!), which is part of ENS) have no rights assigned to any user, but have Default rights = May be used instead. Plus all services by default have binding policy, which automatically binds services to all internal network interfaces!
3. If you delete from System policies Everyone “Can access services” you will not be able to access RCS service used by Gatekeeper for Wingate configuration.
4. The address *.*.*.* corresponds to assumed user Guest (!) and this user by default is a member of Wingate built-in Users group!
5. Qbic says you should not disable Guest account:

“We strongly recommend against disabling the Guest account, as some internal functions require it to be enabled”

.

Consequences:
=> By default All users, including unknown will have access to Internet (they just need to make necessary settings or instal WGIC).

=> Even if you set “User may be assumed” in the default System policy instead of “User may be unknown”, Guest account (which includes any anknown user) will still be granted access to all the services!!! Moreover, even if you also change recipient in the default policy from Everyone to Users group - Guest will still preserve his rights!

=> If you want to make default settings to deny all users (except Wingate Admin) any access untill specifically granted, then you can try any of the following recepts:
- Delete the default right “Can access services” for Everyone from System policies (by previously adding such right for Administrators group. Nevertheless all services have Default rights option “May be used instead”, as they do not contain any rights for any recipients yet, the effective right will be only for Administrators - “Can access services”, i.e. they will be able to access all services.). Or
- Delete Guest account (which is not recommended by Qbic). Or
- Keep the default System policy, but change its authentication requirement to “User must be authenticated”. Or
- Keep the default policy, but in all enabled services policies change Default rights option to “MUST also be granted” from the default “May be used instead” (The issue with Administrators is also actual in this case. – You should grant them necessary rights for RCS and GDP services).
- Keep the default policy, but change binding policies for all enabled services to unbind all interfaces (except Local Loop for RCS and GDP services at least).

Obviously it’s possible to think out even some more variants, but these ones are the fastest (especially first three of them).

I think I’ll choose the first one may be with addition of changing all enabled services’ policies Default rights option to “MUST also be granted” instead of “May be used instead”. Then I’ll start granting specific users and groups required rights, and I am going not to use “Users” built-in group, which contain Guest account.
After removing default rights it is time to grant necessary rights to appropriate users. There are also many ways to grant users who have no rights specific access rights.

[Alen]

Here is the way I am going to go (I am going to use Assumed users mode with making assumptions by users’ machine ip. Later I’ll migrate to AD user DB).

1. Default rights removal.
As was said previously, first of all I’ll take default rights from Everyone by deleting the default right “Can access services” from System policies, then disable\delete all unnecessary services and change all enabled (= necessary) services’ policies Default rights option to “MUST also be granted” instead of “May be used instead” (while previously adding “Can access services” right in System policies and “Can access this service” in RCS and GDP policies with “User must be authenticated” option for the Administrators group).
Thus I’ll delete all users rights and only grant the right for Administrators to use Gatekeeper for Wingate control and configuration.

2. Users and Groups creation
I’ll create required user accounts and groups, then create main user group “MyGroup” and place there all my newly created specific user groups and separate users.

3. Access granting
In the System policy for the main MyGroup group I’ll add a right “Can access services” with “User may be assumed” option.
In every required Service policy I’ll add the right for all required user groups (or the whole MyGroup where needed) with “User may be assumed” option.
(Reminder notes:
Default rights option is set to “MUST also be granted” in all services.
All my user groups are included into “MyGroup“ main user group).

Note: It is also a normal way to do not use an additional step with granting to MyGroup the right in the System policy and simply directly add to every Service (that we need) the policy right for all necessary user groups with “User may be assumed” option and Default rights option “May be used instead”. But the above mentioned way is better as I can set general ban and other common restrictions and terms for all my users at once in the System policy.

Note: For users whose applications do not work via Proxy I’ll grant the right “Users can access this service” in ENS service policy and they will use NAT.
Obviously, I also should not enable Transparent proxy option in user services!?

Please give your comments to above described rights assignment algorithm.

Last edited by Alen on Nov 15 09 5:26 am, edited 1 time in total.

[Alen]

Additional questions:

1. If I run Gatekeeper from the remote PC and authorize as Admin, then access the Internet, will I get Wingate Admin rights or the appropriate assumed user rights according to my PC ip in my above described scenario (Wingate user DB, No authentication with assumed users)?

2. If I have “User may be assumed” already choosen in System policy for a group and Default rights option is set to “MUST also be granted” in a service settings, is it important what to choose in the service policy rights for the same recipient: “User may be unknown” or “User may be assumed”? As I understand, it does not matter, user has to be assumed as it is required by the System policy, which must also be satisfied!?

3. You mentioned that (Wingate’s) Guest user account should not be disabled. What if delete it from Users built-in group?

4. I Need a user, with “read only” rights for security officer, who have to be able to monitor current activities (=> access Gatekeeper -> Activity and Firewall tabs), plus it is desirable for SO to see all (security related) Wingate options, but this is not so necessary. What can be done?
I mention one System policy right: “Users can monitor activity on this server”. Is this what I need?

[adrien]

2. As is known from documentation in Wingate we have System Policy (also called Default rights) and Services Policies, which can be mixed to get desired results of access rights and restrictions. Important is that default System policy is Everyone “Can access services” with “User may be unknown” option, all other services (including Proxies, WRS and NAT (!), which is part of ENS) have no rights assigned to any user, but have Default rights = May be used instead. Plus all services by default have binding policy, which automatically binds services to all internal network interfaces!
3. If you delete from System policies Everyone “Can access services” you will not be able to access RCS service used by Gatekeeper for Wingate configuration.

Actually for the Remote Control Service, we manually specify a policy to avoid this situation, otherwise when people edit the default policy they can lock themselves out of GateKeeper.

4. The address *.*.*.* corresponds to assumed user Guest (!) and this user by default is a member of Wingate built-in Users group!
5. Qbic says you should not disable Guest account:

“We strongly recommend against disabling the Guest account, as some internal functions require it to be enabled”

.

Consequences:
=> By default All users, including unknown will have access to Internet (they just need to make necessary settings or instal WGIC).

Correct - this is by design. We find most customers want to allow access to users on their network without having to perform additional tasks after installation. So this is the default.

=> Even if you set “User may be assumed” in the default System policy instead of “User may be unknown”, Guest account (which includes any anknown user) will still be granted access to all the services!!!

This should not be the case. There are 3 levels in WinGate. Unknown (default, user Guest), Assumed (either by manual IP assumption, or by using an insecure auth method, or cached from a previous authentication session), and Authenticated.

So, when someone connects, yes the username showing will be Guest, but they should not have access to rights that require the user to be assumed.

Moreover, even if you also change recipient in the default policy from Everyone to Users group - Guest will still preserve his rights!

That's because Guest is a member of Users, so doing anything else would be incorrect. I'm pretty sure you can remove Guest from Users without any problems.

=> If you want to make default settings to deny all users (except Wingate Admin) any access untill specifically granted, then you can try any of the following recepts:
- Delete the default right “Can access services” for Everyone from System policies (by previously adding such right for Administrators group. Nevertheless all services have Default rights option “May be used instead”, as they do not contain any rights for any recipients yet, the effective right will be only for Administrators - “Can access services”, i.e. they will be able to access all services.).

Actually no, if you delete all the recipients of the default rights, and have no other grants of rights in any service, then nobody (not even Administrators) will get access. WinGate doesn't grant rights unless there's a configured policy to do so.

Or
- Delete Guest account (which is not recommended by Qbic). Or

You can't delete the Guest account. You can disable it, but there are problems with that.

- Keep the default System policy, but change its authentication requirement to “User must be authenticated”. Or
- Keep the default policy, but in all enabled services policies change Default rights option to “MUST also be granted” from the default “May be used instead” (The issue with Administrators is also actual in this case. – You should grant them necessary rights for RCS and GDP services).
- Keep the default policy, but change binding policies for all enabled services to unbind all interfaces (except Local Loop for RCS and GDP services at least).

Obviously it’s possible to think out even some more variants, but these ones are the fastest (especially first three of them).

So are you saying it's a problem that by default on install access is granted, and that you need to quickly shut it off?

[adrien]

Additional questions:

1. If I run Gatekeeper from the remote PC and authorize as Admin, then access the Internet, will I get Wingate Admin rights or the appropriate assumed user rights according to my PC ip in my above described scenario (Wingate user DB, No authentication with assumed users)?

WinGate caches credentials. What this means is if you establish an authenticated session from an IP address, any subsequent connection from that same IP address will be considered to be the same user. This overrides the IP-based assumptions you may have configured. We have a way to override this (for example if you're using terminal servers), by adding the source IP to the list of multi-user machines.

2. If I have “User may be assumed” already choosen in System policy for a group and Default rights option is set to “MUST also be granted” in a service settings, is it important what to choose in the service policy rights for the same recipient: “User may be unknown” or “User may be assumed”? As I understand, it does not matter, user has to be assumed as it is required by the System policy, which must also be satisfied!?

Correct.

3. You mentioned that (Wingate’s) Guest user account should not be disabled. What if delete it from Users built-in group?

Should be ok.

4. I Need a user, with “read only” rights for security officer, who have to be able to monitor current activities (=> access Gatekeeper -> Activity and Firewall tabs), plus it is desirable for SO to see all (security related) Wingate options, but this is not so necessary. What can be done?
I mention one System policy right: “Users can monitor activity on this server”. Is this what I need?

that right will allow your SO logged into WinGate with GateKeeper to see the activity of users. If you want them to be able to delete sessions, you can also grant them "User can delete sessions from this server" rights.

[Alen]

First of all thank you very much for your help, Adrien. I appreciate it.

Alen wrote:
=> Even if you set “User may be assumed” in the default System policy instead of “User may be unknown”, Guest account (which includes any anknown user) will still be granted access to all the services!!!

adrien wrote:
This should not be the case. There are 3 levels in WinGate. Unknown (default, user Guest), Assumed (either by manual IP assumption, or by using an insecure auth method, or cached from a previous authentication session), and Authenticated.

So, when someone connects, yes the username showing will be Guest, but they should not have access to rights that require the user to be assumed.

Disagree. Look, I am talking about the default System policy: Everyone “Can access services” with “User may be unknown” option. It is said in the help, that Guest is assumed with *.*.*.* address, which means any non-specified address. As Guest is a member of Everyone group and is assumed, I conclude he will preserve his access even if we switch to “User may be assumed” in the default System policy.
Moreover, with the same logic I can conclude, that as Guest is a member of Users group, anonymous (=all) users will have accesses whenever we grant rights to the Users group with “User may be assumed” option. Have'nt they?

This is important, because one could think that it is enough just to modify default System policy and change Everyone to Users and “User may be unknown” to “User may be assumed” to prevent Guest users from accessing services (as in Windows OS family Users group by default does not contain Guest or any unauthorised users).

Alen wrote:
=> If you want to make default settings to deny all users (except Wingate Admin) any access untill specifically granted, then you can try any of the following recepts:
- Delete the default right “Can access services” for Everyone from System policies (by previously adding such right for Administrators group. Nevertheless all services have Default rights option “May be used instead”, as they do not contain any rights for any recipients yet, the effective right will be only for Administrators - “Can access services”, i.e. they will be able to access all services.).

adrien wrote:
Actually no, if you delete all the recipients of the default rights, and have no other grants of rights in any service, then nobody (not even Administrators) will get access. WinGate doesn't grant rights unless there's a configured policy to do so.

Wait a moment, I have mentioned: ...by previously adding such right for Administrators group...
So everything would be ok.

Alen wrote:
Or
- Delete Guest account (which is not recommended by Qbic). Or

adrien wrote:
You can't delete the Guest account. You can disable it, but there are problems with that.

Sorry, I meant "Disable", of course.

So are you saying it's a problem that by default on install access is granted, and that you need to quickly shut it off?

Exactly! Yes, that is the problem.
Today, when even MS started to think about security ;-) and disables\does not install non-necessary services, does not grant unnecessary rights to users by default as it was in the past, it is strange to see such an approach in a security providing system.
I think this is wrong for such program, unless it is positioned at first as Internet sharing tool, but not security system, or is positioned for SOHO users. I don't know, may be it is positioned for SOHO segment and it was my mistake to choose it for company needs...

But yes, as best practices says, better to deny access for all and then grant only required access to only required persons. So this is my target.

[Alen]

Two small additional comments:
1. If someone leaves "User may be unknown" option in any policy then it is useless to choose specific user or group as recipient of that policy, as the effective recipient will be Everyone!
This is obvious, but not mentioned with "right" words in the help. It should be writtent by large red font as caution. :-)
2. In fact the option (could be found in all services Policy tab) Default rights = "Are ignored" is more secure than "May be used instead"! Don't look at their succession in drop down window, the criterion there is not security, but just common logic:
Only this one (Are ignored) - Any of the two (May be used instead) - Both of them (Must also be granted).
If we choose security as succession criterion we get this succession:
May be used instead - Are ignored - Must also be granted.


A question:
When by mistake the rights for RCS is deleted, but the binding to Local Loop for that service is in place, isn't it possible for Admin to login into Wingate locally on the server?

About the most important of my questions concerning my config algorithm: I have revised it and I''ll post it later for your comments. Has an issue with NAT, I'll ask questions in my adjacent topic.

[adrien]

Disagree. Look, I am talking about the default System policy: Everyone “Can access services” with “User may be unknown” option. It is said in the help, that Guest is assumed with *.*.*.* address, which means any non-specified address. As Guest is a member of Everyone group and is assumed, I conclude he will preserve his access even if we switch to “User may be assumed” in the default System policy.
Moreover, with the same logic I can conclude, that as Guest is a member of Users group, anonymous (=all) users will have accesses whenever we grant rights to the Users group with “User may be assumed” option. Have'nt they?

If the help file says that it is wrong. Unless you manually enter an assumption where * maps to Guest, then when an unknown user connects, they are Guest, but unknown, not assumed level, so won't be granted rights by a policy that only grants rights if the user is assumed or better. Last time I checked this was the case, but if it's not currently the case in your testing, that's a bug.

This is important, because one could think that it is enough just to modify default System policy and change Everyone to Users and “User may be unknown” to “User may be assumed” to prevent Guest users from accessing services (as in Windows OS family Users group by default does not contain Guest or any unauthorised users).

that's how it is intended to work.

Exactly! Yes, that is the problem.
Today, when even MS started to think about security ;-) and disables\does not install non-necessary services, does not grant unnecessary rights to users by default as it was in the past, it is strange to see such an approach in a security providing system.
I think this is wrong for such program, unless it is positioned at first as Internet sharing tool, but not security system, or is positioned for SOHO users. I don't know, may be it is positioned for SOHO segment and it was my mistake to choose it for company needs...

But yes, as best practices says, better to deny access for all and then grant only required access to only required persons. So this is my target.

we haven't had any other complaints about that, but we have had many complaints when people can't get access working, whether they are home users, or corporates. By default we only grant access to the internal networks, which is 99.9% of the time what customers want to do. So we save them configuration, and more importantly learning how to configure it.

[adrien]

Two small additional comments:
1. If someone leaves "User may be unknown" option in any policy then it is useless to choose specific user or group as recipient of that policy, as the effective recipient will be Everyone!
This is obvious, but not mentioned with "right" words in the help. It should be writtent by large red font as caution. :-)

fair enough

2. In fact the option (could be found in all services Policy tab) Default rights = "Are ignored" is more secure than "May be used instead"! Don't look at their succession in drop down window, the criterion there is not security, but just common logic:
Only this one (Are ignored) - Any of the two (May be used instead) - Both of them (Must also be granted).
If we choose security as succession criterion we get this succession:
May be used instead - Are ignored - Must also be granted.

Sorry, I'm missing your point - are you saying the sequence of options in the drop-list is illogical?

A question:
When by mistake the rights for RCS is deleted, but the binding to Local Loop for that service is in place, isn't it possible for Admin to login into Wingate locally on the server?

If you delete all the rights to access the RCS, it's unavailable until you re-add some rights. The easiest way (actually possibly the only way unless you have a config backup) to do this is a reg hack.

1. Stop the service
2. Delete the key HKLM\Software\Qbik Software\WinGate\Services\Remote Control Service
3. Start the service again - it will recreate a new RCS with default permissions.

Regards

Adrien

[Alen]

If the help file says that it is wrong.

Here is the exact citate (may be I understand it incorrectly, I am not sure.):

Notes:
 Only WinGate DHCP clients can use computer name-based assumptions.
 When you set up IP assumptions (locations) you can use the wild card * to mean ‘any’.
 IP Assumptions are read from the top down. They will associate with the first match.
e.g.:
192.168.0.1 john
192.168.0.3 alf
192.168.*.* fred
192.168.0.* cilla
The problem here is that Cilla will never be reached because line 3 - fred, covers anything that is not 192.168.0.1 or 192.168.0.3.

If Cilla was promoted like this:
192.168.0.1 john
192.168.0.3 alf
192.168.0.* cilla
192.168.*.* fred
Then Cilla would be assumed for any connection from the 192.168.0.* range of IPs except 192.168.0.1 and 192.168.0.3, and if someone connected from the IP address 192.168.1.12, it would be associated with Fred.
There is an implicit assumption of *.*.*.* ? Guest, as anyone who has not logged in, and has no assumption, is in fact a Guest. This is logically at the bottom of the list, as it will associate with any IP.

that's how it is intended to work.

Of course. I am just saying it differs from what we are accustomed as Windows OS users (begining from XP MS even does not include Anonymous into Everyone by default. In Wingate the role of Anonymous is playing Guest, which is not just a member of Everyone, which is quite logical though, but even "Users" group). Just unusual for me. And in my Wingate conspect ;-) I mark this fact as important.

we haven't had any other complaints about that, but we have had many complaints when people can't get access working, whether they are home users, or corporates. By default we only grant access to the internal networks, which is 99.9% of the time what customers want to do. So we save them configuration, and more importantly learning how to configure it.

Let me wrote some notes on the marked part as offtopic.
If admin and/or security officer are deploying security system without previously and totally learning its features, nuances (like I found for me in Wingate) and configuration tricks they should be fired. This is my principal position, and I am uncompromising here. Myself I read the whole help file of Wingate once and wrote a conspect. Now I am reading my conspect and clarifying ALL unclear questions. This takes about 2 months from me (because I have too much work and I am reading mainly in my free time) and I have not have a single thought to deploy it without being fully ready for it. And this is the only way for responsible and professional staff. IMHO. (The way of samurai ;-)).
Anyway, I don't want to dispute on the defaults you choose. You decide. I just like and is accustomed with the approach of no rights by default, only for Admin to configure (if we talk about security or financial systems, not internal standard application server)...

Sorry, I'm missing your point - are you saying the sequence of options in the drop-list is illogical?

No, not of course. I am saying, that for my opinion their sequence logic is not based on the security level they provide, because Default rights = "Are ignored" is more secure than "May be used instead". That's all.


Depending the RCS service, I was just asking, is it necessary to use this service, when you try to login locally!? To all appearances it is necessary (regardless it is called Remote CS).

[adrien]

If the help file says that it is wrong.

Here is the exact citate (may be I understand it incorrectly, I am not sure.):

Notes:
 Only WinGate DHCP clients can use computer name-based assumptions.
 When you set up IP assumptions (locations) you can use the wild card * to mean ‘any’.
 IP Assumptions are read from the top down. They will associate with the first match.
e.g.:
192.168.0.1 john
192.168.0.3 alf
192.168.*.* fred
192.168.0.* cilla
The problem here is that Cilla will never be reached because line 3 - fred, covers anything that is not 192.168.0.1 or 192.168.0.3.

If Cilla was promoted like this:
192.168.0.1 john
192.168.0.3 alf
192.168.0.* cilla
192.168.*.* fred
Then Cilla would be assumed for any connection from the 192.168.0.* range of IPs except 192.168.0.1 and 192.168.0.3, and if someone connected from the IP address 192.168.1.12, it would be associated with Fred.
There is an implicit assumption of *.*.*.* ? Guest, as anyone who has not logged in, and has no assumption, is in fact a Guest. This is logically at the bottom of the list, as it will associate with any IP.

OK, I can see what the help file is getting at, but the key point to remember is that even though we consider any unknown user to be "Guest", they don't get the elevated security privileges associated with being "assumed". They are still considered unknown.

I think this was written to demonstrate the importance of order in the assumptions, since we traverse the list from top to bottom, and break on the first match.

that's how it is intended to work.

Of course. I am just saying it differs from what we are accustomed as Windows OS users (begining from XP MS even does not include Anonymous into Everyone by default. In Wingate the role of Anonymous is playing Guest, which is not just a member of Everyone, which is quite logical though, but even "Users" group). Just unusual for me. And in my Wingate conspect ;-) I mark this fact as important.

sure, no problem. The WinGate code in this area predates Windows 98, and of course we have to maintain a certain level of backward-compatibility.

we haven't had any other complaints about that, but we have had many complaints when people can't get access working, whether they are home users, or corporates. By default we only grant access to the internal networks, which is 99.9% of the time what customers want to do. So we save them configuration, and more importantly learning how to configure it.

Let me wrote some notes on the marked part as offtopic.
If admin and/or security officer are deploying security system without previously and totally learning its features, nuances (like I found for me in Wingate) and configuration tricks they should be fired. This is my principal position, and I am uncompromising here. Myself I read the whole help file of Wingate once and wrote a conspect. Now I am reading my conspect and clarifying ALL unclear questions. This takes about 2 months from me (because I have too much work and I am reading mainly in my free time) and I have not have a single thought to deploy it without being fully ready for it. And this is the only way for responsible and professional staff. IMHO. (The way of samurai ;-)).
Anyway, I don't want to dispute on the defaults you choose. You decide. I just like and is accustomed with the approach of no rights by default, only for Admin to configure (if we talk about security or financial systems, not internal standard application server)...

Don't get me wrong - I think it's great you are spending so much time researching first. It's a big help file though. I'd also recommend setting up a test rig though, because some of these things can be clarified quickly with a test where the help file may not be clear.

Sorry, I'm missing your point - are you saying the sequence of options in the drop-list is illogical?

No, not of course. I am saying, that for my opinion their sequence logic is not based on the security level they provide, because Default rights = "Are ignored" is more secure than "May be used instead". That's all.

I kinda see your point, but actually no method is any more secure than any other. They are just different methods of combining the policy logic. The security comes down to the actual logic in the end.

Since our policy system is a system of granting access (rather than denying it), the "may be used instead" can be used to grant access in a service where it wouldn't otherwise be granted by system policy. So it's a convenience thing.

Depending the RCS service, I was just asking, is it necessary to use this service, when you try to login locally!? To all appearances it is necessary (regardless it is called Remote CS).

Whether GateKeeper is on the same machine as WinGate or not, it connects to the Remote Control Service using TCP. There's no point in duplicating all that work (communication between GateKeeper and WinGate) for some other inter-process communication method just if we're on the same machine. As far as WinGate is concerned the connection is coming from somewhere which may be remote, hence the name.

So yes, you do need it always, which is why

* it can't be deleted
* if you clear all the bindings and restart, it will recreate bindings

Adrien

[Alen]

OK, I can see what the help file is getting at, but the key point to remember is that even though we consider any unknown user to be "Guest", they don't get the elevated security privileges associated with being "assumed". They are still considered unknown.

Ok, clear. This means Guest is not an assumed user and if we choose "User may be assumed" Guest is excluded from users who pretend to the rights.
But one question still is not clear: if the same time Guest is a member of the Users group, then what will happen if we grant rights to that group, but with "User may be assumed" option?
Any answer here will be partially illogical. ;-)

Don't get me wrong - I think it's great you are spending so much time researching first. It's a big help file though. I'd also recommend setting up a test rig though, because some of these things can be clarified quickly with a test where the help file may not be clear.

Oh-hh, yes. It was very difficult to understand and push into head many things I was reading about without seeing it (I needed more pictures in the help ;-)). Finally only a week ago I just was have to install and activate a trial version at my office PC to be able to understand policies and bandwidth control...

I kinda see your point, but actually no method is any more secure than any other. They are just different methods of combining the policy logic. The security comes down to the actual logic in the end.

Since our policy system is a system of granting access (rather than denying it), the "may be used instead" can be used to grant access in a service where it wouldn't otherwise be granted by system policy. So it's a convenience thing.

I can't agree (may be very little), because unambiguously "MUST also be granted" is always more secure than two others.
What about "Are ignored" vs "May be used instead", in most cases the first would be more secure (i.e. grants less rights) as the second preserves all rights granted by service policy and adds rights from the System policy. The only case when this could be wrong is when we grant the same access right by two policies (System and service) and System policy additionally contains restrictions (say) on the right allowed usage time.
I am not sure, but I expect effective right here will restrict right usage time!?
If not, then "Are ignored" is always safer => I was fully right. ;-)

So it's a convenience thing.

Indeed, it is. No doubt. (But I will never use it, because one day I can forget its consequences and accidentally grant users surplus rights. For me "MUST also be granted" is the best variant: make common restrictions in System policy, then service specific - in service policy. Just mentioned, I am talking rather about restrictions, than rights granting. Bad man :-)).

So yes, you do need it always, which is why
* it can't be deleted
* if you clear all the bindings and restart, it will recreate bindings

Talents will find the way: remove rights for service access and bingo...

[Alen]

I am reading about filters and criterions in Ban and Advanced tabs of the Recipient properties. Have 2 questions:
1. What is the difference between these two tabs? As I understand the first is convenient for creating bans (black list), the second - permissions (white list). The same time as I can understand, only one can be used for both tasks, it's just a matter of convenience. Is it? Or there are also important differences between them?
2. If a filter contains two criterions for only one of which “Criterion is NOT met if” option is chosen, then will the filter come into force in the case of at least one criterion is satisfied =>
Any case, which satisfy to the terms set for “Criterion is met if” and\or
Any case, except that which satisfy to the terms set for “Criterion is NOT met if”?

[adrien]

OK, I can see what the help file is getting at, but the key point to remember is that even though we consider any unknown user to be "Guest", they don't get the elevated security privileges associated with being "assumed". They are still considered unknown.

Ok, clear. This means Guest is not an assumed user and if we choose "User may be assumed" Guest is excluded from users who pretend to the rights.
But one question still is not clear: if the same time Guest is a member of the Users group, then what will happen if we grant rights to that group, but with "User may be assumed" option?
Any answer here will be partially illogical. ;-)

The policy (we call it a recipient, since it is a configuration of a granting of rights to a user/group/everyone) works by checking a bunch of things in sequence.

First, if it's not set to Everybody, it checks that the user of the session matches (either is, or is a member of) the user/group specified.
Then it checks if the session has the required security level.

So, your unknown Guest will still fail policy if your policy only grants access to users assumed or higher.

It is actually possible to have Guest be elevated above unknown, but it requires either

a) the user Guest to be assigned a password, and someone actually authenticate with the username Guest and the password.
b) if you set up an assumed user and assign it to Guest I think it becomes assumed.

[adrien]

I am reading about filters and criterions in Ban and Advanced tabs of the Recipient properties. Have 2 questions:
1. What is the difference between these two tabs? As I understand the first is convenient for creating bans (black list), the second - permissions (white list). The same time as I can understand, only one can be used for both tasks, it's just a matter of convenience. Is it? Or there are also important differences between them?
2. If a filter contains two criterions for only one of which “Criterion is NOT met if” option is chosen, then will the filter come into force in the case of at least one criterion is satisfied =>
Any case, which satisfy to the terms set for “Criterion is met if” and\or
Any case, except that which satisfy to the terms set for “Criterion is NOT met if”?

Actually both tabs are used. You can set policy to use the banlist and also the advanced tab.

The ban-list is a list of exclusions from granting the right. What this means is that if the request matches ANY entry in the banlist, the right won't be granted by that policy.

The advanced tab (if you use it) must match in order to grant rights. The structure of policy with the advanced tab is that

ANY filter can match to grant rights (filters are ORed)
ALL criteria in a filter must match for the filter to match (criteria are ANDed)

You're going to hate me when WinGate 7 comes out, it's a completely different policy system (user-defined flow-chart decision tree)

Regards

Adrien

[Alen]

So, your unknown Guest will still fail policy if your policy only grants access to users assumed or higher.

It is actually possible to have Guest be elevated above unknown, but it requires either

a) the user Guest to be assigned a password, and someone actually authenticate with the username Guest and the password.
b) if you set up an assumed user and assign it to Guest I think it becomes assumed.

Ok, clear now.
Thus the answer on the question: "if the same time Guest is a member of the Users group, then what will happen if we grant rights to that group, but with "User may be assumed" option?" - is: "Guest will not get any access if additional actions for it were not done".
Question is closed finally. Thank you.

The ban-list is a list of exclusions from granting the right.

So it is used to create black lists. Ok.

What this means is that if the request matches ANY entry in the banlist, the right won't be granted by that policy.

Let's call things by their names (you make it difficult to understand when use common terms or phrases): entry here is a filter!? => If the request matches ANY filter in the banlist, the right won't be granted by that policy!
Ok, clear.

The advanced tab (if you use it) must match in order to grant rights.

So this is used to create white lists. And to make full analogy with the Ban list definition you gave it's better to say: The Advanced tab is a list of permissions for granting the right.
I think it's even better to say:
Ban tab is a tool to create exclusions from granting the rights, while Advanced tab is a tool to create permissions for granting the right.
Sorry for my annoyance.

The structure of policy with the advanced tab is that
ANY filter can match to grant rights (filters are ORed)
ALL criteria in a filter must match for the filter to match (criteria are ANDed)

Clear.

Now please check this small text I wrote for myself to quickly switch to Wingate logic in future (it's just a part of the whole text):

1. All access methods in Wingate (NAT, Proxy and WGIC) are introduced and working as services, particularly: WRS for WGIC method, NAT method as part of ENS service and Proxies as user services.
2. For users to connect to the Internet we have to assign to a recipient (user or group) a right to access a specific service(s) in the Service policy or all services in System policy (effective rights depend on the option “Default Right” found for each service policy window). Then we can set conditions on which recipient will use the right in the recipient properties window: allowed or forbidden location from where recipient is trying to use the right (Location), time right is granted or taken (Time tab), sites and servers allowed or forbidden under certain circumstances which depend on the filters (i.e. rules) created (Ban and Advanced tabs).
Each filters contains one or more criterions. Essentially, all filters in a policy are joined with Boolean/conditional ORs. This means that if either filter evaluates to true, then the activity is restricted/allowed (depending on how you have configured it). On the other hand, the rules criterion within filters are joined with Boolean/conditional ANDs, which means that they must all evaluate to true for the specific filter to apply.
In criterions you use variables. The variable type determines what comparisons you can make with that variable: if the variable is a number, you can check whether a number you specify is greater than, less than, or equal to the variable you select; and if the variable is a string then you can apply comparisons such as "contains", "begins with", "ends with" or is "empty".
A right in Advanced tab is granted or prohibition in Ban tab is applied if at least one of its rules (filters) comes into force.
A rule comes into force if all of its criterions are satisfied at once.
Note: If “Criterion is NOT met if” option is chosen, then the criterion is satisfied in all cases except those which satisfy to the term set for the option.

Is this correct?

P.S. I am happy you answered my questions the same day this time (I have only 3 days till deployment and waiting a whole day for answers is very "expensive" for me...)

[Alen]

Adrien
I have just mentioned I could be wrong with understanding of your:

What this means is that if the request matches ANY entry in the banlist, the right won't be granted by that policy.

Does "entry" here equal to filter or criterion? I was thinking about filter, but now I am not sure it is right. Please pay high attention to the sentences marked with bold font.

Thank you.

[adrien]

The ban-list is a list of exclusions from granting the right.

So it is used to create black lists. Ok.

Yes, but the thing to remember is it's a blacklist only for that particular recipient. If there are multiple recipients defined in policy (e.g multiple entries in a proxy service under "user can access services"), then if any grants access to a request, it will be granted. Therefore the recipients aren't all necessarily independent.

What this means is that if the request matches ANY entry in the banlist, the right won't be granted by that policy.

Let's call things by their names (you make it difficult to understand when use common terms or phrases): entry here is a filter!? => If the request matches ANY filter in the banlist, the right won't be granted by that policy!
Ok, clear.

Actually in code, the object we use to provide the entire banlist is a filter object, and each item you see in the banlist UI is a criterion. The filter is evaluated differently from filters in the advanced tab though in that criteria are ORed for the banlist filter to match, and right is not granted if banlist filter matches.

But I think you understand

The advanced tab (if you use it) must match in order to grant rights.

So this is used to create white lists. And to make full analogy with the Ban list definition you gave it's better to say: The Advanced tab is a list of permissions for granting the right.
I think it's even better to say:
Ban tab is a tool to create exclusions from granting the rights, while Advanced tab is a tool to create permissions for granting the right.
Sorry for my annoyance.

No problem. I would instead write that

The Advanced tab is a tool to place further constraints on the granting of access using parameters that are not available under the other tabs (e.g time, user, security level, location) such as user account details, http headers (if applicable), whether the connection was intercepted etc.

The structure of policy with the advanced tab is that
ANY filter can match to grant rights (filters are ORed)
ALL criteria in a filter must match for the filter to match (criteria are ANDed)

Clear.

Now please check this small text I wrote for myself to quickly switch to Wingate logic in future (it's just a part of the whole text):

1. All access methods in Wingate (NAT, Proxy and WGIC) are introduced and working as services, particularly: WRS for WGIC method, NAT method as part of ENS service and Proxies as user services.
2. For users to connect to the Internet we have to assign to a recipient (user or group) a right to access a specific service(s) in the Service policy or all services in System policy (effective rights depend on the option “Default Right” found for each service policy window). Then we can set conditions on which recipient will use the right in the recipient properties window: allowed or forbidden location from where recipient is trying to use the right (Location), time right is granted or taken (Time tab), sites and servers allowed or forbidden under certain circumstances which depend on the filters (i.e. rules) created (Ban and Advanced tabs).
Each filters contains one or more criterions. Essentially, all filters in a policy are joined with Boolean/conditional ORs. This means that if either filter evaluates to true, then the activity is restricted/allowed (depending on how you have configured it). On the other hand, the rules criterion within filters are joined with Boolean/conditional ANDs, which means that they must all evaluate to true for the specific filter to apply.
In criterions you use variables. The variable type determines what comparisons you can make with that variable: if the variable is a number, you can check whether a number you specify is greater than, less than, or equal to the variable you select; and if the variable is a string then you can apply comparisons such as "contains", "begins with", "ends with" or is "empty".
A right in Advanced tab is granted or prohibition in Ban tab is applied if at least one of its rules (filters) comes into force.
A rule comes into force if all of its criterions are satisfied at once.
Note: If “Criterion is NOT met if” option is chosen, then the criterion is satisfied in all cases except those which satisfy to the term set for the option.

Is this correct?

P.S. I am happy you answered my questions the same day this time (I have only 3 days till deployment and waiting a whole day for answers is very "expensive" for me...)

Looks good to me... I must get you to write the next WinGate helpfile :)

[Alen]

the thing to remember is it's a blacklist only for that particular recipient. If there are multiple recipients defined in policy (e.g multiple entries in a proxy service under "user can access services"), then if any grants access to a request, it will be granted. Therefore the recipients aren't all necessarily independent.

This clear.
But the last sentence gave birth to a new question: if we have restricted rights for a recipient, but we have the same rights unrestricted (let's suppose for example) for another recipient - group, which contains the first recipient. What will be the effective rights for the first recipient?
I hope restricted right!?

And if multiple restrictions for the same rights exists for the same recipient (through his "parents") do all restriction work on him?

The filter is evaluated differently from filters in the advanced tab though in that criteria are ORed for the banlist filter to match, and right is not granted if banlist filter matches.

But I think you understand

No Adrien, I didn't, but I was beware of it, that's why I asked you to pay high attention to the marked sentences. Now I have to change it to this (the second sentence was changed):
A right in Advanced tab is granted or prohibition in Ban tab is applied if at least one of its rules (filters) comes into force.
A rule of Ban tab (filter, which is not visible in Ban tab) can contain only one criterion and thus comes into force anyway, while for Advanced tab whcih has not such limitation it comes into force if all of its criterions are satisfied at once.

Note to correction: In fact there are no filters found in the Ban tab, only criterions. But logically there are "invisible" filters there (it's convenient to think so to preserve the common logic), which contain only one criterion. And thus any criterion in the Ban tab belongs to its individual filter!
=> As in Wingate filters are joined with logical OR, criterions in the Ban tab are also joined with logical OR (and the reason of this is simply the fact each of them belongs to a different filter!)!

Last edited by Alen on Nov 23 09 11:09 pm, edited 1 time in total.

[Alen]

I must get you to write the next WinGate helpfile :)

Thanks for your trust. I think you'll be fully satisfied with the quality, but not time spent for it ;-).

[adrien]

the thing to remember is it's a blacklist only for that particular recipient. If there are multiple recipients defined in policy (e.g multiple entries in a proxy service under "user can access services"), then if any grants access to a request, it will be granted. Therefore the recipients aren't all necessarily independent.

This clear.
But the last sentence gave birth to a new question: if we have restricted rights for a recipient, but we have the same rights unrestricted (let's suppose for example) for another recipient - group, which contains the first recipient. What will be the effective rights for the first recipient?
I hope restricted right!?

the restrictions don't accumulate, the grants do. Each policy you add, adds a little bit more to what users can do.

So logically all the policy definitions (need a good name for the thing you are editing when you edit "properties for recipient XXX") are ORed. If ANY grants access, then access is granted. When you think about it, it must be this way otherwise how could you have a recipient of rights for Bob, and Jim. A user cannot be both Bob and Jim.

So, if you had say a definition for each of your users individually, and had all the things they could do specified, and then you added another one for Everyone can do anything, then this would then grant access to everyone for anything.

It does make it a bit trickier sometimes to figure out the complete policy logic. this is another reason why we re-wrote policy in WinGate 7. You might like to take a look at that (let me know - we are close to beta, but some customers are already running it even in production). It solves issues such as

* change management of policy (you assign policy to events, so you can swap between policies for say web access control, test, swap back out) You can even use the WinGate scheduler to swap active policy.
* sharing of policy between services
* re-usable sub-policy. So you can create a library of policy functionality and re-use it throughout your entire policy
* profiling - you can measure the impact of policy changes on performance
* debugging.
* specific rejection messages for any reason for blocking. So a user / admin can know WHY and exactly where in policy someone was blocked.

it's basically a visual development environment for handling web proxy (and other WinGate) events. So you can do not only access control with it, but also take actions (e.g. launch other apps, write to DB, execute some function on a COM object), or change configuration for a particular request (e.g. set gateway per request, based on who, when, what etc). It's extremely flexible and powerful.

It also has a HTTP/1.1 compatible cache using ODBC for the index. We have clocked WinGate on my dev machine here serving over 4000 files/sec solidly without any problem using a remote MySQL server for cache index. We measured this with WinGate's built-in metering showing in dials on WinGate's dashboard. Anyway, enough about WinGate 7.

And if multiple restrictions for the same rights exists for the same recipient (through his "parents") do all restriction work on him?

The filter is evaluated differently from filters in the advanced tab though in that criteria are ORed for the banlist filter to match, and right is not granted if banlist filter matches.

But I think you understand

No Adrien, I didn't, but I was beware of it, that's why I asked you to pay high attention to the marked sentences. Now I have to change it to this (the second sentence was changed):
A right in Advanced tab is granted or prohibition in Ban tab is applied if at least one of its rules (filters) comes into force.
A rule (filter) of Ban tab comes into force if any of its criterions are satisfied, while for Advanced tab it comes into force if all of its criterions are satisfied at once.

OK

[Alen]

the restrictions don't accumulate, the grants do. Each policy you add, adds a little bit more to what users can do.

Ok, let's write this way:
If a user is recipient (through membership in different groups) of many “instances” for the same policy right, then restrictions defined in the recipient properties for all instances of the right do not accumulate, but permissions do.
Thus each new policy you add (for the existing right of some recipient), can add a little bit more to what respective users can do by extinguishing existing restrictions and never add new restrictions. Simply saying: in Wingate permission overwrites restriction.
But, wait a moment, it is hard to believe it.
Let's suppose a user, member of the Users group has a personal right to use web proxy and the only restriction is http://www.ms.com banned. Then we create new policy and grant Users group a right to use web proxy with the only restriction: http://www.int.com banned.
What we get as resulting policy for the user? He can go everywhere or everywhere except the two sites?!

So logically all the policy definitions (need a good name for the thing you are editing when you edit "properties for recipient XXX") are ORed. If ANY grants access, then access is granted. When you think about it, it must be this way otherwise how could you have a recipient of rights for Bob, and Jim. A user cannot be both Bob and Jim.

I did not understand what you say.

But I can say that the problem obviously is again in the fact for me it's usual that "Deny" overwrites permission, but as I understand in Wingate we have reverse situation: permission overwrites restriction! And that's why we have what we have...

It does make it a bit trickier sometimes to figure out the complete policy logic. this is another reason why we re-wrote policy in WinGate 7. You might like to take a look at that

Thank's, but no, I have so much to do, you even could not believe (finish corporate network infrastructure upgrade and finally create intranet, provide branches Internet via central point - head office, finish corporate IS Policy documents "infrastructure", migrate domain to AD and include all branches into one domain, consolidate all servers in head office, create warm back-up site, deploy IP telephony over intranet and many others. And this is global tasks, I am not talking about everyday routine...
Hope i'll finish all during my life :-)).
So I hope I'll install and tune Wingate one time and then it will work stable almost without any changes for a long time (only periodical OS and Wingate updates and new users registration).


New question:
What if I make settings to allow for only assumed users to get access to the Internet and make no assumption for Wingate server ip? WIll Internet work on the Wingate machine?
What about the same situation, but immediately after Admin loges into Wingate? Or it (credentials caching) does not matter here?

[adrien]

the restrictions don't accumulate, the grants do. Each policy you add, adds a little bit more to what users can do.

Ok, let's write this way:
If a user is recipient (through membership in different groups) of many “instances” for the same policy right, then restrictions defined in the recipient properties for all instances of the right do not accumulate, but permissions do.
Thus each new policy you add (for the existing right of some recipient), can add a little bit more to what respective users can do by extinguishing existing restrictions and never add new restrictions. Simply saying: in Wingate permission overwrites restriction.
But, wait a moment, it is hard to believe it.
Let's suppose a user, member of the Users group has a personal right to use web proxy and the only restriction is http://www.ms.com banned. Then we create new policy and grant Users group a right to use web proxy with the only restriction: http://www.int.com banned.
What we get as resulting policy for the user? He can go everywhere or everywhere except the two sites?!

everywhere. I know this is counter-intuitive, but it's the only way that the current structure of the policy can work, since there are no deny policies. Thats why I suggested you take a quick look at WinGate 7. I think it could well be worth spending 30min to look at it. Many things are the same, so you don't need to relearn everything, but policy will allow you to do what you want.

So logically all the policy definitions (need a good name for the thing you are editing when you edit "properties for recipient XXX") are ORed. If ANY grants access, then access is granted. When you think about it, it must be this way otherwise how could you have a recipient of rights for Bob, and Jim. A user cannot be both Bob and Jim.

I did not understand what you say.

But I can say that the problem obviously is again in the fact for me it's usual that "Deny" overwrites permission, but as I understand in Wingate we have reverse situation: permission overwrites restriction! And that's why we have what we have...

if you think of each thing as a permission (perhaps with restrictions), with WinGate 6.x you are only adding permission. Denial results only when no permission is granted (rather than other systems which explicitly deny).

It does make it a bit trickier sometimes to figure out the complete policy logic. this is another reason why we re-wrote policy in WinGate 7. You might like to take a look at that

Thank's, but no, I have so much to do, you even could not believe (finish corporate network infrastructure upgrade and finally create intranet, provide branches Internet via central point - head office, finish corporate IS Policy documents "infrastructure", migrate domain to AD and include all branches into one domain, consolidate all servers in head office, create warm back-up site, deploy IP telephony over intranet and many others. And this is global tasks, I am not talking about everyday routine...
Hope i'll finish all during my life :-)).
So I hope I'll install and tune Wingate one time and then it will work stable almost without any changes for a long time (only periodical OS and Wingate updates and new users registration).

I understand. So you don't foresee a need to do things like maintain a whitelist of sites? This can be difficult in WinGate 6. In WinGate 7 you can have your site whitelist in a DB.

New question:
What if I make settings to allow for only assumed users to get access to the Internet and make no assumption for Wingate server ip? WIll Internet work on the Wingate machine?
What about the same situation, but immediately after Admin loges into Wingate? Or it (credentials caching) does not matter here?

Unless the software you are using is configured to connect to the proxy on the WinGate machine, then it's not restricted. It's common for instance to set the proxy configuration for the browser on the WinGate machine to locahost and go out through WinGate. In this case, it's treated like any LAN user (except it doesn't affect license count). If you log in with GateKeeper, you'll associate credentials for that IP, which will be cached.

[Alen]

if you think of each thing as a permission (perhaps with restrictions), with WinGate 6.x you are only adding permission. Denial results only when no permission is granted (rather than other systems which explicitly deny).

Agree, I see it now.

You were asking how to call Recipient properties window, I am thinking about it as about "Conditional rights": Recipient is granted rights, which are subject of some conditions (Location, Time, etc.).

I understand. So you don't foresee a need to do things like maintain a whitelist of sites? This can be difficult in WinGate 6. In WinGate 7 you can have your site whitelist in a DB.

I'll have whitelist (as you remember I want to allow NAT only for a couple of addresses and sites, which does\will not work via Proxy), and I am going to realize it as one filter in the Ban list with "This crirerion is NOT met if" type criterions with all the sites from the white list (e.g. wingate.com, ms.com).
As I understand this will mean: Ban all NOT equal to wingate.com and ms.com.
Or this will not work properly as criterions in Ban list are joined with logical OR, not AND? And the result will be only first site is allowed?

If so, then I'll use Advanced tab and create individual filters with single criterion for each white site\address. This will work for sure.

Thats why I suggested you take a quick look at WinGate 7. I think it could well be worth spending 30min to look at it. Many things are the same, so you don't need to relearn everything, but policy will allow you to do what you want.

Let me deploy 6-th first, then one sunny day, I'll look at 7-th.

Alen wrote:
New question:
What if I make settings to allow for only assumed users to get access to the Internet and make no assumption for Wingate server ip? WIll Internet work on the Wingate machine?
What about the same situation, but immediately after Admin loges into Wingate? Or it (credentials caching) does not matter here?

adrien wrote:
Unless the software you are using is configured to connect to the proxy on the WinGate machine, then it's not restricted. It's common for instance to set the proxy configuration for the browser on the WinGate machine to locahost and go out through WinGate. In this case, it's treated like any LAN user (except it doesn't affect license count). If you log in with GateKeeper, you'll associate credentials for that IP, which will be cached.

Wait a moment. All my services, including NAT will be available for use for Assumed users only, why should it work?!
I am seriously thinking about preventing Internet to work on Wingate itself by default, because my admins periodically install some apps on it, which is inadmissible for my opinion...

[Alen]

Adrien, yesterday night I went deep with filters and criterions (only logical experiment on paper, I did not try it on Wingate), and here is what I found out for Advanced tab, this is also applicable to the Cache filters (for better understanding it is supposed we are granting service access right and the recipient is Everyone group).

I looked at:
1. one filter with a couple of the same criterions: both criterions positive, both negative, mixed
2. one filter with a couple of different criterions: both criterions positive, both negative, mixed
3. two filters each with a single and of the same type criterions: both criterions positive, both negative, mixed
4. two filters each with a single, but different between each other criterions: both criterions positive, both negative, mixed.
Positive here means criterions in “Criterion is met if” kind, Negative - “Criterion is Not met if” kind.

For example, let's take 2 criterions Username equals one to Bob (Criterion X), the second to John (Criterion Y), and another criterion Session description contains wingate.com (Criterion A).
(It is supposed X neither equal, nor contains, nor is contained into Y. This is important.)

1. Filter contains two criterions of the same type:
1.1 [X and Y] = empty variety => No one will be granted the right.
1.2 [(Not X) and (Not Y)] => everyone, except Bob and John, will be granted the right.
1.3 [X and (Not Y)] = X => the right will be granted to Bob only.

2. Filter contains two criterions of different types:
2.1 [X and A] => Bob (and only him) will be granted the right to visit *wingate.com* sites only
2.2 [(Not X) and (Not A)] => Everyone, except Bob, can access everything, except *wingate.com* sites (Bob is denied everything!)
2.3 [X and (Not A)] => the right will be granted to Bob only to visit any sites, except *wingate.com* sites


3. Two filters each with one, but of the same type criterion:
3.1 [X or Y] => Bob and John both will be granted the access
3.2 [(Not X) or (Not Y)] => Everyone will get access for everything, no effective restrictions
3.3 [X or (Not Y)] = Not Y => the right will be granted to Everyone except John

Two filters each with one (but different between each other) criterions, the first - X, the second - A
4.1 [X or A] => Bob will be granted the right to visit anything, while all others *wingate.com* sites only
4.2 [(Not X) or (Not A)] => Everyone can access everything, except Bob, who cann't access *wingate.com* sites (others can) (the same result as for 2.2!?)
4.3 [X or (Not A)] => Bob is allowed everything, all others - everything, except *wingate.com* sites.


And the most important results (for when we suppose X neither equal, nor contains, nor is contained into Y):

When creating filters for a Recipient to grant him an access right:
Don’t use two or more “positive” and independent (non-overlapping) criterions of the same type in one filter! As Recipient would not be granted any access at all (by this filter)!
E.g. if you use filter with 2 criterions: “Username” equal to Bob and “Username” equal to John, then as Username can not be Bob and John simultaneously, noone will be granted the right by this filter!

Don’t use two or more “negative” and independent (non-overlapping) criterions of the same type in different filters! As Recipient would not be restricted at all by the filters and all members of the Recipient will be granted full access!
E.g. if you use 2 filters with 1 criterion in each: I - “Username” Not equal to Bob, II - “Username” Not equal to John, then every member of the respective Recipient, including both Bob and John, will be granted the right by this filters. This is because filters are applied with logical OR, and thus John will be granted the right as one of the users who satisfy to the first filter (Not Bob), and Bob – the second (not John)!

In case criterions are not independant, i.e. X contains or is contained into Y these nuances went away.

And one very usefull sentence form the help:
If you want multiple filters, but disallow some specific criterion (i.e. use "negative criterion"), make sure you include this disallowed criterion in every filter! This applies to all rules in WinGate (including rules for caching and service access)!

Last edited by Alen on Nov 23 09 10:50 pm, edited 2 times in total.

[adrien]

I'll have whitelist (as you remember I want to allow NAT only for a couple of addresses and sites, which does\will not work via Proxy), and I am going to realize it as one filter in the Ban list with "This crirerion is NOT met if" type criterions with all the sites from the white list (e.g. wingate.com, ms.com).
As I understand this will mean: Ban all NOT equal to wingate.com and ms.com.
Or this will not work properly as criterions in Ban list are joined with logical OR, not AND? And the result will be only first site is allowed?

that won't work, as the request will be blocked if

site NOT A OR
site NOT B OR
etc

since site cannot be both A and B, this will block everything.

If so, then I'll use Advanced tab and create individual filters with single criterion for each white site\address. This will work for sure.

Yes, the only way to do a whitelist is with an individual filter and criterion for each whitelisted site.

Thats why I suggested you take a quick look at WinGate 7. I think it could well be worth spending 30min to look at it. Many things are the same, so you don't need to relearn everything, but policy will allow you to do what you want.

Let me deploy 6-th first, then one sunny day, I'll look at 7-th.

Alen wrote:
New question:
What if I make settings to allow for only assumed users to get access to the Internet and make no assumption for Wingate server ip? WIll Internet work on the Wingate machine?
What about the same situation, but immediately after Admin loges into Wingate? Or it (credentials caching) does not matter here?

adrien wrote:
Unless the software you are using is configured to connect to the proxy on the WinGate machine, then it's not restricted. It's common for instance to set the proxy configuration for the browser on the WinGate machine to locahost and go out through WinGate. In this case, it's treated like any LAN user (except it doesn't affect license count). If you log in with GateKeeper, you'll associate credentials for that IP, which will be cached.

Wait a moment. All my services, including NAT will be available for use for Assumed users only, why should it work?!
I am seriously thinking about preventing Internet to work on Wingate itself by default, because my admins periodically install some apps on it, which is inadmissible for my opinion...

If you connect to localhost (127.0.0.1), this does not affect NAT, since the localhost interface is not visible to NAT / NDIS. It's implemented in a higher layer in the stack, and doesn't go down that far.

You never actually do NAT from the WinGate machine anyway, since it will always bind to the external interface to connect to the internet, and no translation is required.

[adrien]

Adrien, yesterday night I went deep with filters and criterions (only logical experiment on paper, I did not try it on Wingate), and here is what I found out for Advanced tab, this is also applicable to the Cache filters (for better understanding it is supposed we are granting service access right and the recipient is Everyone group).

I looked at:
1. one filter with a couple of the same criterions: both criterions positive, both negative, mixed
2. one filter with a couple of different criterions: both criterions positive, both negative, mixed
3. two filters each with a single and of the same type criterions: both criterions positive, both negative, mixed
4. two filters each with a single, but different between each other criterions: both criterions positive, both negative, mixed.
Positive here means criterions in “Criterion is met if” kind, Negative - “Criterion is Not met if” kind.

For example, let's take 2 criterions Username equals one to Bob (Criterion X), the second to John (Criterion Y), and another criterion Session description contains wingate.com (Criterion A).
(It is supposed X neither equal, nor contains, nor is contained into Y. This is important.)

1. Filter contains two criterions of the same type:
1.1 [X and Y] = empty variety => No one will be granted the right.
1.2 [(Not X) and (Not Y)] => everyone, except Bob and John, will be granted the right.
1.3 [X and (Not Y)] = X => the right will be granted to Bob only.

2. Filter contains two criterions of different types:
2.1 [X and A] => Bob (and only him) will be granted the right to visit *wingate.com* sites only
2.2 [(Not X) and (Not A)] => Everyone can access everything, except Bob, who cann't access *wingate.com* sites (others can)

actually others can't either. No-one can visit wingate.com if Not A is set. Bob can't go anywhere.

2.3 [X and (Not A)] => the right will be granted to Bob only to visit any sites, except *wingate.com* sites


3. Two filters each with one, but of the same type criterion:
3.1 [X or Y] => Bob and John both will be granted the access
3.2 [(Not X) or (Not Y)] => Everyone will get access for everything, no effective restrictions
3.3 [X or (Not Y)] = Not Y => the right will be granted to Everyone except John

Two filters each with one (but different between each other) criterions, the first - X, the second - A
4.1 [X or A] => Bob will be granted the right to visit anything, while all others *wingate.com* sites only
4.2 [(Not X) or (Not A)] => Everyone can access everything, except Bob, who cann't access *wingate.com* sites (others can) (the same result as for 2.2!?)
4.3 [X or (Not A)] => Bob is allowed everything, all others - everything, except *wingate.com* sites.


And the most important results (for when we suppose X neither equal, nor contains, nor is contained into Y):

When creating filters for a Recipient to grant him an access right:
Don’t use two or more “positive” and independent (non-overlapping) criterions of the same type in one filter! As Recipient would not be granted any access at all (by this filter)!
E.g. if you use filter with 2 criterions: “Username” equal to Bob and “Username” equal to John, then as Username can not be Bob and John simultaneously, noone will be granted the right by this filter!

correct. It's important to realise the logically incorrect usage of the english language. We say John AND Bob are allowed access. Really the correct logic is John OR Bob, since the check is "is the user John, or Bob? if so allow". Since the user can't be both John and Bob, requiring both makes the grant impossible to match.

Don’t use two or more “negative” and independent (non-overlapping) criterions of the same type in different filters! As Recipient would not be restricted at all by the filters and all members of the Recipient will be granted full access!
E.g. if you use 2 filters with 1 criterion in each: I - “Username” Not equal to Bob, II - “Username” Not equal to John, then every member of the respective Recipient, including both Bob and John, will be granted the right by this filters. This is because filters are applied with logical OR, and thus John will be granted the right as one of the users who satisfy to the first filter (Not Bob), and Bob – the second (not John)!

In case criterions are not independant, i.e. X contains or is contained into Y these nuances went away.

And one very usefull sentence form the help:
If you want multiple filters, but disallow some specific criterion (i.e. use "negative criterion"), make sure you include this disallowed criterion in every filter! This applies to all rules in WinGate (including rules for caching and service access)!

[Alen]

Alen wrote:
...
2. Filter contains two criterions of different types:
...
2.2 [(Not X) and (Not A)] => Everyone can access everything, except Bob, who cann't access *wingate.com* sites (others can)

adrien wrote:
actually others can't either. No-one can visit wingate.com if Not A is set. Bob can't go anywhere.

Hm-m, I can't agree.
According to what is written in help, both crireions must be satisfied simultaneously for the filter to come in force. => NOT Bob and NOT *wingate.com* criterions are satisfied simultaneously, when (let's cross to positive criterions with exceptions, which will be easier to understand) the user is anyone, except Bob and, the same time, the requested site is anything, except *wingate.com* => this is possible when the user is neither Bob nor the site is *wingate.com*! => Everyone, except Bob will be granted access to visit anything, except *wingate.com* (Bob is denied everything).

You are right, now I see it (my mystake was I was thinking about simultaneouse satisfaction of Not Bob and Not *wingate.com* conditions themselves, not Wingate criterions).
Ok, I'll correct it immediately. (But it was not obvious, I had to concentrate hard to understand you are right, and I found the crossing from negative criterion to positive with exceptions can be very helpful here!).

P.S. Adrien, this is not simple. I am strictly doubt most of Wingate users can make settings correctly (and then they will say Wingate is not secure or doesn't work properly). I think you MUST pay a great attention to proper rules setup in the help. May be even add something like I wrote here! This is necessary.

It's important to realise the logically incorrect usage of the english language. We say John AND Bob are allowed access. Really the correct logic is John OR Bob, since the check is "is the user John, or Bob? if so allow". Since the user can't be both John and Bob, requiring both makes the grant impossible to match.

Yes, and it is not the problem of only English language. The only way is to explain fully with "live" examples.

[Alen]

Alen wrote:
I'll have whitelist (as you remember I want to allow NAT only for a couple of addresses and sites, which does\will not work via Proxy), and I am going to realize it as one filter in the Ban list with "This crirerion is NOT met if" type criterions with all the sites from the white list (e.g. wingate.com, ms.com).
As I understand this will mean: Ban all NOT equal to wingate.com and ms.com.
Or this will not work properly as criterions in Ban list are joined with logical OR, not AND? And the result will be only first site is allowed?

adrien wrote:
that won't work, as the request will be blocked if
site NOT A OR
site NOT B OR
etc

since site cannot be both A and B, this will block everything.

Alen wrote: If so, then I'll use Advanced tab and create individual filters with single criterion for each white site\address. This will work for sure.

adrien wrote:
Yes, the only way to do a whitelist is with an individual filter and criterion for each whitelisted site.

Ok, clear.

But I found out one thing you did not say to me: there are no "visible" filters in the Ban list tab! Only criterions. And they are joined with logical OR (this was said).
I propose and think it is much better to count that we have invisible filters in the Ban list, and each filter can contain only one criterion (that is why they are made invisible. But in fact each criterion you see belongs to its individual filter). This will preserve the common logic. It's not good you say one thing for the Ban list tab and another for Advanced tab or Caching rules. That is my (humble ;-)) opinion.

I have changed one of my Wingate "laws" one more time, and it looks this way:

A right in Advanced tab is granted or prohibition in Ban tab is applied if at least one of its rules (filters) comes into force.
A rule of Ban tab (filter, which is not visible in Ban tab) can contain only one criterion and thus comes into force anyway, while for Advanced tab whcih has not such limitation it comes into force if all of its criterions are satisfied at once.

Note: In fact there are no filters found in the Ban tab, only criterions. But logically there are "invisible" filters there (it's convenient to think so to preserve the common logic), which contain only one criterion. And thus any criterion in the Ban tab belongs to its individual filter!
=> As in Wingate filters are joined with logical OR, criterions in the Ban tab are also joined with logical OR (and the reason of this is simply the fact each of them represents a separate filter!)!

If you connect to localhost (127.0.0.1), this does not affect NAT, since the localhost interface is not visible to NAT / NDIS. It's implemented in a higher layer in the stack, and doesn't go down that far.
You never actually do NAT from the WinGate machine anyway, since it will always bind to the external interface to connect to the internet, and no translation is required.

Right. But. In case you have not set DNS ip on WAN interface of Wingate, it will not work anyway (I understand now it should not be called NAT connection, it's just a direct connection). And as you remember, I was not going to set DNS ip on WAN interface, just in DNS Resolver settings (and after I installed and activated Wingate (YES! I did it finally, but caught one problem, so it is still not in use. See my new theme.) I remove DNS ip from the WAN interface settings). => After I finished all my settings, it was not possible to use Internet from the Wingate machine, untill I make an assumption that 192.168.200.1 is Wingate Administrator...

P.S. I think I clarify all my questions about user rights in Wingate.
Adrien, I'll say this a few times more later on (because still have another unanswered questions), but thank you very much! It was the best and most patient support I have ever met.

I just could not understand why you answer my questions at night, if we both are in UTC + 4?!

Last edited by Alen on Nov 25 09 1:33 am, edited 1 time in total.