Skip to main content

Authentication Methods

Updated

Authentication is used to identify the end user and apply the right policies. When adding Web Proxy Authentication policies, you can use the listed authentication methods. For more information on Authentication and Transparent or Non-transparent Web Proxying, see the Smoothwall Authentication overview.

No authentication

Users are only identified by their IP address. All requests are assigned to the Unauthenticated IPs user group.

This can be used with both Transparent and Non-transparent proxies.

External authentication

These methods don't rely on the proxy requiring client applications to provide authentication, so no authentication bypass is required. These methods are configured independently of the proxy, and work exactly the same with both Transparent and Non-transparent proxies.

Advantages:

  • Automatic authentication and identification.
  • No bypass issues when applications cannot respond to a proxy authentication request.
  • It can be combined with Indirect Proxy Authentication to authenticate users before they start browsing.

Disadvantages:

  • Additional setup is required.
  • Users could be misidentified if the setup is incorrect.

Methods:

  • IDex: When a user signs in, the IDex Agent tells Smoothwall Filter not to ask who they are because the IDex software installed on domain controllers sends user sign-in events to Smoothwall Appliance instead.
  • Kerberos Authentication Scripts: When a user signs in, the scripts tell Smoothwall Appliance that the proxy does not need to ask the user for their credentials. The sign-in refreshes automatically every two minutes.
  • RADIUS: When a user signs in to the Wi-Fi network, they are also signed in to Smoothwall Filter via RADIUS. This option is usually used for Bring Your Own (BYO) devices.

Direct Proxy Authentication

These methods require users to authenticate for every session and new connection. When using one of these methods, you must add Authentication Exceptions for any software that does not support authentication.

  • Advantage: Automatic authentication and identification.
  • Disadvantage: The application must support the authentication method, or you’ll need to bypass authentication.

Terminal Services compatibility mode

Each Direct Proxy Authentication method has a standard version and a Terminal Services compatibility mode version.

Terminal Services compatibility mode is for network devices that use Microsoft Terminal Services (Remote Desktop Connections), allowing multiple users to connect from the same IP address. Every request must be identified to accurately track user activity.

You must not use a Terminal Services compatibility mode Authentication Method when using Firewall rules for specific User Groups, as authentication won’t work as expected.

Methods

Method Support Description Policy Type
Negotiate Kerberos/NTLM
and
Negotiate Kerberos/NTLM (Terminal Services compatibility mode)		 Deprecated as of June 2025. The device selects the most secure authentication method it supports between Kerberos or NTLM.
Requirements:
  • The user account to set up the Active Directory must be permitted to connect devices to the domain.
  • All devices must be connected to the same Active Directory domain.
 Non-transparent
Kerberos
and
Kerberos (Terminal Services compatibility mode)		   This method identifies users using the Kerberos keytab. Non-transparent
Proxy authentication
and
Proxy authentication (Terminal Services compatibility mode)		   This method identifies users by requesting a username and password when they first use their web browser. These details are encoded in all future requests made through the browser. For each connection, the browser supplies a header which the server can ask for if it's not already present. Non-transparent
NTLM identification
and
NTLM identification (Terminal Services compatibility mode)		 Deprecated as of June 2025. Identifies users based on the username used to sign in to their Windows-based device.
Requirements:
  • Smoothwall Filter only supports NTLM identification Microsoft operating system software and browsers, even if the platform claims to support NTLM.
  • NTLM identification should only be used on single-domain networks because it doesn’t transmit domain information alongside usernames.

  Important

NTLM identification doesn't verify a user's credentials, so it should only be used where all devices are secured and members of a Windows domain.

 Non-transparent
NTLM authentication
and
NTLM authentication (Terminal Services compatibility mode)		 Deprecated as of June 2025. Identifies users based on the username used to sign in to their Windows-based device and validates their credentials with the domain controller.
Requirements:
  • The user account to set up the Active Directory must be permitted to connect devices to the domain.
  • There must be a device account in Active Directory.
  • Smoothwall Filter only supports NTLM identification Microsoft operating system software and browsers, even if the platform claims to support NTLM.
  • NTLM authentication should only be used on single-domain networks because it doesn’t transmit domain information alongside usernames.
 Non-transparent

 

Indirect Proxy Authentication

These methods require a user to authenticate only once for the duration of the sign-in timeout value (found on the Services > Authentication > Settings page). When using these methods, you can:

  • Advise users to keep their browsers open and regularly browse to prevent timeouts.
  • Set the timeout to a reasonable value. It should be long enough to cover when devices change hands, but short enough so users are not asked to re-authenticate an unreasonable number of times. Your organisation should decide this, but the default is 10 minutes.

Advantages:

  • Automatic authentication and identification.
  • They can be combined with External authentication.

Disadvantages:

  • Users can be misidentified if another user uses the system before the sign-in expires.
  • Using this method can cause issues with applications that don’t support Indirect Proxy Authentication methods, such as the app ceasing to work or users not being authenticated
  • The authentication service supports only one user per device IP address.
Method Support Description Policy Type
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)		 Deprecated in Maiden:
  • Redirect users to SSL Login page (with background tab)
  • Redirect users to non-SSL login page (with background tab)
If you need help, contact Smoothall Support.

  Important

We recommend using the Redirect users to SSL Login page (with session cookie) option with a HTTPS certificate. The non-SSL option isn't secure because it uses HTTP to submit the username and password.

This method identifies users with the authentication service and sends this encrypted information to Smoothwall Filter. If no user is signed in, web requests are redirected to the SSL login page or non-SSL login page, where users must enter their username and password.

Smoothwall Filter stores a session cookie on the user’s browser, removing the need for the user to re-authenticate or leave the SSL login page open. Because of this, this method is best used for tablet PCs and other mobile devices that can’t keep tabs in browsers open in the background.
To securely sign out, the user must click Logout on the SSL Login page.

Both
Negotiate Kerberos/NTLM (via redirect) Deprecated as of June 2025. The device selects the most secure authentication method it supports between Kerberos or NTLM.
Requirements:
  • The user account to set up the Active Directory must be permitted to connect devices to the domain.
  • All devices must be connected to the same Active Directory domain.
  • Devices not connected to the domain must be set up to require users to enter valid domain credentials.
 Transparent
Kerberos (via redirect)   This method identifies users with the authentication service. If no user is signed in, web requests are redirected to the Kerberos sign-in page, which obtains the username signed into their Windows-based device. Both
Smart redirect

Deprecated in Maiden.

If you need help, contact Smoothall Support.

 This method identifies the user’s device and redirects them to an NTLM authentication or SSL login service.
The System > Authentication > User Activity page shows the authentication method used instead of Smart redirect.

  Note

The redirect is based on the User-Agent data received in the browser’s HTTP header packet and is a best-guess scenario based on pattern matching and compatibility.

 Both
NTLM identification (via redirect) Deprecated as of June 2025. This method identifies users with the authentication service. If no user is signed in, web requests are redirected to the NTLM sign-in page, which obtains the username signed into their Windows-based device. Both
NTLM authentication (via redirect) Deprecated as of June 2025. This method identifies users with the authentication service. If no user is signed in, web requests are redirected to the NTLM sign-in page, which obtains the username signed into their Windows-based device and validates their credentials with the domain controller. Both

 

Other Authentication methods

Method Support Description Policy Type
Core authentication  

  Important

You should use Core authentication alongside an External authentication method.

Core authentication controls what sites anonymous users can access and allows authenticated users to access more.
  • If the user authenticates with the authentication service, Smoothwall Filter applies policies depending on the User Group they fall into.
  • If the user hasn't authenticated with the authentication service, they're assigned to the Unauthenticated IPs group for policies and can only be identified with their IP address in reports.
If they are met with a Block page, they can authenticate themselves using the SSL or non-SSL login page (depending on what your organisation has set up).		 Both
Ident

Deprecated in Maiden.

If you need help, contact Smoothall Support.

 Ident identifies users with the username returned by a server on their device and does not verify credentials. Once the Ident server identifies the user, Smoothwall Filter filters their web activity according to their User Group. Both
Identification by location

Deprecated in Maiden.

Instead, use Location Objects in the Where step of an Authentication Policy.

 This method identifies users by IP address and assigns a User Group based on the Identification by Location policy. Both
Global Proxy using NTLM Deprecated as of June 2025. This method identifies users with NTLM credentials when signed into the Secure Global Proxy service. You can implement device authentication using certificates on your devices.
  • You can only create one Global Proxy using the NTLM authentication policy, regardless of the number of internal interfaces your Smoothwall Appliance has.
  • Global Proxy listens on all external interfaces.
  • Turning on this policy adds the Firewall rules to automatically allow external access to the proxy port.
 Non-Transparent