Running SPNEGO with the firewall

To explain how SPNEGO operates, this document will rely on the example of a user who wishes to access the Internet. The various phases of SPNEGO authentication are as follows:

  1. The user authenticates on the network (Microsoft Active Directory domain).
  2. The domain controller authorizes this authentication.
  3. The user opens his web browser to connect to the website of his choice.
  4. The HTTP proxy enabled on the firewall redirects the web browser to the authentication portal on the firewall.
  5. The web browser will then connect transparently to the firewall’s authentication portal using its serial number. In the diagrams, this serial number is represented by “FW-DNSNAME”. For this purpose, this “FW-DNSNAME” has to be resolved by the DNS server configured on the client workstation.
  6. The firewall will inform the web browser that it needs to issue a Kerberos client ticket associated with its service (SPN).
  7. The web browser will then ask the domain controller to associate the ticket provided during exchange number 2 with the firewall's SPN service. USERNAME will then be associated with HTTP/FW-DNSNAME.
  8. After having checked that the user has indeed been authenticated on the domain, the domain controller will provide the web browser with the requested information. In the diagrams, the ticket is represented as “SECRET” (USERNAME / HTTP/FW-DNSNAME pair).
  9. The web browser forwards the new USERNAME / HTTP/FW-DNSNAME@Domain ticket to the firewall, which then decrypts its contents using the encryption key shared between the domain controller and the firewall (Keytab). The user is then authenticated for the duration defined by the administrator. In these diagrams, this key is represented by "KEY".
  10. The firewall redirects the web browser to the firewall’s HTTP proxy, which provides the user with the web page initially requested.

All the exchanges of information described above take place transparently for the user. The user does not need to either log on manually to the authentication portal or enter his login or password.

Exchanges (5) to (9) are encrypted: (5), (6) and (9) in SSL and exchanges (7) and (8) are made in plaintext with an encrypted Kerberos ticket (the Kerberos ticket cannot be used without an encryption key).

Note that there is no direct interaction between the firewall and the domain controller.

The clocks on the client workstation, domain controller and the firewall must all be synchronized, as any discrepancy of a few minutes may cause an authentication failure.