Access Control 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 can authenticate users to and synchronise with an Active Directory for user accounts and group membership, including multiple forests.

This means you can log into WinGate for mail, web, or remote configuration using your Active Directory accounts.

WinGate has a users and groups panel that can perform filtered searches of your active directory objects - users, groups and computers. It also has a search facility that is used throughout WinGate for searching for users, groups, computers or domains for various WinGate configuration functions.

In this way, Active Directory is tightly and seamlessly integrated into WinGate.

Specific attention was paid to dealing with very large domains with large numbers of objects, and heavy load. This includes an object caching layer to reduce LDAP fetches from the domain controllers.
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

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
As an alternative to the Active Directory user database connector, WinGate ships with 2 other connectors. One for access to the local windows user database on the host system, and the final one a standalone WinGate user database.

When you install WinGate, the next step after license activation is choice of user database to use. WinGate forcefully guides you through this step, as nothing can be done in WinGate without a user database provider.


Back to top

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
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 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