Skip to content

Authentication methods

Details about the authentication methods available in Sophos Firewall.

Sophos Firewall supports both NTLM (NT LAN Manager) and Kerberos authentication. The main difference is how the two protocols handle the client authentication.

With NTLM, clients send credentials to Sophos Firewall, which sends the credentials to the AD server to be checked. This authentication process requires the exchange of three messages.

With Kerberos, clients send a ticket to Sophos Firewall, which is validated without talking to the AD server. This authentication process requires the exchange of just one message.

So, Kerberos is faster and uses fewer resources. This matters more in environments with hundreds of concurrent users. If Use per-connection AD SSO authentication for multi-user hosts is turned on in Authentication > Web authentication, the number of authentication requests can increase a thousand-fold. While NTLM is technically supported, Kerberos is needed for most environments.

You can configure Sophos Firewall to only offer NTLM to clients, or to offer both Kerberos and NTLM. You cannot configure Sophos Firewall to only offer Kerberos, as this is not supported by the HTTP specification. The client decides whether to use Kerberos or NTLM. Clients that support Kerberos prefer to use it over NTLM, but only when they are connecting to systems that the AD server tells them are valid.


When using NTLM or Kerberos, the firewall redirects transparent mode traffic to port 8091 for authentication.


NTLM, also known as Windows challenge-response, is a suite of security protocols offering users authentication, integrity, and confidentiality. It's the authentication protocol used on networks that run Windows operating systems and standalone systems.

It uses an encrypted challenge-response mechanism to authenticate clients without sending a password. The credentials consist of a domain name, a username, and a one-way hash of the user's password, obtained through an interactive authentication process. The system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.

It uses three messages to authenticate clients:

  1. Clients establish a network path to the server and send a NEGOTIATE_MESSAGE advertising their capabilities.
  2. The server responds with CHALLENGE_MESSAGE which is used to establish the identity of clients.
  3. Clients respond to the challenge with an AUTHENTICATE_MESSAGE.

Sophos Firewall supports single sign-on (SSO) authentication for NTLM users. However, since NTLM is a browser-initiated authentication method, it's at a lower priority than other authentication methods such as the following:

  • General Authentication Client
  • Clientless single sign-on
  • Client-based single sign-on

NTLM is used as a fallback if any of the above authentication methods fail. If NTLM also fails, the captive portal is shown for user authentication. To troubleshoot NTLM authentication failures, see Troubleshooting authentication.


Windows 2000 and later versions use Kerberos as the default authentication method. Kerberos builds on symmetric key cryptography and requires a trusted third party. Optionally it may use public-key cryptography during certain phases of authentication.

Kerberos uses a two-way handshake using a ticket granting service called a key distribution center. The authentication steps are as follows:

  1. Clients authenticate themselves to the Authentication Server (AS) which forwards the usernames to a key distribution center (KDC).
  2. The KDC issues a ticket-granting ticket (TGT), adds a time stamp, encrypts it using the ticket-granting service's (TGS) secret key and returns the encrypted result to the users workstation. This is done infrequently, typically at user sign-in.

The TGT expires at some point although it may be transparently renewed by the user's session manager while they are signed-in.

Kerberos has strict time requirements, which means the clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication fails. The default configuration requires that clock times be no more than five minutes apart.

More resources