Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Contributor II

Explicit proxy with Kerberos authentication

I followed the guide below to configure explicit proxy and enable Kerberos with NTLM in fallback:

Administration Guide | FortiGate / FortiOS 6.4.8 | Fortinet Documentation Library


Everything works correctly.


The problem is that all users authenticate through NTLM and not Kerberos:

# diagnose wad user list
ID: 2, IP:, VDOM: vdom1
  user name   : TEST31@DOMAIN
  duration    : 7
  auth_type   : Session
  auth_method : NTLM
  pol_id      : 1
  g_id        : 5
  user_based  : 0
  expire      : no
    bytes_in=6156 bytes_out=16149
    bytes_in=7618 bytes_out=1917

 I have a doubt: is it all here or is some configuration missing?


I found this article on TechNet:

Active Directory: Using Kerberos Keytabs to integrate non-Windows systems - TechNet Articles - Unite...


In particular it seems to be necessary to enable Kerberos for the service user used for the keytab:


<After the keytab generation, the User logon name changes into an SPN, so it can be found by Kerberos clients looking it up.  Note that the checkbox "This account supports Kerberos AES 256 bit encryption" under Account Options is selected.  The checkbox must be manually selected after the keytab generation otherwise you'll receive an error along the lines of 'Cannot find key of appropriate type to decrypt AP REP...".>


In our case, the Fortinet guide generates the keytab with the "-crypto all" option, so I have enabled all 3 fields DES, AES 128,AES 256.

But I keep seeing authentications only in NTLM...


Anyone have ideas?


1 Solution

I confirm that the DNS record created with the domain account name used to create the keytab must be used in the PAC file.

View solution in original post

New Contributor

I'd recommend getting a packet capture on the client and enable Kerberos error logging. Double check the relevant browser auth settings (firefox splits ntlm and spnego/kerberos settings) and/or GPO. Also ensure your client has visibility to the KDC, and the SPN was registered correctly in AD when doing the ktpass step (from a windows joined machine: "setspn -l FGT" should return your personalized version of the example from the guide: "HTTP/FGT.FORTINETQA.LOCAL").


Hey ac1,

perhaps a stupid question, but what is the explicit proxy setting on your test client?

Does it have an IP or a hostname set?

For Kerberos authentication to work, the host needs to access proxy by hostname.

I once had the issue in a lab, all config was in place correctly but only NTLM auth was happening, and it turned out to be the case because of that simple oversight :D


+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++

An fqdn is set which is resolved correctly and from where the client I checked is able to obtain the PAC file.


Did you have to enable Kerberos support in the service domain account used on FortiGate, in your configurations?




Hey ac1 - when I had my lab set up, I didn't have to enable anything specifically on the service account FortiGate was using as I recall.

You could consider taking a packet capture to see the proxy authentication process.

-  you should see an HTTP 407 from FortiGate indicating that proxy authentication is required

- this should include an offer of what authentication methods are available

-> It should be visible here if FortiGate is only offering NTLM, or also offering Kerberos

-> that should give us some clue if Kerberos is even an option for the client PC, and if yes, which one it goes with.


We are, however, drifting into very technical troubleshooting - might be worth opening a ticket with Technical Support for more in-depth support.

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
Contributor II

I caught the traffic from the client. I filtered the traffic from "http.response.code == 407" and I saw:





what does it mean?



Hey ac1,

the ''Negotiate TlRMTVNTxxxxxxxx" bit is the one that indicates Keberos is being offered, if I remember correctly.

A pure NTLM offer looks like this:



+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++

Ok, so it is the client not accepting Kerberos Negotiation.


That's what it looks like to me at least.

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++

The problem may be in the PAC file. The set FQDN does not have the same name as the service user for which the A record was created on the domain.

In this line:

return "PROXY";


In my keytab:

config user krb-keytab
edit "http-proxy"
set pac-data disable
set principal "HTTP/"
set ldap-server ""
set keytab "ENC xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"


I have to test the FQDN change on the PAC file: ->


Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Top Kudoed Authors