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