There are a variety of authentication methods for the web filter. Here we look at the differences between authentication methods as well as the pros and cons of each type.
Direct proxy authentication/identification
The methods listed below are all direct proxy authentication/identification methods. They are only available for a non-transparent proxy. Each session has to be authenticated when using these methods which means that even if a browser has authenticated correctly, bringing up an app that uses the proxy, this app needs to authenticate too.
Advantages: Automatic authentication/identification for all NTLM and Kerberos methods.
Disadvantages: Application has to support the authentication/identification method. Authentication bypass has to be used for applications that are not able to provide authentication replies.
We don't recommend that you use any of these any longer because 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 (Terminal services compatibility mode)
- Proxy authentication (LEGACY as of Maiden 1)
- Proxy authentication (Terminal services compatibility mode) (LEGACY as of Maiden 1)
- NTLM identification
- NTLM identification (Terminal services compatibility mode)
- NTLM authentication
- NTLM authentication (Terminal services compatibility mode)
Indirect proxy authentication/identification
The next set only authenticate once for the duration of the login timeout value 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 causes less issues with software that's 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.
Advantages: Automatic authentication/identification for all NTLM and Kerberos methods. Works with external authentication/identification methods.
Disadvantages: Login timeout can mean misidentification of users if another user starts using a system before the login expires. Applications that do not support proxy authentication/identification methods can still have issues.
- Redirect users to SSL Login page (with background tab) (LEGACY as of Maiden 1)
- Redirect users to SSL Login page (with session cookie)
- Redirect users to non-SSL Login page (with background tab) (LEGACY as of Maiden 1)
- 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 (LEGACY as of Maiden 1)
The remaining methods don't 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.
Advantages: Automatic authentication/identification for all methods. Bypasses any issues with applications not supporting proxy authentication.
Disadvantages: Additional setup required. Misidentification is possible in certain scenarios but can be minimized/eliminated with proper implementation.
- iDex agent - Agent software is installed on domain controllers that then sends user login events to the Smoothwall Filter. When a user logs in, the Smoothwall Filter gets told so there is no need for the proxy to ask the user who they are. Compatible with all the indirect authentication/identification methods as well as core authentication.
- iDex client - Client software installed on Windows or MacOS clients. The client sends user information with every web request, so the proxy again doesn't need to ask who the user is. The iDex client uses a special proxy interface on the Smoothwall Filter.
- Login scripts - Scripts are provided for both Windows and MacOS. The script runs at login and refreshes every 2 minutes. When a user logs in, the Smoothwall Filter gets told so there is no need for the proxy to ask the user who they are. Compatible with all the indirect authentication/identification 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 Filter. Compatible with all the indirect authentication/identification methods as well as core authentication.
A combination of indirect and external methods is often 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.
In addition to the above advantages, these methods are compatible with the indirect authentication/identification methods.
There are three methods listed in the selection for proxy authentication method that we have not mentioned above.
- Core authentication - This method doesn't ask for usernames or passwords. Core authentication checks 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 (LEGACY as of Maiden 1) - This method uses IP address and location definitions to assign permissions. No user authentication is done. This method is redundant because 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.
Replace with 'No Authentication' with the 'Location' provided by a Guardian Location Object.
- Ident (LEGACY as of Maiden 1) - Ident requires that clients run an Ident service on their machines to work. Initially used by Novell Netware networks but not in widespread use currently.
If your Smoothwall Filter proxy setup has not been revisited for the past two to three years, we would recommend that you contact your account manager, to setup a session about what changes might be appropriate to implement for your authentication setup. We have made a lot of improvements to the authentication methods in recent years that can help make your life easier.