Authentication methods

Details about the authentication methods available in XG Firewall.

XG Firewall supports both NTLM and Kerberos authentication. The main difference is how the two protocols handle the client authentication.

With NTLM, clients send credentials to XG 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 XG 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. However, you notice this only in heavily loaded environments.

You can configure XG Firewall to only offer NTLM to clients, or to offer both Kerberos and NTLM. You cannot configure XG 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.

NTLM

NTLM is a challenge-response authentication protocol which 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.

Kerberos

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.