Technical Tip: Configuring FortiProxy Kerberos authentication for explicit proxy
Description
This article describes how to configure Kerberos authentication for explicit Proxy on FortiProxy.
Scope
Any supported version of FortiProxy.
Solution
Windows Server general setup.
Kerberos environment - Windows Server setup:
- For the test, set up a Windows Server 2016 with a domain configuration and Active Directory.
- Set the domain name MT-TEST.LOCAL (realm name).
Create an AD user:
- testuser is a normal user (can be any existing domain user account).
- fortikerberos is the example user that will be used for creating the Kerberos ticket.
Recommendation: Create the username in all lowercase (even if this goes against corporate standards).
- The account only requires 'domain users' membership.
- Set the password to never expire.
- Set a very strong password.
Create a DNS record for FortiProxy.
Create a DNS A record mapping the FortiProxy IP address to the FQDN. For example:
FORTIPROXY.MT-TEST.LOCAL -> 10.0.0.240.
Generate the Kerberos keytab:
On a Windows Server, use the ktpass command through CMD to generate the Kerberos keytab.
Note that it is necessary to run CMD with the 'Run as Admin' option.
An explanation of the KTPass syntax can be seen in the following Microsoft article:
ktpass
Syntax example:
ktpass -princ HTTP/<FQDN of FortiProxy>@REALM -mapuser fortiproxy@domain.com -pass <password> -crypto all -ptype KRB5_NT_PRINCIPAL -out fpx.keytab
Test example:
ktpass -princ HTTP/fortiproxy.mt-test.local@MT-TEST.LOCAL -mapuser fortiproxy@mt-test.local -pass 12345678 -crypto all -ptype KRB5_NT_PRINCIPAL -out fpx.keytab
Note that the principal parameter is case-sensitive.
The output after creating a successful keytab looks similar to the following:

Use the base64 command available in most Linux distros (or use any other available Base64 encoder) to encode the fpx.keytab file.
base64 fpx.keytab > fpx.txt
In Windows Server 2016, use the native tool to encode fpx.keytab file to Base64. The output will be used for the FortiProxy keytab.
certutil -encode <keytab> <encode-file-name>
FortiProxy configuration.
All of the settings can be done in CLI or in GUI.
From the GUI, go to User & Device -> LDAP Servers and create a new LDAP server object.

set cnid "sAMAccountName"
set dn "dc=mt-test,dc=local"
set type regular
set username "fortibind@mt-test.local”
set password <password>
Go to User & Device -> Kerberos and create a new Kerberos object:

set ldap-server "dc01" <- The defined ldap server for authorization.
set keytab "BQIAAABNAAIACkJFUkJFUi5DT00ABEhUVFAAGlRPTllfRkdUXzEwMERfQS5CRVJCRVIuQ09NAAAAAQAAAAAKABcAEJQl0MHqovwplu7XzfENJzw=" <- Base64 encoded keytab data, created in step 5 of general setup.

edit "krb"
set method negotiate
set negotiate-ntlm disable
set kerberos-keytab "krb_mttest"
next
end

edit "kerberos"
set srcintf "port1"
set srcaddr "all"
set dstaddr "all"
set ip-based disable
set active-auth-method "krb"
next
end
Go to User & Device -> User Groups and create a new group:

edit "testgrp"
set member "dc01"
config match
edit 1
set server-name "dc01" <- Same as ldap-server option in krb-keytab.
set group-name "CN=Domain Users,CN=Users, DC=mt-test,DC=local"
next
end
next
end

edit 0
set type explicit-web
set name "test"
set explicit-web-proxy "web-proxy"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "webproxy"
set logtraffic all
set groups "testgrp"
set utm-status enable
next
end
drwxr--r-- 2 0 0 Fri May 29 10:19:05 2020 60 .
drwxrwxrwt 31 0 0 Fri May 29 10:28:49 2020 2260 ..
-rw-r--r-- 1 0 0 Fri May 29 10:19:05 2020 387 KEY-FILE
Check Kerberos is working.
Cached Tickets: (5)
#0> Client: testuser @ mt-test.local
Server: krbtgt/MT-TEST.LOCAL @ MT-TEST.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
Start Time: 12/6/2020 14:58:06 (local)
End Time: 12/7/2020 0:58:04 (local)
Renew Time: 12/13/2020 14:58:04 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#1> Client: testuser @ mt-test.local
Server: krbtgt/MT-TEST.LOCAL @ MT-TEST.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 12/6/2020 14:58:04 (local)
End Time: 12/7/2020 0:58:04 (local)
Renew Time: 12/13/2020 14:58:04 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#2> Client: testuser @ mt-test.local
Server: cifs/EthicsGradient.mt-test.local @ MT-TEST.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 12/6/2020 14:58:06 (local)
End Time: 12/7/2020 0:58:04 (local)
Renew Time: 12/13/2020 14:58:04 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#3> Client: testuser @ mt-test.local
Server: ldap/EthicsGradient.mt-test.local @ MT-TEST.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 12/6/2020 14:58:06 (local)
End Time: 12/7/2020 0:58:04 (local)
Renew Time: 12/13/2020 14:58:04 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#4> Client: testuser @ mt-test.local
Server: LDAP/EthicsGradient.mt-test.local/mt-test.local @ MT-TEST.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 12/6/2020 14:58:06 (local)
End Time: 12/7/2020 0:58:04 (local)
Renew Time: 12/13/2020 14:58:04 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96

- The client accesses the explicit proxy, but an HTTP 407 Proxy Authentication Required error will be returned.
- As 'Negotiate' is set, the client knows the KRBTGT, and it requests a ticket from the KDC with a krb-tgs-req message.
This includes the REALM (MT-TEST.LOCAL) in the reg-body section, and the provided instances SNAME and service (in this case, HTTP/dc01.mt-test.local). - The KDC responds with the next KRB-TGS-REP.
This ticket is then available to the client.
In the example below, the ticket-granted-service has issued Ticket #2:
Server: HTTP/dc01.mt-test.local @ MT-TEST.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 12/6/2020 14:59:45 (local)
End Time: 12/7/2020 0:58:04 (local)
Renew Time: 12/13/2020 14:58:04 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
- The conversation between the client and the proxy continues as the client responds with the Kerberos ticket in the response.
The whole process takes less than a second to complete.
diagnose wad filter src <IP address>
diagnose wad debug enable category auth
diagnose wad debug enable category policy
diagnose wad debug enable level verbose
diagnose debug application fnbamd -1
diagnose debug enable
To stop debug:
diagnose debug disable
diagnose debug reset
One possible reason the client does not show the ticket for the HTTP protocol under klist is if there is an encryption mismatch between the client and the service. Both need to use the same Kerberos encryption type.
"Unsupported etype" error when accessing a resource in a trusted domain
Related articles:
Technical Tip: How to debug Kerberos authentication in FortiProxy
Technical Tip: FortiGate explicit proxy authentication with Kerberos
Troubleshooting Tip: Kerberos proxy-authentication and group lookup
Technical Tip: Kerberos authentication through FortiGate 'Redirected Transparent Web Proxy