Some software that uses HTTP(S) can't reply to an authentication request from a proxy. To make these types of software work through a proxy, the destinations the software access on the internet, need to be excluded from authentication. Bypassing destinations from authentication is done by creating categories for the destinations/use existing ones and add those into the "Included categories or category groups:" field in "Web proxy - Authentication - Exceptions". This is a global setting and the effect on the logging is that all access to the included destinations will be logged with an IP address as source. Group membership for the request is set to either "Unauthenticated IPs" or as the group set in the proxy configuration for unauthenticated access.
When to use authentication bypass
Required bypass
Authentication bypass is only needed for some proxy authentication. This first set of methods do require bypass of authentication for any software not capable replying to the authentication method used because they authenticate every session. Even if a user has browsed and authenticated using a browser, a new connection will still be asked to authenticate. This means all software using the proxy will be asked to authenticate and exceptions have to be made for software not supporting authentication. Smoothwall does not recommend using any of these any longer as we have other methods better suited with less problems regarding software authentication. If you are using any of these, please contact support so we can explain and recommend more suitable options.
- Negotiate Kerberos/NTLM
- Negotiate Kerberos/NTLM (Terminal services compatibility mode)
- Kerberos
- Kerberos (Terminal services compatibility mode)
- Proxy authentication
- Proxy authentication (Terminal services compatibility mode)
- NTLM identification
- NTLM identification (Terminal services compatibility mode)
- NTLM authentication
- NTLM authentication (Terminal services compatibility mode)
Optional bypass
The next set only authenticate once for the duration of the login timeout value seen in the "Services - Authentication - Settings". This means that once a user has been authenticated, new sessions will not require to authenticate for the duration of the login timeout. This cause less issues with software not able to authenticate and can be addressed by the user by keeping their browser open and browsing occasionally as well as setting an appropriate login timeout value. Authentication bypass can be used less often when these methods are used.
- Redirect users to SSL Login page (with background tab)
- Redirect users to SSL Login page (with session cookie)
- Redirect users to non-SSL Login page (with background tab)
- Redirect users to non-SSL Login page (with session cookie)
- Negotiate Kerberos/NTLM (via redirect)
- Kerberos (via redirect)
- NTLM authentication (via redirect)
- NTLM identification (via redirect)
- Smart redirect
No bypass needed
The remaining methods do not rely on the proxy asking the client software to provide authentication so no authentication bypass is needed at all. Some of these methods are not listed as proxy authentication methods when setting up a new proxy. This is because they are not initiated or completed by the proxy - they have to be configured independently of the proxy.
- iDex agent - agent software is installed on domain controllers that then sends user login events to the Smoothwall. When a user logs in, the Smoothwall gets told so there is no need for the proxy to ask the user who they are. Compatible with all the optional bypass methods as well as core authentication.
- iDex client - client software installed on Windows or MacOS clients. The client sends user information with every we request, so the proxy again does not need to ask who the user is. The iDex client use a special proxy interface on the Smoothwall.
- Login scripts - scripts are provided for both Windows and MacOS. Script runs at login and refreshes every 2 minutes. When a user logs in, the Smoothwall gets told so there is no need for the proxy to ask the user who they are. Compatible with all the optional bypass methods as well as core authentication.
- RADIUS 802.1x - perfect for BYOD setups. When the user logs into the Wifi network the user also gets logged into the Smoothwall system. Compatible with all the optional bypass methods as well as core authentication.
A combination of these methods is recommended. The advantage here is that authentication is done before the users starts browsing and is handled separately to the proxy. This bypasses all the compatibility issues otherwise seen when software cannot respond to a proxy authentication request.
Other methods
There are 3 methods listed in the selection for proxy authentication method that we have not mentioned above.
- Core authentication - This method does not ask for usernames or passwords. Core authentication will check if a user is logged in from the IP address the request came from and if there is, assign the relevant permissions to the request. If there is no user logged in, core authentication will treat the request as unauthenticated.
- Identification by location - This method use IP address and location definitions to assign permissions. No user authentication is done. This method is redundant as the same results can be achieved using location objects in the where setting and assigning specific groups to the unauthenticated requests, so disregard this method.
- Ident - Ident requires that clients run and ident service on their machines in order to work. Initially used by Novell Netware networks but not in widespread use currently.
Closing remarks
If your Smoothwall proxy setup has not been revisited for the past 2-3 years, we would recommend you contact support or your account manager, to setup a session about what changes may be appropriate to implement for your authentication setup. Smoothwall has made a lot of improvements to the authentication methods in recent years that can help make your life easier.