When using certain combinations of proxy authentication methods, it's possible that, for a time, a user entry in the web filter logs is incorrect. Any authentication/identification method that uses a timeout to log the user out, could potentially misidentify entries in the web filter logs.
When a timeout logs the user out, it's possible that the user can browse for a while before the timeout is reached, and the original, logged-in, user is no longer present. There are multiple methods that use login timeouts. This might affect the methods listed in the table, and what solutions are available to minimize the occurrences of this happening.
Potential solutions
Description | Be aware of | Remedies |
Idex agent (Not iDex client) |
||
Agent software installed on Active Directory domain controller sends login information to the Smoothwall. The agent doesn't send logout information. | In networks, where the DHCP pool is shared between BYOD, Domain and service devices and/or where the DHCP pool is small so devices re-use IP addresses often, the use of iDex agent should be considered carefully, as incorrect identification is likely to occur. |
The authentication service can be told to erase all iDex logins on a daily basis. This option should almost always be used with the iDex agent. Access in the GUI is via a hidden URL: HTTPS://smoothwall.ip:441/admin/hbd/ |
Negotiate Kerberos/NTLM (via redirect) (port 813) Kerberos (via redirect) (port 812) NTLM Authentication (via redirect) (port 810) NTLM Identification (via redirect) (port 811) |
||
All options with the word redirect in them, will check if a login is recorded from the IP address the request comes in from. If not, the redirect will happen. If a user login is recorded, no redirect is needed. | All redirect options use the global timeout value from "Services - authentication - settings". When a login is active, the timeout needs to be reached before the login is renewed. | Careful consideration needs to be given to what type of device and networks should be using these methods. All of these methods are great as backup methods when iDex agent, RADIUS and Login scripts are used as primary methods. |
Kerberos Login Scripts (port 814) |
||
The kerberos login scripts, available for MAC OSX and Windows, runs on user login and logs the user into the Smoothwall system. The login refreshes automatically every two minutes and times out after three. | Due to the short timeout values and the fact that these scripts runs on login, this method is the most robust of the automated login methods, with the least likelihood of mis-identification. | Login scripts in combination with a redirect method is the most reliable method for domain devices. The low timeout value and the automated refresh, coupled with the fact that the script runs at login, makes mis-identification unlikely. |
Login page. SSL and non-SSL. |
||
The login pages will show if there are no users logins recorded on the IP address of the incoming request. Login pages have two variants. One where the page has to be kept open in order to remain logged in, another where the page can be closed and a cookie manages the login keep-alive. | Login pages also use the global timeout from the "Services - authentication - settings" page. Login pages can be customised in the backend (update safe). The session based option keeps the user logged in until the browser is closed or the system is powered off/logged off. Shared devices, especially iPads, may need to use this option. | Login pages are often used on Guest networks and will also work as a fallback for any of the automated methods mentioned before, RADIUS, Login scripts and iDex agent. With shared devices it may be needed to provide a logout link, so users can manually logout before handing the device over to another user. |
The issue of mis-identification is due to the fact that while we can reliably tell when a user begins browsing, its harder to tell when they stop. The introduction of the iDex system (both agent and client) as well as our RADIUS and login script capabilities, helps to minimise and in most cases, completely remove any cases of mis-identification.
If you need advice in designing an authentication scheme or would like to move to some of the newer options Smoothwall is now offering for user authentication, please raise a ticket.