Skip to main content
ac1
ac1
Explorer III
February 25, 2022
Solved

Explicit proxy with Kerberos authentication

  • February 25, 2022
  • 3 replies
  • 16209 views

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:

Active Directory: Using Kerberos Keytabs to integrate non-Windows systems - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com)

 

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?

 

Best answer by ac1

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

3 replies

Tristan_C
Tristan_C
New Member
February 26, 2022

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").

Debbie_FTNT
Staff & Editor
Debbie_FTNT
Staff & Editor
February 28, 2022

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

 

ac1
ac1Author
Explorer III
February 28, 2022

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

Debbie_FTNT
Staff & Editor
Debbie_FTNT
Staff & Editor
March 1, 2022

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.

ac1
ac1Author
Explorer III
March 1, 2022

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

img1-1.png

 

img1.png

 

what does it mean?

 

Debbie_FTNT
Staff & Editor
Debbie_FTNT
Staff & Editor
March 1, 2022

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:

Debbie_FTNT_0-1646149386621.png

 

    ac1
    ac1Author
    Explorer III
    March 1, 2022

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

    Terms & ConditionsAccessibility statement