Technical Tip: FortiGate explicit proxy authentication with Kerberos

[Sx11]

Description

This article describes how to enable explicit proxy on FortiGate and configure Kerberos as an active authentication method.

Documentation:

Explicit proxy authentication.

Scope

FortiGate.

Solution

In this scenario, the following elements are used:

• Windows Server 2012.
• Domain: amf.meta.local.
• NetBIOS name: AMF.
• FortiGate v7.0.1.

1. Enable and configure Explicit proxy.

If the explicit proxy feature is not visible in the GUI, it is possible to enable it in System -> Feature Visibility.

Configure explicit proxy settings and the interface on FortiGate.

In this case, port3 has been configured as the ingress interface for host traffic.

GUI configuration.

CLI configuration.

config web-proxy explicit
    set status enable
    set http-incoming-port 8080
    set https-incoming-port 8080
    set unknown-http-version best-effort
end

config system interface
    edit "port3"
        set vdom "root"
        set ip 192.168.20.1 255.255.255.0
        set allowaccess ping https ssh snmp radius-acct
        set type physical
        set explicit-web-proxy enable
        set alias "Remote"
        set lldp-transmission enable
        set role lan
        set snmp-index 3
    next
end

2. Configure the Authentication Server on FortiGate.

GUI configuration.

CLI configuration.

config user ldap
    edit "2AD"
        set server "amf.meta.local"
        set cnid "sAMAccountName"
        set dn "cn=users,dc=amf,dc=meta,dc=local"
        set type regular
        set username "cn=Administrator,cn=Users,dc=amf,dc=meta,dc=local"
        set password ENC somepassword
    next
end

3. Windows Server configuration and keytab generation.

Kerberos operates through a set of centralized Key Distribution Centers, or KDCs.

The KDC consists of three logical components:

• Database of all principals and their associated encryption keys
• Authentication Server
• Ticket Granting Server

Instead of sending plain-text passwords over the network in the clear, Kerberos uses encrypted tickets to prove the identity users or servers.

These tickets are generated by the centralized Key Distribution Centers on behalf of users who wish to authenticate to the network.

When using Kerberos, user passwords are never sent over the network in the clear.

Services running on systems that are not running the Windows operating system (in this case FortiGate) can be configured using service instance accounts in Active Directory, Directory Services (AD DS). 

For this reason, a key file will be used and generated on the Windows Server.

This allows any Kerberos client to authenticate to services not running the Windows operating system by using Windows KDCs.

Create a user to identify FortiGate on the Windows server.

• As a service name, set the FortiGate Hostname. In this scenario, we have set it to 'fortigate2'.
• Create the username in all lowercase (even if this goes against corporate standards).
• User accounts created should have a membership to domain users.
• Configure a strong password.
• Select option 'Password never expires'.

Add the FortiGate FQDN into the Windows DNS domain, Host A and PTR records.

Create the new record and select 'Update associated pointer (PTR) record'.

Make sure to previously have configured Reverse Lookup zones for the PTR records to be updated automatically.

Verify the PTR record.

Generate the Kerberos keytab using the ktpass command on the Windows server.

Make sure to enter the realm part in capital letters, the FQDN in lower case (Kerberos is case-sensitive).

ktpass -princ HTTP/<fortigate Hostname>@realm -mapuser <user> -pass <password> -crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab

Open command line prompt 'cmd' on the Windows server and enter (with a secure password after '-pass'):

ktpass -princ HTTP/fortigate2.amf.meta.local@AMF.META.LOCAL -mapuser fortigate2 -pass !StrPass91 -crypto all -ptype KRB5_NT_PRINCIPAL -out fortigate2.keytab

After that generate a new file by encoding the binary formatted fortigate2.keytab to base64 encoded text:

• Windows: certutil -encode fgt.keytab tmp.b64 && findstr /v /c:- tmp.b64 > fortigate2.txt
• Linux: base64 fgt.keytab > fortigate2.txt
• MacOS: base64 -i fgt.keytab -o fortigate2.txt

The keytab and .txt files will be located in the directory the commands were ran, by default C:\Users\'Your user'.

4. Define Kerberos as an authentication service. This option is only available in the CLI.

config user krb-keytab
    edit service_fortigate2
        set pac-data disable
        set principal HTTP/fortigate2.amf.meta.local@AMF.META.LOCAL
        set ldap-server 2AD
        set keytab PJ7lfH7uO0B-shortened-DgF+bgyExW/-shortened-1z8sVciKUfyT2FWK+UoI="
    next
end

Note:

The principal entered must match exactly what was entered in the ktpass command when the keytab file was generated.

In the keytab file, copy the value from fortigate2.txt without any spaces or additional characters.

Once the keytab is imported, check that it has been properly decoded.

It is visible with the following command:

fnsysctl ls -la /tmp/kt
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

5. Create a user group for Kerberos Authentication.

Create a new group of type Firewall and select the previously configured LDAP server named '2AD' as the remote server.

In this active directory tree a test user 'srogers' has been created which is part of the 'Domain Users' and 'remoteAdmins' groups on the Windows Server.

GUI configuration.

CLI configuration.

config user group
    edit "KRB"
    set member "2AD"
    config match
       edit 1
           set server-name "2AD"
           set group-name "CN=remoteAdmins,OU=France,OU=Europe,DC=amf,DC=meta,DC=local"
       next
       edit 2
           set server-name "2AD"
           set group-name "CN=Domain Users,CN=Users,DC=amf,DC=meta,DC=local"
       next
    end
next
end

6. Create an Authentication Scheme and Rule.

Configuration through the GUI.

Scheme configuration:

Rule configuration:

Configuration through CLI.

config authentication scheme
    edit "KRB2"
        set method negotiate
        set negotiate-ntlm disable
        set kerberos-keytab "service_fortigate2"
    next
end

config authentication rule
    edit "Rule_KRB2"
        set srcaddr "all"
        set ip-based disable
        set active-auth-method "KRB2"
    next
end

7. Create an explicit proxy-policy.

Configuration through the GUI.

Add the 'KRB' group created previously in the source.

Configuration through CLI.

config firewall proxy-policy
    edit 1
        set name "KRB2_policy"
        set proxy explicit-web
        set dstintf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set service "webproxy"
        set schedule "always"
        set logtraffic disable
        set groups "KRB"
    next
end

Windows proxy settings and monitoring.

To test the scenario, a non-domain will bed used, joined Windows PC.

Domain user: srogers

Go to Control panel -> Internet Options -> Connections.

Enter the FortiGate FQDN/IP as a proxy server in LAN settings and modify the port to 8080.

It is possible to verify user authentication in the FortiGate CLI:

In Log& Report -> Events -> User events, it is possible to monitor the user and authentication data.

On the Windows host, it is possible to check the granted tickets in cmd through 'klist' command:

Related articles:

• Troubleshooting Tip: Kerberos proxy-authentication and group lookup.
• Technical Tip: Kerberos authentication through FortiGate 'Redirected Transparent Web Proxy'.
• Technical Tip: Configuring FortiProxy Kerberos authentication for explicit proxy.