Web: Permissions & Limits

A number of general permissions can be set for each group in the Permissions & Limits subsection of the Web tab.

These are heritable settings (see Group Inheritance). If you are not sure which settings would be applied to a user, look at the Policy Modelling report.

These settings will also be inherited by all the descendent groups, unless explicitly overridden. If you need to override the inherited settings, untick the Inherit box of the setting and adjust it as appropriate.

Allow users to override a block

If the filtering is simply being used to prevent trusted users from accidentally stumbling across inappropriate content, it can be useful to allow those users to override a block if they are sure that the website they are visiting is ok. When a user is blocked, if they are in a group with this setting ticked they will be given the option to temporarily override the block and continue to the website.

Bypass all web proxy restrictions

Users who are in a group that has this option ticked will not be restricted by any web filtering or bandwidth limits at all, irrespective of any other settings.

HTTPS decryption

By decrypting HTTPS traffic, the filter can analyse and log encrypted traffic. This option allows you to find a balance between safety and intrusiveness:

• Active decryption - Traffic may be fully decrypted. The filter will be able to examine the whole URI and content in order to categorise the request. Logs will contain full data, including the whole URI, content type, etc. Client devices need to have your unique Opendium inspection certificate installed as a trusted root certification authority.
• Passive inspection - The TLS handshake may be decoded but traffic will not be decrypted. The filtering and reporting capabilities will be reduced - only the host name part of the URI will be available to the system and no content can be examined. Client devices do not need the Opendium inspection certificate installed.
• Disabled [NOT RECOMMENDED] - No examination of the encrypted traffic is done. The filtering and reporting capabilities will be extremely limited.

Note that by default, banking websites are excluded from active interception. We recommend that active interception is enabled for students. It is often convenient to use passive inspection for guest devices.

Display splash page for new devices

When a device first connects to the network, it will be presented with a splash page and may be instructed to download and install the system's unique inspection certificate. This is most useful for Bring Your Own Device networks, where users will need to install the certificate before they can browse the web. For networks of workstations, where the certificate is being installed through Windows Group Policy, turn this setting off.

Please ensure that the certcheck DNS records have been created on your internal domain.

Autoconfigure devices to use the proxy

Devices on this network will be able to automatically discover the proxy server using the Web Proxy Auto-Discovery (WPAD) protocol. It is recommended that this setting is enabled.

Please ensure that the wpad DNS records have been created on your internal domain and that your DHCP scopes are correctly configured.

User identification

Different types of device require different techniques in order to unobtrusively associate the web requests with specific users. This option allows you to pick a suitable profile. The Automatic setting provides a reasonable default that works reasonably well in most situations, but setting a more specific profile to each part of your network helps provide the best compatibility with the devices.

• Automatic [NOT RECOMMENDED] - this is an "all round" mode that works in most situations. However, it has a number of problems, so it is preferable to divide your network up so that a more appropriate setting can be used for networks of each type of device. A combination of HTTP proxy authentication, captive portal authentication, WISPr and RADIUS accounting will be used.
• Automatic 2 [NOT RECOMMENDED] - similar to Automatic mode, except that traffic through the transparent proxy will not be authenticated. This mode is not recommended.
• Workstation - for networks of workstations which accept logins from several non-concurrent users. A combination of HTTP proxy authentication and RADIUS accounting will be used. Devices must use the non-transparent proxy. Transparently proxied requests will be denied until after an authenticated proxy request has been made.
• Single user devices - for networks of devices whereby each device is only used by a single user. For example, wifi networks of personal devices such as phones, tablets, etc. A combination of captive portal authentication, WISPr and RADIUS accounting will be used. If the Opendium system should expect to receive RADIUS accounting data for all devices on the network, use RADIUS mode instead.
• Multiuser servers - for networks of servers whereby each server is expected to be used by multiple concurrent users. For example, remote desktop servers. HTTP proxy authentication will be used exclusively. When HTTP proxy authentication is not possible, users will not be identified.
• RADIUS - for networks that provide login and logout notifications through RADIUS accounting, such as wifi networks using 802.1x / WPA-Enterprise authentication. Only RADIUS accounting will be used. You must also configure your wifi controller to send RADIUS accounting data to the Opendium system and traffic will be denied until accounting data has been received. This method is also used for the Opendium Chrome browser extension (see below).
• Adhoc RADIUS - the same as RADIUS, except traffic will be allowed if no RADIUS accounting data has been received for a device.
• Guest RADIUS - for guest wifi systems that send accounting data containing a temporary user name. This behaves like disabling user identification, except that access from devices for which no accounting data has been received will be denied, and the user name in the accounting data will be included in the logs and can therefore be used for reporting. Note: the user name will not be used for access control, quotas or automatic user disabling, even if it matches the name of a real user.
• Disabled - users are not identified.

A brief description of the authentication mechanisms which are commonly used:

• HTTP Negotiate proxy authentication (Kerberos / NTLM) - this is the primary method used by workstations that are connected to a Windows domain. It is a single-signon system, so the user only needs to log onto the workstation and never has to authenticate with the proxy separately. It is, in theory, possible to authenticate every web connection individually for maximum accuracy, but in reality some software is not compatible and most user identification modes only authenticate some of the requests and use cached information for the rest.
• HTTP Basic proxy authentication - this also sends authentication information directly to the proxy, but is not a single-signon mechanism. The user will usually see a popup authentication box when they start their web browser, but the browser may save their credentials between sessions.
• 802.1x / WPA-Enterprise - the device sends login credentials to a network access controller (i.e. the wifi access point or ethernet switch) when it is connected to the network. The client is authenticated by a RADIUS authentication server, which may either be the Opendium system or a third party system. Once the client connects to the network, the network access controller forwards the login information onto the Opendium system's RADIUS accounting service.  The proxy needs to perform no further authentication, since it can identify the user based on the information provided to the RADIUS service.
• Captive portal - web requests are redirected to a login page which the user can log in to with their user name and password.
• WISPr - this works like the captive portal, except that the device saves the login credentials the first time the user logs in through the portal, and automatically logs back in each time the device reconnects to the network.
• ChromeOS passthrough authentication - Chromebooks can be configured to log in to an 802.1x wifi network using an "onboarding" user name, and then re-login to the network as the appropriate user once a user has logged into the device.  The "onboarding" user should have the walled garden enabled and the ChromeOS Onboarding override applied. It may be advisable to also assign the "onboarding" user to a separate VLAN.
• Chrome extension - schools who use Google Classroom and have no other facilities for providing user identification information to the Opendium system can install the Opendium user identification extension for the Chrome web browser. Whenever the user logs onto Google Classroom, their browser will automatically send their user name to the Opendium system. The Chrome Onboarding override should be applied to the network and the user identification profile set to RADIUS.

Limit users' bandwidth

The amount a user downloads over the web can be restricted by enabling this setting. Once a user has exceeded the limit, their web requests will be blocked.

This works on a "Leaky Bucket" model: If, for example, a user is allowed to download 500MB per hour, they start with 500MB left in their quota. If they then use 400MB of that over a half hour period, at the end of that time they will have 350MB of their quota left (100MB of the original 500MB, plus the 250MB extra they accumulated over that half hour based on the 500MB/hour limit). As such, a user can actually use up to 1000MB in a single hour, but when averaged over a longer period the limit tends towards the configured 500MB per hour.

Restrict requests to IP literals

Most legitimate applications use a host name to make requests to web servers, whereas VPNs frequently make connections to unidentified IP addresses. It is usually a good idea to block these requests, but it may break a few legitimate applications.

Possible options are:

• Block POSTs - HTTP/HTTPS POST requests to IP literals will be blocked.
• Block all - the most aggressive setting, all requests to IP literals will be blocked.
• Disabled - requests to IP literals will be allowed.

Allow users to access reports

Users with this option set will be able to access reports about users' web access, and may receive real time alerts based on configured Reporting Categories.

Administrators can always access reports.