Category:Client Configuration

Proxy settings

Opendium systems provide a traditional non-transparent authenticated HTTP proxy and a transparent proxy. The non-transparent web proxy is the preferred system, as it includes some capabilities which cannot be performed by the transparent proxy, such as Kerberos single sign-on authentication. However, it does require software to understand how to find and talk to the proxy. Workstations usually use the non-transparent proxy for the majority of their traffic, whereas tablets and phones usually rely more on transparent proxy.

We recommend using automatic proxy discovery wherever possible. Ensure that Autoconfigure devices to use the proxy is ticked on Permissions & Limits, the wpad DNS records have been created on your internal domain and that your DHCP scopes are correctly configured.

However, if it is necessary to manually configure the proxy, the settings used should be:

You must use the address shown above, rather than the proxy's IP address, otherwise Kerberos Single Sign-on authentication will not work.

Authentication

The proxy server supports the following methods of client authentication:

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

• Kerberos - automatic single sign-on, requires no interaction from the user. The workstation must be a member of the Windows domain and configured to use the non-transparent proxy.

The authentication methods that clients are expected to use are determined by the User Identification mode of the appropriate network. We highly recommend that your network is split into VLANs with the appropriate user identification mode set on each network rather than using the Automatic mode.

Certificates

By default, the system performs active HTTPS decryption and client devices are therefore usually required to have your unique Opendium inspection certificate installed. A link to the certificate can be found in the Web tab, and also on the Splash Page. You may want to include a link to the certificate in a convenient location on your Intranet or print the QR code to download it on any literature.

It is not always feasible to install a certificate on every device. For example, it is desirable to connect guest devices to the network without installing the certificate. In those cases, you can set the HTTPS Decryption mode to Passive, but be aware that this will greatly reduce the filtering and auditing capabilities of the system and is therefore not usually a suitable configuration for student devices.

Remember that since the Opendium system automatically examines network traffic, including encrypted traffic, you should ensure the users all agree to a usage policy that indicates that their network traffic may be monitored. Under data protection law, there are a number of requirements that must be met, which are discussed in our blog article on the subject.

Configuration Instructions for Specific Clients

We have provided several pages, listed below, giving guides to the configuration of several common client devices.