Authentication Methods

 

Authentication is used to identify the end user and apply the right policies. When adding authentication policies, you can use the listed authentication methods.

Authentication methods work with Transparent proxies (where the client device does not know a proxy exists, limiting the types of authentication that can be used), Non-transparent proxies (where clients have proxy settings explicitly set, so the proxy can ask the client for authentication for every request), or both.

Non-transparent authentication policies require devices to be configured to use the specified Authentication Method.

Transparent authentication policies don’t require devices to be configured. When using Transparent authentication policies:

• Client devices must not be multi-homed (connected to multiple LANs, such as wired and wireless simultaneously).
• Client devices must not be dual-stacked, for example, they must not use both IPv4 and IPv6 addresses.

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 asking the client applications to provide authentication, so no authentication bypass is needed. 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 not to ask who they are because the IDex software installed on domain controllers sends user sign-in events to Smoothwall instead.
• Kerberos Authentication Scripts: When a user signs in, the scripts tell Smoothwall that the proxy does not need to ask the user who they are. The sign-in refreshes automatically every two minutes.
• RADIUS: When a user signs into the Wi-Fi network, they are also signed into Smoothwall by 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.

These methods can only be used with a Non-transparent proxy.

Advantages:

• Automatic authentication and identification.

Disadvantages:

• The application has to support the authentication method, or you’ll need to bypass authentication.

Terminal Services compatibility mode

Each direct proxy authentication has a standard version and a Terminal Services compatibility mode version.

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

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
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.
Kerberos and Kerberos (Terminal Services compatibility mode)		This method identifies users using the Kerberos keytab.
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.
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 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.
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 for Smoothwall in Active Directory. Smoothwall 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.

 

Indirect proxy authentication/identification

These methods only require a user to authenticate 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 timeout.
• 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.

These methods can be used with a Non-transparent or Transparent proxy, apart from Negotiate Kerberos/NTLM (via redirect), which must be used with a Transparent proxy.

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 proxy authentication/identification 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
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. 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 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. Requirements: The authentication service supports only one user per device IP address. To securely sign out, the user must click Logout on the SSL Login page.
Negotiate Kerberos/NTLM (via redirect)	Deprecated as of June 2025.	he 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.
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. See Adding Kerberos keytabs. The authentication service supports only one user per device IP address.
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.
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. The authentication service supports only one user per device IP address.
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. The authentication service supports only one user per device IP address.

 

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 will apply 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 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 has. Global Proxy listens on all external interfaces. Turning on this policy adds the Smoothwall Firewall rules to automatically allow external access to the proxy port.	Non-Transparent