Fortinet black logo

Handbook

Kerberos

6.0.0
Copy Link
Copy Doc ID 4afb0436-a998-11e9-81a4-00505692583a:926128
Download PDF

Kerberos

Kerberos authentication is a method for authenticating both explicit web proxy and transparent web proxy users. It has several advantages over NTLM challenge response:

  • Does not require FSSO/AD agents to be deployed across domains.
  • Requires fewer round-trips than NTLM SSO, making it less latency sensitive.
  • Is (probably) more scalable than challenge response.
  • Uses existing Windows domain components rather than added components.
  • NTLM may still be used as a fallback for non-Kerberos clients.
Note

For authentication of transparent mode proxy sessions to work, you need to enable SSL deep inspection.

Enhancements to Kerberos explicit and transparent web proxy

FortiOS 5.6.x authentication is managed by schemes and rules based on protocol and source address. As such, configurable authentication settings have been introduced to enhance authentication.

CLI commands (config authentication rule, scheme, and setting) allow explicit proxy rules and schemes to be created to separate user authentication (e.g. authentication rules and schemes used to match conditions in order to identify users) from user authorization (proxy-based policies with users and/or user groups).

CLI syntax - config authentication rule

config authentication rule

edit <name>

set name <name>

set status {enable|disable}

set protocol {http|ftp|socks}

config srcaddr <addr-name or addrgrp-name>

edit <name>

set name <ipv4-policy-name>

next

end

config srcaddr6 <addr-name or addrgrp-name>

edit <name>

set name <ipv6-policy-name>

next

end

set ip-based {enable|disable}

set active-auth-method <scheme-name>

set sso-auth-method <scheme-name>

set transaction-based {enable|disable} - basic scheme + session-based

set web-auth-cookie {enable|disable}

set comments <comments>

next

end

Note: As shown above, HTTP, FTP, and SOCKSv5 authentication protocols are supported for explicit proxy.

Authentication rules are used to receive user-identity, based on the values set for protocol and source address. Having said this, if a rule fails to match based on source address, there will be no other attempt to match the rule, however the next policy will be attempted. This occurs only when:

  • there is an authentication rule, but no authentication method has been set (under config authentication scheme; see below), so user identity cannot be found.
  • the user is successfully matched in the rule, but fails to match the current policy.

Once a rule is positively matched through protocol and/or source address, it must also match the authentication method specified (active-auth-method and sso-auth-method). These methods point to schemes, as defined under config authentication scheme.

CLI syntax - config authentication scheme

config authentication scheme

edit <name>

set name <name>

set method {basic|digest|ntlm|form|negotiate|fsso|rsso}

set negotiate-ntlm {enable|disable}

set require-tfa {enable|disable}

set fsso-guest {enable|disable}

config user-database

edit <name>

set name {local|<ldap-server>|<radius-server>|<fsso-name>|<rsso-name>|<tacacs+-name>}

next

end

next

end

Combining authentication rules and schemes, granular control can be exerted over users and IPs, creating an efficient process for users to successfully match a criteria before matching the policy.

Additional options can be set under config authentication setting.

CLI syntax - config authentication setting

config authentication setting

set sso-scheme <scheme-name>

set active-scheme <scheme-name>

set captive-portal <host-name>

set captive-portal-port <tcp-port>

end

Integration of transparent and explicit proxy HTTP policy checking

A CLI command, under config firewall profile-protocol-options, allows HTTP policy checking to be enable or disabled. When enabled, transparent traffic can be matched in a firewall policy and policy user authentication can occur. In addition, separate SSL inspection policies can be created:

config firewall profile-protocol-options

edit <name>

set http-policy {enable|disable}

end

Internet Service Database in Explicit/Implicit proxy policies

CLI commands, under config firewall proxy-policy, implement the Internet Service Database (ISDB) as the webproxy matching factor, and override IP pool is also support:

config firewall proxy-policy

edit <name>

set proxy {explicit-web|transparent-web|ftp|wanopt}

set dstintf <dst-name>

set poolname <ip-pool-name>

end

Multiple port/port range support for explicit web and explicit FTP proxy

Multiple port numbers and/or ranges can be set for explicit proxy, specifically for HTTP/HTTPS and FTP. Go to Network > Explicit Proxy and configure settings under Explicit Web Proxy and Explicit FTP Proxy, or under config web-proxy explicit in the CLI Console.

1. General configuration

1.1 Kerberos environment - Windows server setup
  1. Build a Windows 2008 Platform server.
  2. Enable domain configuration in windows server (dcpromo).
  3. Set the domain name TEST.COM (realm name).
1.2 Create users
  • testuser is a normal user (could be any existing domain user account).
  • testfgt is the service name. In this case it should be the FQDN for the explicit proxy Interface, For example the hostname in the client browser proxy config.
  • Recommendation: create username all in lowercase (even if against corporate standards).
  • The account only requires “domain users” membership
  • Password set to never expire
  • Set a very strong password
1.3 Add FortiGate to DNS
tooltip icon Add the FortiGate FQDN in to the Windows DNS domain, as well as in-addr.arpa

For Lab/Testing add the FortiGate Domain name and IP mapping in the hosts file (windows/system32/drivers/etc/hosts). e.g., TESTFGT.TEST.COM 10.10.1.10

1.4 Generate the Kerberos keytab

Use the ktpass command (found on Windows Servers and many domain workstations) to generate the Kerberos keytab.

Example:

ktpass -princ HTTP/<domain name of test fgt>@realm -mapuser testfgt -pass <password> -crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab

note icon In the case where the FortiGate is handling multiple keytabs in Kerberos authentication, use different passwords when generating each keytab.
note icon The ktpass on older Windows servers (i.e. 2003) may not support the “all” crypto option.

Example:

ktpass -princ HTTP/testfgt.test.com@TEST.COM -mapuser testfgt -pass 12345678 -crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab

note icon The realm name is always presented in uppercase, and prefixed with the “@” character.
1.5 Encode base64

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

Example:

base64 fgt.keytab > fgt.txt

note icon Use Notepad++ or some native Linux text editor. Windows Notepad and Wordpad are likely to introduce errors.

2. FortiGate configuration

2.1 Create LDAP server instance

config user ldap

edit "ldap" <<< Required for authorization

set server "10.10.1.1" <<< LDAP server IP, normally it should be same as KDC server

set cnid "cn"

set dn "dc=test,dc=com"

set type regular

set username "CN=admin,CN=Users,DC=test,DC=com" <<< Your domain may require STARTTLS

set password <FOOS>

next

end

2.2 Define Kerberos as an authentication service

config user krb-keytab

edit "http_service"

set principal "HTTP/testfgt.test.com@TEST.COM" <<< Same as the principal name in 1.4

set ldap-server "ldap" <<< the defined ldap server for authoriztion

set keytab "BQIAAABNAAIACkJFUkJFUi5DT00ABEhUVFAAGlRPTllfRkdUXzEwMERfQS5CRVJCRVIuQ09NAAAAAQAAAAAKABcAEJQl0MHqovwplu7XzfENJzw=" <<< base64 endoding keytab data, created in step 1.5

next

end

2.3 Create user group(s)

config user group <<< the group is used for kerberos authentication

edit "testgrp"

set member "ldap"

config match

edit 1

set server-name "ldap" <<< Same as ldap-server option in krb-keytab

set group-name "CN=Domain Users,CN=Users,DC=TEST,DC=com"

next

end

next

end

2.4 Create firewall policy

config firewall proxy-policy

edit 1

set uuid 5e5dd6c4-952c-51e5-b363-120ad77c1414

set proxy explicit-web

set dstintf "port1"

set srcaddr "all"

set dstaddr "all"

set service "webproxy"

set action accept

set schedule "always"

set groups "CN=USERS LAB.PS FSSO"

next

end

2.5 Diagnostics

Once the keytab is imported, check that it has been properly decoded. The filename generated will be relatively random, but should be clearly visible.

Artoo-Deetoo (root) # fnsysctl ls -la /tmp/kt
drwxr--r-- 2 0 0 Fri Dec 2 10:06:43 2016 60 .
drwxrwxrwt 22 0 0 Tue Dec 6 14:28:29 2016 3280 ..
-rw-r--r-- 1 0 0 Fri Dec 2 10:06:43 2016 392 1.0.89.keytab
note icon If there is no file present, then the file hasn’t decoded. Check the file for line feeds and try again.

3. Client side walkthrough

3.1 Check Kerberos is working

Log on to the domain by using testuser, created in 1.2. Use the klist command to list ticket information. In the below example, the client has received krbtgt, CIFS, and LDAP tickets. As there has been no interaction with the FortiGate, there are no references to it.

C:\Users\glenk>klist Cached Tickets: (5)
C:\Users\glenk>klist
Cached Tickets: (5)
#0> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent

Start Time: 12/6/2016 14:58:04 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#2> Client: glenk @ home.local

Server: cifs/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#3> Client: glenk @ home.local

Server: ldap/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#4> Client: glenk @ home.local

Server: LDAP/EthicsGradient.home.local/home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

3.2 Configure client

Set up web-proxy in browser through the FortiGate. This can be achieved via a PAC file or direct browser configuration.

note icon Some Firefox documentation indicates that it is necessary to make manual advanced configuration changes to allow Kerberos authentication work. However, builds 48 (and possibly much earlier) require no additional configuration beyond setting of the proxy server.
3.3 Open a connection to the Internet
  1. The client accesses the explicit proxy, but a HTTP 407 Proxy Authentication Required is returned.
  2. As “Negotiate” is set, the client has knowledge of the KRBTGT, it requests a ticket from the KDC with a krb-tgs-req message. This includes the REALM (HOME.LOCAL) in the reg-body section, and the provided instances SNAME and service (in this case, HTTP/artoo-deetoo.home.local).
  3. The KDC responds with a next KRB-TGS-REP.
  4. This ticket is then available on the client.

    In the example below, the ticket-granted-service has issued Ticket #2.

    #2> Client: glenk @ home.local

    Server: HTTP/artoo-deetoo.home.local @ HOME.LOCAL

    KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

    Ticket Flags 0x40a00000 -> forwardable renewable pre_authent

    Start Time: 12/6/2016 14:59:45 (local)

    End Time: 12/7/2016 0:58:04 (local)

    Renew Time: 12/13/2016 14:58:04 (local)

    Session Key Type: RSADSI RC4-HMAC(NT)

  5. The conversation between the client and the proxy continues, as the client responds with the Kerberos ticket in the response.
  6. The whole process takes less than a second to complete. The user should be visible as a FSSO logon in the Web UI.

Transparent web-proxy Kerberos authentication

Transparent web-proxy allows the FortiGate to process level 7 policy matching, even when the explicit web-proxy is not enabled on the client's browser. The transparent web-proxy policy is set in proxy-policy too. The policy matching rule is the same as the explicit web-proxy.

In the firewall policy level, transparent web-proxy is regarded as a special UTM. The HTTP/HTTPS traffic matches the firewall policy first, then traffic is redirected to the web-proxy daemon. If the transparent web-proxy feature is disabled, http-policy options in profile-protocol-options is used to enable transparent web-proxy feature.

IP-based

Kerberos authentication requires the captive portal to be an FQDN address that is resolved to a local IP address. However, it becomes more complicated to setup an FQDN address in a local user deployment. Therefore you can set the captive-portal-type to either use an FQDN or IP address.

  1. Captive portal and the captive portal port must be configured in transparent web-proxy for support of Kerberos authentication:

    config authentication setting

    set captive-portal-type {fqdn | ip}

    set captive-portal <fqdn-name> / <ip>

    set captive-portal-port "9998"

    end

  2. Authentication rule, scheme, and krb-keytab need to be configured for Kerberos authentication (note the active-auth-method scheme referenced in the rule):

    config authentication scheme

    edit <kerberos-scheme>

    set method negotiate

    set negotiate-ntlm <enable>

    set fsso-guest <disable>

    end

    config authentication rule

    edit <name>

    set status <enable>

    set protocol <http>

    set srcadrr "all"

    set ip-based <enable>

    set active-auth-method <kerberos-scheme>

    end

    config user krb-keytab

    edit <name>

    set principal "HTTP/TESTFGT.TEST.COM@TEST.COM"

    set ldap-server "ldap"

    set keytab <base64-encoding-keytab-data>

    end

  3. Configure LDAP and user group used for authorization:

    config user ldap

    edit "ldap"

    set server "10.10.1.1"

    set cnid

    srt dn

    set type <regular>

    set username "CN=admin,CN=Users,DC=test,DC=com"

    set password ENC <encrypted-password>

    end

    config user group

    edit "testgrp"

    set memeber "ldap"

    config match

    edit "1"

    set server-name "ldap"

    set group-name "CN=Domain Users,CN=Users,DC=TEST,DC=com"

    end

  4. Create proxy-policy, with groups as the authorizing policy-matching element:

    config firewall proxy-policy

    edit 1

    set uuid 1bbb891a-9cd2-51e7-42ff-d1fa13cac3da

    set proxy explicit-web

    set dstintf "any"

    set srcaddr "all"

    set dstaddr "all"

    set service "webproxy"

    set action accept

    set schedule "always"

    set groups testgrp

    end

  5. UTM must be enabled in the firewall policy to support the transparent web-proxy:

    config firewall policy

    edit "1"

    set name "policy1"

    set uuid 8a6ceeac-b016-51e6-2b5c-165070d5bf50

    set srcintf "mgmt1"

    set dstintf "mgmt1"

    set srcaddr "all"

    set dstaddr "all"

    set action <accept>

    set schedule "always"

    set service "ALL"

    set utm-status <enable>

    set profile-protocol-options "transparent-web-proxy"

    set ssl-ssh-profile "deep-inspection"

    set nat <enable>

    end

    config firewall profile-protocol-options

    edit "transparent-web-proxy"

    config http

    set ports "80 8080"

    unset options

    set http-policy enable

    unset post-lang

    end

    ...

    end

Session-based with web-auth cookie

The web-auth-cookie feature is necessary for session-based authentication under transparent web-proxy.

The configuration is the same as for IP-based authentication, except ip-based is disabled in the authentication rule:

config authentication rule

edit "kerberos-rules"

set status <enable>

set protocol <http>

set srcadrr "all"

set ip-based <disable>

set active-auth-method <kerberos-scheme>

next

config authentication setting

set captive-portal <fqdn-name>

set captive-portal-port "9998"

end

Kerberos

Kerberos authentication is a method for authenticating both explicit web proxy and transparent web proxy users. It has several advantages over NTLM challenge response:

  • Does not require FSSO/AD agents to be deployed across domains.
  • Requires fewer round-trips than NTLM SSO, making it less latency sensitive.
  • Is (probably) more scalable than challenge response.
  • Uses existing Windows domain components rather than added components.
  • NTLM may still be used as a fallback for non-Kerberos clients.
Note

For authentication of transparent mode proxy sessions to work, you need to enable SSL deep inspection.

Enhancements to Kerberos explicit and transparent web proxy

FortiOS 5.6.x authentication is managed by schemes and rules based on protocol and source address. As such, configurable authentication settings have been introduced to enhance authentication.

CLI commands (config authentication rule, scheme, and setting) allow explicit proxy rules and schemes to be created to separate user authentication (e.g. authentication rules and schemes used to match conditions in order to identify users) from user authorization (proxy-based policies with users and/or user groups).

CLI syntax - config authentication rule

config authentication rule

edit <name>

set name <name>

set status {enable|disable}

set protocol {http|ftp|socks}

config srcaddr <addr-name or addrgrp-name>

edit <name>

set name <ipv4-policy-name>

next

end

config srcaddr6 <addr-name or addrgrp-name>

edit <name>

set name <ipv6-policy-name>

next

end

set ip-based {enable|disable}

set active-auth-method <scheme-name>

set sso-auth-method <scheme-name>

set transaction-based {enable|disable} - basic scheme + session-based

set web-auth-cookie {enable|disable}

set comments <comments>

next

end

Note: As shown above, HTTP, FTP, and SOCKSv5 authentication protocols are supported for explicit proxy.

Authentication rules are used to receive user-identity, based on the values set for protocol and source address. Having said this, if a rule fails to match based on source address, there will be no other attempt to match the rule, however the next policy will be attempted. This occurs only when:

  • there is an authentication rule, but no authentication method has been set (under config authentication scheme; see below), so user identity cannot be found.
  • the user is successfully matched in the rule, but fails to match the current policy.

Once a rule is positively matched through protocol and/or source address, it must also match the authentication method specified (active-auth-method and sso-auth-method). These methods point to schemes, as defined under config authentication scheme.

CLI syntax - config authentication scheme

config authentication scheme

edit <name>

set name <name>

set method {basic|digest|ntlm|form|negotiate|fsso|rsso}

set negotiate-ntlm {enable|disable}

set require-tfa {enable|disable}

set fsso-guest {enable|disable}

config user-database

edit <name>

set name {local|<ldap-server>|<radius-server>|<fsso-name>|<rsso-name>|<tacacs+-name>}

next

end

next

end

Combining authentication rules and schemes, granular control can be exerted over users and IPs, creating an efficient process for users to successfully match a criteria before matching the policy.

Additional options can be set under config authentication setting.

CLI syntax - config authentication setting

config authentication setting

set sso-scheme <scheme-name>

set active-scheme <scheme-name>

set captive-portal <host-name>

set captive-portal-port <tcp-port>

end

Integration of transparent and explicit proxy HTTP policy checking

A CLI command, under config firewall profile-protocol-options, allows HTTP policy checking to be enable or disabled. When enabled, transparent traffic can be matched in a firewall policy and policy user authentication can occur. In addition, separate SSL inspection policies can be created:

config firewall profile-protocol-options

edit <name>

set http-policy {enable|disable}

end

Internet Service Database in Explicit/Implicit proxy policies

CLI commands, under config firewall proxy-policy, implement the Internet Service Database (ISDB) as the webproxy matching factor, and override IP pool is also support:

config firewall proxy-policy

edit <name>

set proxy {explicit-web|transparent-web|ftp|wanopt}

set dstintf <dst-name>

set poolname <ip-pool-name>

end

Multiple port/port range support for explicit web and explicit FTP proxy

Multiple port numbers and/or ranges can be set for explicit proxy, specifically for HTTP/HTTPS and FTP. Go to Network > Explicit Proxy and configure settings under Explicit Web Proxy and Explicit FTP Proxy, or under config web-proxy explicit in the CLI Console.

1. General configuration

1.1 Kerberos environment - Windows server setup
  1. Build a Windows 2008 Platform server.
  2. Enable domain configuration in windows server (dcpromo).
  3. Set the domain name TEST.COM (realm name).
1.2 Create users
  • testuser is a normal user (could be any existing domain user account).
  • testfgt is the service name. In this case it should be the FQDN for the explicit proxy Interface, For example the hostname in the client browser proxy config.
  • Recommendation: create username all in lowercase (even if against corporate standards).
  • The account only requires “domain users” membership
  • Password set to never expire
  • Set a very strong password
1.3 Add FortiGate to DNS
tooltip icon Add the FortiGate FQDN in to the Windows DNS domain, as well as in-addr.arpa

For Lab/Testing add the FortiGate Domain name and IP mapping in the hosts file (windows/system32/drivers/etc/hosts). e.g., TESTFGT.TEST.COM 10.10.1.10

1.4 Generate the Kerberos keytab

Use the ktpass command (found on Windows Servers and many domain workstations) to generate the Kerberos keytab.

Example:

ktpass -princ HTTP/<domain name of test fgt>@realm -mapuser testfgt -pass <password> -crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab

note icon In the case where the FortiGate is handling multiple keytabs in Kerberos authentication, use different passwords when generating each keytab.
note icon The ktpass on older Windows servers (i.e. 2003) may not support the “all” crypto option.

Example:

ktpass -princ HTTP/testfgt.test.com@TEST.COM -mapuser testfgt -pass 12345678 -crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab

note icon The realm name is always presented in uppercase, and prefixed with the “@” character.
1.5 Encode base64

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

Example:

base64 fgt.keytab > fgt.txt

note icon Use Notepad++ or some native Linux text editor. Windows Notepad and Wordpad are likely to introduce errors.

2. FortiGate configuration

2.1 Create LDAP server instance

config user ldap

edit "ldap" <<< Required for authorization

set server "10.10.1.1" <<< LDAP server IP, normally it should be same as KDC server

set cnid "cn"

set dn "dc=test,dc=com"

set type regular

set username "CN=admin,CN=Users,DC=test,DC=com" <<< Your domain may require STARTTLS

set password <FOOS>

next

end

2.2 Define Kerberos as an authentication service

config user krb-keytab

edit "http_service"

set principal "HTTP/testfgt.test.com@TEST.COM" <<< Same as the principal name in 1.4

set ldap-server "ldap" <<< the defined ldap server for authoriztion

set keytab "BQIAAABNAAIACkJFUkJFUi5DT00ABEhUVFAAGlRPTllfRkdUXzEwMERfQS5CRVJCRVIuQ09NAAAAAQAAAAAKABcAEJQl0MHqovwplu7XzfENJzw=" <<< base64 endoding keytab data, created in step 1.5

next

end

2.3 Create user group(s)

config user group <<< the group is used for kerberos authentication

edit "testgrp"

set member "ldap"

config match

edit 1

set server-name "ldap" <<< Same as ldap-server option in krb-keytab

set group-name "CN=Domain Users,CN=Users,DC=TEST,DC=com"

next

end

next

end

2.4 Create firewall policy

config firewall proxy-policy

edit 1

set uuid 5e5dd6c4-952c-51e5-b363-120ad77c1414

set proxy explicit-web

set dstintf "port1"

set srcaddr "all"

set dstaddr "all"

set service "webproxy"

set action accept

set schedule "always"

set groups "CN=USERS LAB.PS FSSO"

next

end

2.5 Diagnostics

Once the keytab is imported, check that it has been properly decoded. The filename generated will be relatively random, but should be clearly visible.

Artoo-Deetoo (root) # fnsysctl ls -la /tmp/kt
drwxr--r-- 2 0 0 Fri Dec 2 10:06:43 2016 60 .
drwxrwxrwt 22 0 0 Tue Dec 6 14:28:29 2016 3280 ..
-rw-r--r-- 1 0 0 Fri Dec 2 10:06:43 2016 392 1.0.89.keytab
note icon If there is no file present, then the file hasn’t decoded. Check the file for line feeds and try again.

3. Client side walkthrough

3.1 Check Kerberos is working

Log on to the domain by using testuser, created in 1.2. Use the klist command to list ticket information. In the below example, the client has received krbtgt, CIFS, and LDAP tickets. As there has been no interaction with the FortiGate, there are no references to it.

C:\Users\glenk>klist Cached Tickets: (5)
C:\Users\glenk>klist
Cached Tickets: (5)
#0> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent

Start Time: 12/6/2016 14:58:04 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#2> Client: glenk @ home.local

Server: cifs/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#3> Client: glenk @ home.local

Server: ldap/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#4> Client: glenk @ home.local

Server: LDAP/EthicsGradient.home.local/home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

3.2 Configure client

Set up web-proxy in browser through the FortiGate. This can be achieved via a PAC file or direct browser configuration.

note icon Some Firefox documentation indicates that it is necessary to make manual advanced configuration changes to allow Kerberos authentication work. However, builds 48 (and possibly much earlier) require no additional configuration beyond setting of the proxy server.
3.3 Open a connection to the Internet
  1. The client accesses the explicit proxy, but a HTTP 407 Proxy Authentication Required is returned.
  2. As “Negotiate” is set, the client has knowledge of the KRBTGT, it requests a ticket from the KDC with a krb-tgs-req message. This includes the REALM (HOME.LOCAL) in the reg-body section, and the provided instances SNAME and service (in this case, HTTP/artoo-deetoo.home.local).
  3. The KDC responds with a next KRB-TGS-REP.
  4. This ticket is then available on the client.

    In the example below, the ticket-granted-service has issued Ticket #2.

    #2> Client: glenk @ home.local

    Server: HTTP/artoo-deetoo.home.local @ HOME.LOCAL

    KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

    Ticket Flags 0x40a00000 -> forwardable renewable pre_authent

    Start Time: 12/6/2016 14:59:45 (local)

    End Time: 12/7/2016 0:58:04 (local)

    Renew Time: 12/13/2016 14:58:04 (local)

    Session Key Type: RSADSI RC4-HMAC(NT)

  5. The conversation between the client and the proxy continues, as the client responds with the Kerberos ticket in the response.
  6. The whole process takes less than a second to complete. The user should be visible as a FSSO logon in the Web UI.

Transparent web-proxy Kerberos authentication

Transparent web-proxy allows the FortiGate to process level 7 policy matching, even when the explicit web-proxy is not enabled on the client's browser. The transparent web-proxy policy is set in proxy-policy too. The policy matching rule is the same as the explicit web-proxy.

In the firewall policy level, transparent web-proxy is regarded as a special UTM. The HTTP/HTTPS traffic matches the firewall policy first, then traffic is redirected to the web-proxy daemon. If the transparent web-proxy feature is disabled, http-policy options in profile-protocol-options is used to enable transparent web-proxy feature.

IP-based

Kerberos authentication requires the captive portal to be an FQDN address that is resolved to a local IP address. However, it becomes more complicated to setup an FQDN address in a local user deployment. Therefore you can set the captive-portal-type to either use an FQDN or IP address.

  1. Captive portal and the captive portal port must be configured in transparent web-proxy for support of Kerberos authentication:

    config authentication setting

    set captive-portal-type {fqdn | ip}

    set captive-portal <fqdn-name> / <ip>

    set captive-portal-port "9998"

    end

  2. Authentication rule, scheme, and krb-keytab need to be configured for Kerberos authentication (note the active-auth-method scheme referenced in the rule):

    config authentication scheme

    edit <kerberos-scheme>

    set method negotiate

    set negotiate-ntlm <enable>

    set fsso-guest <disable>

    end

    config authentication rule

    edit <name>

    set status <enable>

    set protocol <http>

    set srcadrr "all"

    set ip-based <enable>

    set active-auth-method <kerberos-scheme>

    end

    config user krb-keytab

    edit <name>

    set principal "HTTP/TESTFGT.TEST.COM@TEST.COM"

    set ldap-server "ldap"

    set keytab <base64-encoding-keytab-data>

    end

  3. Configure LDAP and user group used for authorization:

    config user ldap

    edit "ldap"

    set server "10.10.1.1"

    set cnid

    srt dn

    set type <regular>

    set username "CN=admin,CN=Users,DC=test,DC=com"

    set password ENC <encrypted-password>

    end

    config user group

    edit "testgrp"

    set memeber "ldap"

    config match

    edit "1"

    set server-name "ldap"

    set group-name "CN=Domain Users,CN=Users,DC=TEST,DC=com"

    end

  4. Create proxy-policy, with groups as the authorizing policy-matching element:

    config firewall proxy-policy

    edit 1

    set uuid 1bbb891a-9cd2-51e7-42ff-d1fa13cac3da

    set proxy explicit-web

    set dstintf "any"

    set srcaddr "all"

    set dstaddr "all"

    set service "webproxy"

    set action accept

    set schedule "always"

    set groups testgrp

    end

  5. UTM must be enabled in the firewall policy to support the transparent web-proxy:

    config firewall policy

    edit "1"

    set name "policy1"

    set uuid 8a6ceeac-b016-51e6-2b5c-165070d5bf50

    set srcintf "mgmt1"

    set dstintf "mgmt1"

    set srcaddr "all"

    set dstaddr "all"

    set action <accept>

    set schedule "always"

    set service "ALL"

    set utm-status <enable>

    set profile-protocol-options "transparent-web-proxy"

    set ssl-ssh-profile "deep-inspection"

    set nat <enable>

    end

    config firewall profile-protocol-options

    edit "transparent-web-proxy"

    config http

    set ports "80 8080"

    unset options

    set http-policy enable

    unset post-lang

    end

    ...

    end

Session-based with web-auth cookie

The web-auth-cookie feature is necessary for session-based authentication under transparent web-proxy.

The configuration is the same as for IP-based authentication, except ip-based is disabled in the authentication rule:

config authentication rule

edit "kerberos-rules"

set status <enable>

set protocol <http>

set srcadrr "all"

set ip-based <disable>

set active-auth-method <kerberos-scheme>

next

config authentication setting

set captive-portal <fqdn-name>

set captive-portal-port "9998"

end