Technical Tip: FortiGate explicit proxy authentication with Kerberos

[Hatibi]

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.

Figure 1. Enable explicit proxy in FortiGate GUI.

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.

Figure 2. Explicit Web proxy configuration settings.

Figure 3. FortiGate Interface Configuration where Explicit proxy will listen for requests.

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.

Figure 4. LDAP Server configuration in FortiGate

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 of 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, and 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 example, it is set 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'.

Figure 5. Sevice Instance account creation for FortiGate

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.

Figure 6. DNS A record configuration for FortiGate

Verify the PTR record.

Figure 7. DNS PTR record configuration for FortiGate

Generate the Kerberos keytab using the ktpass command on the Windows server. Make sure to enter the realm part in capital letters, and the FQDN in lowercase (Kerberos is case-sensitive).

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

Here 'user' is the service account defined on the AD for the Kerberos service. For 'password', use the password defined for the service account.

Open the 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 fortigate2.keytab tmp.b64 && findstr /v /c:- tmp.b64 > fortigate2.txt OR certutil -encode fortigate2.keytab fortigate2.txt
• Use this command if the above does not work in PowerShell : certutil -encode fgt.keytab fortigate2.txt
• Linux: base64 fortigate2.keytab > fortigate2.txt
• MacOS: base64 -i fortigate2.keytab -o fortigate2.txt

Use the base64 command (available in most Linux distros) command to encode the fortigate2.keytab file. Any LF (Line Feed) necessary to be deleted from the file.

For example:

base64 fgt.keytab > fgt.txt

Use Notepad++ or a native Linux text editor. Windows Notepad and Wordpad are likely to introduce errors as shown below. Make sure that there are no LF or spaces.

If the file contains the LF or spaces, the error shown in the screenshot below can be seen.

 

The encoded text result in the Base64 (fortigate2.txt) keytab might be split into several lines. This will not be accepted when pasting the text in the 'set keytab' in the following step 4. when Kerberos is defined as an authentication service.

To make sure that a single line of text is added in FortiGate, use a text editor to properly edit and merge the split lines. The keytab and .txt files will be located in the directory the commands were run, by default C:\Users\<username>.

Figure 8. Keytab file location in local host.

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

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

Note:

Starting from v7.4.5, these files are not visible anymore due to Security Reasons:

fnsysctl ls -la /tmp/kt
ls: /tmp/kt: No such file or directory

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.

Figure 9. Group configuration to be used with kerberos authentication.

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 Authentication Rule.

Configuration through the GUI.

Scheme configuration:

Figure 10. Authentication Scheme configuration in FortiGate

Rule configuration:

Figure 11. Authentication Rule configuration in FortiGate.

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.

Figure 12. Configuring the Explicit proxy policy in FortiGate.

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. Testing the scenario with a non-domain 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.

Figure 13. Proxy settings configuration on the test host.

The captive portal prompt can be prevented, eliminating the need for the user to re-enter login credentials. To do this, open Internet Properties by typing 'inetcpl.cpl' in the Windows command prompt, then go to Security -> Local Intranet -> Sites -> Advanced. Add the FortiGate FQDN/IP address, including the HTTP/HTTPSprefix.

For example http://fortigate2K.domain.com or https://fortigate2K.domain.com.

It is possible to verify user authentication in the FortiGate CLI.  For this, run 'diagnose debug enable' and then the command below:

Figure 14. List authenticated users through Explicit proxy in FortiGate.

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

Figure 15. User Event logs in FortiGate GUI.

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

Figure 16. Kerberos granted tickets list on the test host.

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