The SafeSquid service processes a connection, by using the entries in the Access Restrictions, before the connection is processed by any other section.
The Access Restrictions Section allows you to specify the Access rights for various users.
As the name suggests Access Restrictions allows you to specify access rights for users that may use the SafeSquid's proxy service.
It also allows you to:
- Create policies for Authentication
- Create policies based on IP Address(es)
- Policies for access to the WebGUI
- Modes of use (transparent or explicit specification of proxy)
- Permission to use CONNECT methods for https sites or FTP clients
- Disabling of one or more filters
- Create policies for different interfaces on which SafeSquid service is listening for incoming clients
- Profile the users for being uniquely processed in other sections
This section has a Global Section, and two sub-sections - Allow and Deny.
In SafeSquid versions that support Windows Integrated Authentication, the Global Section allows you to explicitly Enable or Disable NTLM authentication. By setting this to "Disabled", you can explicitly switch off the support for Windows Integrated Authentication. If this option is enabled, SafeSquid offers authentication headers that encourage the client's browser to use Negotiate, NTLM or Basic Authentication, depending upon the browser's capabilities and user's system configuration.
The realm name used for the authentication is the proxyhost specified in the startup configuration. If the proxyhost is not specified or left blank, hostname specified in the General Section of the config is used to form the realm of the Authentication Challenge. SafeSquid for Windows automatically considers this realm as the domain name when processing an authentication via Windows LSA, if the user does not specify a domain name as a part of the username, when responding to an authentication challenge.
The Access Restrictions section functions like a typical network-layer firewall.
The Global Section also allows you to define the default Access Policy. You could set this to either Allow or Deny. If you set the default policy to Deny, you must create entries in the Allow sub-section, to specify which users may access. Conversely if you set the default policy to Allow, you can specify the users that should be denied access, in the Deny sub-section.
The entries are:
- matched in the top-down order,
- so the entry in the top of a sub-section is matched first,
- and the first entry that matches is used for the connection, and the remaining entries in the list are ignored.
- individually managed.
An entry can be pushed up or down the order as desired. An entry can be used as a template, by cloning it and editing the clone for adjustments. Entries can be added or deleted in a sub-section.
The scope of each entry can be made broad or narrow as desired, by appropriately defining the rules that constitute that entry.
An entry in Access Restrictions can be constituted by making rules that test for:
An entry is considered to be matched only if ALL the rules test positive.
Incomplete … Under construction