- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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: 10.1.100.202, 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 LAN: bytes_in=6156 bytes_out=16149 WAN: 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:
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?
Solved! Go to Solution.
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirm that the DNS record created with the domain account name used to create the keytab must be used in the PAC file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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").
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Thanks

Created on ‎03-01-2022 12:15 AM Edited on ‎03-01-2022 12:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
EDIT:
We are, however, drifting into very technical troubleshooting - might be worth opening a ticket with Technical Support for more in-depth support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I caught the traffic from the client. I filtered the traffic from "http.response.code == 407" and I saw:
what does it mean?

Created on ‎03-01-2022 07:43 AM Edited on ‎03-01-2022 07:43 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, so it is the client not accepting Kerberos Negotiation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's what it looks like to me at least.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 proxy.domain.net:8080";
In my keytab:
config user krb-keytab
edit "http-proxy"
set pac-data disable
set principal "HTTP/fortinet.domain.net@DOMAIN.NET"
set ldap-server "domain.net"
set keytab "ENC xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
next
end
I have to test the FQDN change on the PAC file:
proxy.domain.net -> fortinet.domain.net
