LOG IN |  Register | 0 item(s) in your shopping cart, USD
Download and try the latest WinGate 9 free for 30 days.

Features

Active Directory integration

WinGate needs a user database in order to be able to provide user-level security etc.  In cases where the operating system that WinGate is installed on does not have a user database, WinGate has its own one.  Alternatively if the OS WinGate is installed on does have a user database, or is part of a domain or Active Directory, then WinGate can synchronise and authenticate against that OS user database.  This saves system administrators the pain of replicating the existing user databases on the network. User database options
WinGate (version 6.0 and later) has the ability to intergrate and synchronise with an Active Directory User Database, be it on the local or a remote machine.

This allows you to set up internet access policies in WinGate based on your current setup of users and groups in AD, instead of having to recreate them all, as well as allowing you to use NTLM authentication for such services as SMTP, WWW, and POP3.

For inforamtion on non Active Directory user database's see the link on the features page
Back to top

User authentication options

WinGate supports several modes of operation, and methods for authentication.

Different sites and networks often have different policy requirements for access to internet services. In some cases the system administrator may wish to completely lock down the system, and only allow a restricted set of users to perform restricted activities. Other installations may allow more freedom.

To cater for these varying requirements, WinGate was developed to support various methods of operation in relation to user identification and validation, ranging from no authentication at all, through assuming who a user is based on their IP, through to forced authentication.

The way each of these options is selected is on a per-service or global basis by use of WinGate policies. Choosing the appropriate option on the user tab of the Policy editor in WinGate allows you to specify whether a user may be assumed, could be anyone or guest, or must authenticate with a strong authentication method to gain access to that right (i.e. rights to access a service, or perform a task in WinGate).

Further to this, if policy dictates that user authentication is to be used, there are several options available.

  • WinGate's own secure MD5-based challenge response authentication method provided by the Remote Control Service in WinGate (used by GateKeeper, and the Java Client available through the WWW Proxy) [only available if you are using WinGate's built-in user database];
  • MicroSoft's proprietary NTLM method. This method is integrated into client software such as MS Internet Explorer, or Outlook, and is available in WinGate in the Remote Control Service (for GateKeeper access), WWW Proxy, SMTP server, POP3 Server, and Winsock Redirection Service (for the WinGate Internet Client). [only available if you are using the Windows user database]
  • HTTP Basic authentication for the WWW Proxy
  • Several other mail specific options, such as CRAM-MD5, SASL PLAIN, APOP, and plaintext options.
Notes:
  • In addition to the above, users can make use of plaintext (insecure) authentication in Telnet, HTTP or SOCKS 5 to achieve an assumed level of authentication.

Back to top

Terminal services / multiple users per IP

Using WinGate 7's new Credential Rules, you can enforce individual user credentials even when multiple users are connecting to WinGate from a Terminal Server. Terminal services users
WinGate 7 introduces a credential rules system to manage how user credentials will be treated on a per machine basis. This allows you to implement Assumed User and Multi User Machine policy on your network. Credential Rules (Multi-user machines)
WinGate solves the problem of per-user policy where users are hosted on a terminal server.

Most proxy servers associate the IP address of the client machine with a single user at any one time. If there are many users logged into a terminal server which then connects out through such a proxy, all connections are from the same IP address. This means a traditional problem has been how to tell individual users apart for access to the Internet if they are logged into a terminal server.

WinGate solves this problem with Credential Rules. This allows individual authentication of users who are using a terminal server to access the Internet.

Normally, WinGate will associate user credentials with an IP address, and new sessions from that IP will inherit these credentials. However, if you specify the IP address of your terminal server in a credential rule, you may prevent credentials from being inherited for connections from that IP. This means that if your access policies require authentication, then every connection from that IP will have to be individually authenticated. This then allows per-user authentication from a terminal server.

Some protocols do not provide for authentication to a proxy server (such as DNS, file-sharing apps etc). This means this traffic may show up as belonging to the Guest user. If you install the WinGate Internet Client on the terminal server however, and are using the Windows or Active Directory user database in WinGate, then authentication of the logged in user becomes automatic (and uses their windows credentials). Furthermore all TCP connections made by the user will be associated with their credentials whether or not the application they are using supports proxy authentication.
Back to top

User and group management

The core of any secured access control system is user management. You can't provide per-user rules, or restrict access on a per-user basis without some concept of what a user is.

WinGate allows for use of several user databases. Firstly, for those operating systems that do not provide a built-in user database (such as Windows 95, 98, ME, and XP Home), WinGate provides its own built-in user database. For other Windows operating systems, you may alternatively choose to use the user database that is made available in the Operating System itself, thereby avoiding the necessity to set up and maintain an additional user database. This can be extremely useful for users of large databases. Additionally, WinGate can use a remote user database hosted on an Active Directory, Domain Controller, or even NT Workgroup.

If using the WinGate User Database, then you can create as many Users and Groups as you need, for example having groups for different departments in your company, and having groups that will be allowed to access the internet, and groups that wont. You can also have nested groups - groups within groups, to more accurately model your organisational structure.

Of course you may already have these set up on the servers on your network, in which case you can point WinGate at the machine which holds your user database, and it will synchronise with all your predefined users and groups.

No matter which user database you prefer, it is through these that you can then configure WinGate to control access to specific internet services, in conjunction with authentication and system and service policies.


Back to top

Support for AI content filtering

WinGate includes support for several plug-in components which are available separately. These data scanning components allow you to scan content passing through WinGate proxies. One component, a Content Filter in association with Icognito, is PureSight, which will scan WWW traffic, for undesirable content.

A number of different categories exist that cover common topics that users may wish to block from their network. These range from sex and gambling, through to sport sites, job seeking, and web mail.

There is also a number of different ways content can be blocked, be it via the AI, a match with a listing on a global database, or by a user customisable ban list.


Back to top

In-built or OS user database

WinGate needs a user database in order to be able to provide user-level security etc.  In cases where the operating system that WinGate is installed on does not have a user database, WinGate has its own one.  Alternatively if the OS WinGate is installed on does have a user database, or is part of a domain or Active Directory, then WinGate can synchronise and authenticate against that OS user database.  This saves system administrators the pain of replicating the existing user databases on the network. User database options
WinGate doesn't have to use it's own user database. It can use an existing NT database (Windows NT and later OS's are supported, with the exception of XP Home edition). This can be a local or remote NT database, or even a local or remote domain controller.

This allows you to set up internet access policies in WinGate based on your current setup of users and groups in Windows, instead of having to recreate them all, as well as allowing you to use NTLM authentication for such services as SMTP, WWW, and POP3.

For information about Active Directory see the link on the features page
Back to top

Flow-chart policy

In the WinGate 7 policy system, each policy is a user-defined sequence of decisions and actions.  This gives customers complete control over policy evaluation, and enables the system to perform any policy task, including conditionally modifying requests, alerting administrators, running external tasks etc. Flow-chart policy
The policies panel shows you all the policies in WinGate.  This allows centralised management of policies for all types of event and event source. Policies panel

The flow-chart policy system is a new way of thinking about policy control.

The new flow-chart policy system gives you complete control over policy structure - the order and sequence of evaluations made to come to an access control decision. You can share policies amongst multiple proxies, test a policy before going live with it. Change-manage policy updates.


Back to top