Explicit Proxy Configuration
The following is information that is specific to Explicit Proxy configuration.
Configuring an external IP address for the IPv4 explicit web proxy
You can use the following command to set an external IP address (or pool) that will be used by the explicit web proxy policy.
config web-proxy explicit set status enable
set outgoing-ip <ip1> <ip2> … <ipN>
end
Configuring an external IP address for the IPv6 explicit web proxy
You can use the following command to set an external IP address (or pool) that will be used by the explicit web proxy policy.
config web-proxy explicit set status enable
set outgoing-ipv6 <ip1> <ip2> … <ipN>
end
Restricting the IP address of the IPv4 explicit web proxy
You can use the following command to restrict access to the explicit web proxy using only one IP address. The IP address that you specify must be the IP address of an interface that the explicit web proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses.
For example, to require uses to connect to the IP address 10.31.101.100 to connect to the explicit web proxy:
config web-proxy explicit set incoming-ip 10.31.101.100
end
Restricting the outgoing source IP address of the IPv4 explicit web proxy
You can use the following command to restrict the source address of outgoing web proxy packets to a single IP address. The IP address that you specify must be the IP address of an interface that the explicit web proxy is Restricting the IP address of the explicit IPv6 web proxy
enabled on. You might want to use this option if the explicit web proxy is enabled on an interface with multiple IP addresses.
For example, to restrict the outgoing packet source address to 172.20.120.100:
config web-proxy explicit set outgoing-ip 172.20.120.100
end
Restricting the IP address of the explicit IPv6 web proxy
You can use the following command to restrict access to the IPv6 explicit web proxy to use only one IP6 IP address. The IPv6 address that you specify must be the IPv6 address of an interface that the explicit web proxy is enabled on. You might want to use this option if the explicit web proxy is enabled on an interface with multiple IPv6 addresses.
For example, to require uses to connect to the IPv6 address 2001:db8:0:2::30 to connect to the explicit IPv6 web proxy:
config web-proxy explicit set incoming-ipv6 2001:db8:0:2::30
end
Restricting the outgoing source IP address of the IPv6 explicit web proxy
You can use the following command to restrict the source address of outgoing web proxy packets to a single IPv6 address. The IP address that you specify must be the IPv6 address of an interface that the explicit web proxy is enabled on. You might want to use this option if the explicit web proxy is enabled on an interface with multiple IPv6 addresses.
For example, to restrict the outgoing packet source address to 2001:db8:0:2::50:
config web-proxy explicit set outgoing-ipv6 2001:db8:0:2::50
end
Explicit proxy firewall address types
Explicit proxy firewall address types improve granularity over header matching for explicit web proxy policies. You can enable this option using the Show in Address List button on the Address and Address Group New/Edit forms under Policy & Objects > Addresses.
The following address types are available:
- URL Pattern – destination address l Host Regex Match – destination address l URL Category – destination address (URL filtering) l HTTP Method – source address l User Agent – source address
Proxy auto-config (PAC) configuration
- HTTP Header – source address l Advanced (Source) – source address (combines User Agent, HTTP Method, and HTTP Header) l Advanced (Destination) – destination address (combines Host Regex Match and URL Category)
Proxy auto-config (PAC) configuration
A proxy auto-config (PAC) file defines how web browsers can choose a proxy server for receiving HTTP content. PAC files include the FindProxyForURL(url, host) JavaScript function that returns a string with one or more access method specifications. These specifications cause the web browser to use a particular proxy server or to connect directly.
To configure PAC for explicit web proxy users, you can use the port that PAC traffic from client web browsers use to connect to the explicit web proxy. explicit web proxy users must configure their web browser’s PAC proxy settings to use the PAC port.
PAC File Content
You can edit the default PAC file from the web-based manager or use the following command to upload a custom PAC file:
config web-proxy explicit set pac-file-server-status enable set pac-file-data <pac_file_str>
end
Where <pac_file_str> is the contents of the PAC file. Enter the PAC file text in quotes. You can copy the contents of a PAC text file and paste the contents into the CLI using this option. Enter the command followed by two sets of quotes then place the cursor between the quotes and paste the file content.
The maximum PAC file size is 256 kbytes. If your FortiGate unit is operating with multiple VDOMs each VDOM has its own PAC file. The total amount of FortiGate memory available to store all of these PAC files 2 MBytes. If this limit is reached you will not be able to load any additional PAC files.
You can use any PAC file syntax that is supported by your users’s browsers. The FortiGate unit does not parse the PAC file.
To use PAC, users must add an automatic proxy configuration URL (or PAC URL) to their web browser proxy configuration. The default FortiGate PAC file URL is:
http://<interface_ip>:<PAC_port_int>/<pac_file_str>
For example, if the interface with the explicit web proxy has IP address 172.20.120.122, the PAC port is the same as the default HTTP explicit web proxy port (8080) and the PAC file name is proxy.pac the PAC file URL would be:
http://172.20.120.122:8080/proxy.pac
From the CLI you can use the following command to display the PAC file URLs:
get web-proxy explicit
Unknown HTTP version
Unknown HTTP version
You can select the action to take when the proxy server must handle an unknown HTTP version request or message. Set unknown HTTP version to Reject or Best Effort. Best Effort attempts to handle the HTTP traffic as best as it can. Reject treats known HTTP traffic as malformed and drops it. The Reject option is more secure.
Authentication realm
You can enter an authentication realm to identify the explicit web proxy. The realm can be any text string of up to 63 characters. If the realm includes spaces enclose it in quotes. When a user authenticates with the explicit web proxy the HTTP authentication dialog includes the realm so you can use the realm to identify the explicitly web proxy for your users.
Implementing Botnet features
The option scan-botnet-connections can be added to an explicit proxy policy.
CLI Syntax:
config firewall proxy-policy edit <policy_id> set scan-botnet-connections [disable|block|monitor]
end where:
l disable means do not scan connections to botnet servers. l block means block connections to botnet servers. l monitor means log connections to botnet servers.
Adding disclaimer messages to explicit proxy policies
This feature allows you to create user exceptions for specific URL categories (including warning messages) based on user groups. The Disclaimer Options are configured under Policy & Objects > Proxy Policy.
You can also configure a disclaimer for each Authentication Rule by setting Action to Authenticate.
Disclaimer explanations
- Disable: No disclaimer (default setting).
- By Domain: The disclaimer will be displayed on different domains. The explicit web proxy will check the referring header to mitigate the javascript/css/images/video/etc page.
- By Policy: The disclaimer will be displayed if the HTTP request matches a different explicit firewall policy. l By User: The disclaimer will be displayed when a new user logs on.
Changing HTTP headers
Changing HTTP headers
You can create explicit web proxy profiles that can add, remove and change HTTP headers. The explicit web proxy profile can be added to a web explicit proxy policy and will be applied to all of the HTTP traffic accepted by that policy.
You can change the following HTTP headers:
- client-ip l via header for forwarded requests l via header for forwarded responses l x-forwarded-for l front-end-https
For each of these headers you can set the action to:
- Pass to forward the traffic without changing the header l Add to add the header l Remove to remove the header
You can also configure how the explicit web proxy handles custom headers. The proxy can add or remove custom headers from requests or responses. If you are adding a header you can specify the content to be included in the added header.
Create web proxy profiles from the CLI:
config web-proxy profile edit <name> set header-client-ip {add | pass | remove} set header-via-request {add | pass | remove} set header-via-response {add | pass | remove} set header-x-forwarded-for {add | pass | remove} set header-front-end-https {add | pass | remove} config headers edit <id> set action {add-to-request | add-to-response | remove-from-request | remove-from-response}
set content <string> set name <name>
end end
Use the following command to add a web proxy profile to an explicit proxy policy:
config firewall proxy-policy edit <id> set webproxy-profile <name>
end
Preventing the explicit web proxy from changing source addresses
By default in NAT/Route mode the explicit web proxy changes the source address of packets leaving the
FortiGate to the IP address of the FortiGate interface that the packets are exiting from. In Transparent mode the
source address is changed to the management IP.
This configuration hides the IP addresses of clients and allows packets to return to the FortiGate unit interface without having to route packets from clients. You can use the following command to configure the explicit web proxy to keep the original client’s source IP address:
config firewall proxy-policy edit 0 set proxy explicit-web set transparent enable
end
Example users on an internal network browsing the Internet through the explicit web proxy with web caching, RADIUS authentication, web filtering, and virus scanning
This example describes how to configure the explicit web proxy for the example network shown below. In this example, users on the internal network connect to the explicit web proxy through the Internal interface of the FortiGate unit. The explicit web proxy is configured to use port 8888 so users must configure their web browser proxy settings to use port 8888 and IP address 10.31.101.100.
Example explicit web proxy network topology
Explicit web proxy users must authenticate with a RADIUS server before getting access to the proxy. The explicit proxy policy that accepts explicit web proxy traffic applies per session authentication and includes a RADIUS server user group. The authentication rule also applies web filtering and virus scanning.
General configuration steps
This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given:
- Enable the explicit web proxy for HTTP and HTTPS and change the HTTP and HTTPS ports to 8888.
- Enable the explicit web proxy on the internal interface.
- Add a RADIUS server and user group for the explicit web proxy.
- Add an authentication explicit proxy policy. Enable web caching. Add an authentication rule and enable antivirus and web filtering.
Preventing the explicit web proxy from changing source addresses
Configuring the explicit web proxy – web-based manager
Use the following steps to configure the explicit web proxy.
To enable and configure the explicit web proxy
- Go to System > Feature Visibility and turn on the Explicit Proxy
- Go to Network > Explicit Proxy and change the following settings:
| Enable Explicit Web Proxy |
Select HTTP/HTTPS. |
| Listen on Interfaces |
No change. This field will eventually show that the explicit web proxy is enabled for the Internal interface. |
| HTTP Port |
8888 |
| HTTPS Port |
0 |
| Realm |
You are authenticating with the explicit web proxy. |
| Default Firewall Policy Action |
Deny |
- Select Apply.
To enable the explicit web proxy on the Internal interface
- Go to Network > Interfaces.
- Edit the internal interface.
- Select Enable Explicit Web Proxy.
- Select OK.
To add a RADIUS server and user group for the explicit web proxy
- Go to User & Device > RADIUS Servers and select Create New to add a new RADIUS server:
| Name |
RADIUS_1 |
| Primary Server Name/IP |
10.31.101.200 |
| Primary Server Secret |
RADIUS_server_secret |
- Select OK.
- Go to User & Device > User Groups and select Create New to add a new user group.
| Name |
Explict_proxy_user_group |
| Type |
Firewall |
| Remote Groups |
RADIUS_1 |
| Group Name |
Any |
- Select OK.
To add an explicit proxy policy
- Go to Policy & Objects > Addresses and select Create New.
- Add a firewall address for the internal network:
| Category |
Address |
| Name |
Internal_subnet |
| Type |
Subnet / IP Range |
| Subnet / IP Range |
10.31.101.0 |
| Interface |
Any |
- Go to Policy & Objects > Proxy Policy and select Create New.
- Configure the explicit web proxy policy.
| Explicit Proxy Type |
Web |
| Source Address |
Internal_subnet |
| Outgoing Interface |
wan1 |
| Destination Address |
all |
| Action |
AUTHENTICATE |
- Under Configure Authentication Rules select Create New to add an authentication rule:
| Groups |
|
Explicit_policy |
| Source User(s) |
|
Leave blank |
| Schedule |
|
always |
- Turn on Antivirus and Web Filter and select the default profiles for both.
- Select the default proxy options profile.
- Select OK.
- Make sure Enable IP Based Authentication is not selected.
- Turn on Web Cache.
- Select OK.
Configuring the explicit web proxy – CLI
Use the following steps to configure the example explicit web proxy configuration from the CLI.
To enable the explicit web proxy on the Internal interface
- Enter the following command to enable the explicit web proxy on the internal interface.
Preventing the explicit web proxy from changing source addresses
config system interface edit internal set explicit-web-proxy enable
end
To enable and configure the explicit web proxy
- Enter the following command to enable the explicit web proxy and set the TCP port that proxy accepts HTTP and HTTPS connections on to 8888.
config web-proxy explicit set status enable set http-incoming-port 8888 set https-incoming-port 8888
set realm “You are authenticating with the explicit web proxy” set sec-default-action deny
end
To add a RADIUS server and user group for the explicit web proxy
- Enter the following command to add a RADIUS server:
config user radius edit RADIUS_1 set server 10.31.101.200 set secret RADIUS_server_secret
end
- Enter the following command to add a user group for the RADIUS server.
config user group edit Explicit_proxy_user_group set group-type firewall set member RADIUS_1
end
To add a security policy for the explicit web proxy
- Enter the following command to add a firewall address for the internal subnet:
config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255
end
- Enter the following command to add the explicit web proxy security policy:
config firewall proxy-policy edit 0 set proxy explicit-web set dstintf wan1 set srcaddr Internal_subnet
set dstaddr all set action accept set service webproxy set webcache enable set identity-based enable set ipbased disable
set active-auth-method basic set groups <User group> end
Testing and troubleshooting the configuration
You can use the following steps to verify that the explicit web proxy configuration is working as expected:
To test the explicit web proxy configuration
- Configure a web browser on the internal subnet to use a web proxy server at IP address 10.31.101.100 and port 8888.
- Browse to an Internet web page.
The web browser should pop up an authentication window that includes the phrase that you added to the Realm option.
- Enter the username and password for an account on the RADIUS server.
If the account is valid you should be allowed to browse web pages on the Internet.
- Close the browser and clear its cache and cookies.
- Restart the browser and connect to the Internet.
You could also start a second web browser on the same PC. Or you could start a new instance of the same browser as long as the browser asks for a user name and password again.
You should have to authenticate again because identity-based policies are set to session-based authentication.
- If this basic functionality does not work, check your FortiGate and web browser configuration settings.
- Browse to a URL on the URL filter list and confirm that the web page is blocked.
- Browse to http://eicar.org and attempt to download an anti-malware test file.
The antivirus configuration should block the file.
Sessions for web-proxy security policies do not appear on the Top Sessions dashboard widget and the count column for security policies does not display a count for explicit web proxy security policies.
- You can use the following command to display explicit web proxy sessions
get test wad 60 IP based users:
Session based users:
user:0x9c20778, username:User1, vf_id:0, ref_cnt:9
Total allocated user:1
Total user count:3, shared user quota:50, shared user count:3
This command output shows one explicit proxy user with user name User1 authenticated using session-based authentication.
Kerberos and NTLM authentication
FortiOS recognizes the client’s authentication method from the token and selects the correct authentication scheme to authenticate successfully.
CLI syntax
config firewall proxy-policy edit 0
set active-auth-method [ntlm|basic|digest|negotiate|none] end
Kerberos authentication for explicit proxy users
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. l Requires fewer round-trips than NTLM SSO, making it less latency sensitive.
- Is (probably) more scalable than challenge response. l Uses existing Windows domain components rather than added components. l NTLM may still be used as a fallback for non-Kerberos clients.
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:
l there is an authentication rule, but no authentication method has been set (under config authentication scheme; see below), so user identity cannot be found. l 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
- Build a Windows 2008 Platform server.
- Enable domain configuration in windows server (dcpromo).
- 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. l Recommendation: create username all in lowercase (even if against corporate standards).
- The account only requires “domain users” membership l Password set to never expire l Set a very strong password
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
- 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
Example:
ktpass -princ HTTP/testfgt.test.com@TEST.COM -mapuser testfgt -pass 12345678 -crypto all ptype KRB5_NT_PRINCIPAL -out fgt.keytab
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
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
“BQIAAABNAAIACkJFUkJFUi5DT00ABEhUVFAAGlRPTllfRkdUXzEwMERfQS5CRVJCRVIuQ09NAAAAAQA
AAAAKABcAEJQl0MHqovwplu7XzfENJzw=” <<< 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
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.
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
- The client accesses the explicit proxy, but a HTTP 407 Proxy Authentication Required is returned.
- As “Negotiate” is set, the client has knowledge of the KRBTGT, it requests a ticket from the KDC with a krb-tgsreq 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).
- The KDC responds with a next KRB-TGS-REP.
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)
- 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. The user should be visible as a FSSO logon in the Web UI.
Transparent web-proxy Kerberos authentication
Transparent web-proxy is new to FortiOS 5.6, in which the FortiGate can 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 trasnparent web-proxy feature is disabled, http-policy options in profile-protocol-options is used to enable transparent web-proxy feature.
IP-based
- 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 <fqdn-name> set captive-portal-port “9998”
end
- 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>
next
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>
next
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>
next
end
- 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 aW5lIAHkPMf4D+ZCKpGMU3x8Fpq0G+7uIbAvpblbXFA5vLfgb4/oRBx+B6R/v+CMCetP84e+Gdz5zEcM yOd3cjoBoIhFrpYJfXhRs4lSEOHezeVXfxwTSf5VJG+F11G/G5RpaY+AE8bortC8MBe7P2/uGQocFHu4
Ilulp5I6OJvyk6Ei3hDZMjTd8iPp5IkRJZVVjQ== next
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”
next
end
next
end
- 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
next
end
- 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>
next
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 …
next
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
