Authentication in security policies
Security policies control traffic between FortiGate interfaces, both physical interfaces and VLAN subinterfaces. The firewall tries to match the session’s user or group identity, device type, destination, or other attribute to a security policy. When a match is found, the user connects to the requested destination. If no security policy matches, the user is denied access.
A user who has not already been authenticated by a captive portal, FSSO, or RSSO can match only policies where no user or user group is specified. If no such policy exists, the firewall requests authentication. If the user can authenticate and the session can be matched to a policy, the user connects to the requested destination, otherwise, the user is denied access. This section includes:
- Enabling authentication protocols l Authentication replacement messages l Access to the Internet l Configuring authentication security policies l Identity-based policy l NTLM authentication l Certificate authentication
- Restricting number of concurrent user logins
Enabling authentication protocols
Users can authenticate using FTP, HTTP, HTTPS, and Telnet. However, these protocols must be enabled first.
Another authentication option is to redirect any attempts to authenticate using HTTP to a more secure channel that uses HTTPS. This forces users to a more secure connection before entering their user credentials.
To enable support for authentication protocols – web-based manager:
- Go to User & Device > Authentication Settings.
- Select one or more of HTTP, HTTPS, FTP, Telnet, or Redirect HTTP Challenge to a Secure Channel (HTTPS). Only selected protocols will be available for use in authentication.
- Select the Certificate to use, for example Fortinet_Factory.
- Select Apply.
To enable support for authentication protocols – CLI:
config user setting set auth-type ftp http https telnet set auth-cert Fortinet_Factory
end
As of FortiOS 5.4, the Fortinet_Factory certificate has been re-signed with an expiration date of 2038. It is used instead of Fortinet_ Factory2, which has been removed.
Authentication replacement messages
A replacement message is the body of a web page containing a message about a blocked website message, a file too large message, a disclaimer, or even a login page for authenticating. The user is presented with this message instead of the blocked content.
Authentication replacement messages are the prompts a user sees during the security authentication process such as login page, disclaimer page, and login success or failure pages. These are different from most replacement messages because they are interactive requiring a user to enter information, instead of simply informing the user of some event as other replacement messages do.
Replacement messages have a system-wide default configuration, a per-VDOM configuration, and disclaimers can be customized for multiple security policies within a VDOM.
These replacement messages are used for authentication using HTTP and HTTPS. Authentication replacement messages are HTML messages. You cannot customize the security authentication messages for FTP and Telnet.
The authentication login page and the authentication disclaimer include replacement tags and controls not found on other replacement messages.
More information about replacement messages can be found in the config system replacemsg section of the FortiOS CLI Reference.
List of authentication replacement messages
| Replacement message name (CLI name) |
Description |
| Login challenge page
(auth-challenge-page) |
This HTML page is displayed if security users are required to answer a question to complete authentication. The page displays the question and includes a field in which to type the answer. This feature is supported by RADIUS and uses the generic RADIUS challenge-access auth response. Usually, challenge-access responses contain a Reply-Message attribute that contains a message for the user (for example, “Please enter new PIN”). This message is displayed on the login challenge page. The user enters a response that is sent back to the RADIUS server to be verified.
The Login challenge page is most often used with RSA RADIUS server for RSA SecurID authentication. The login challenge appears when the server needs the user to enter a new PIN. You can customize the replacement message to ask the user for a SecurID PIN.
This page uses the %%QUESTION%% tag. |
| Disclaimer page
(auth-disclaimer-page-1)
(auth-disclaimer-page-2)
(auth-disclaimer-page-3) |
This page prompts user to accept the displayed disclaimer when leaving the captive portal to access Internet resources. It is displayed when the captive portal type is Authentication and Disclaimer or Disclaimer Only.
In the CLI, the auth-disclaimer-page-2 and auth-disclaimer-page-3 pages seamlessly extend the size of the disclaimer page from 8 192 characters to 16 384 and 24 576 characters respectively. In the web-based manager this is handled automatically.
See Disclaimer on page 84. |
| Email token page
(auth-email-token-page) |
The page prompting a user to enter their email token. See Email on page
1. |
| FortiToken page
(auth-fortitoken-page) |
The page prompting a user to enter their FortiToken code. See FortiToken on page 56. |
| Replacement message name (CLI name) |
Description |
| Keepalive page
(auth-keepalive-page) |
The HTML page displayed with security authentication keepalive is enabled using the following CLI command:
config system globalset auth-keepalive enable end
Authentication keepalive keeps authenticated firewall sessions from ending when the authentication timeout ends. In the web-based manager, go to User & Device > Authentication Settings to set the Authentication Timeout.
This page includes %%TIMEOUT%%. |
| Login failed page
(auth-login-failed-page) |
The Disclaimer page replacement message does not re-direct the user to a redirect URL or the security policy does not include a redirect URL. When a user selects the button on the disclaimer page to decline access through the FortiGate unit, the Declined disclaimer page is displayed. |
| Login page
(auth-login-page) |
The authentication HTML page displayed when users who are required to authenticate connect through the FortiGate unit using HTTP or HTTPS.
Prompts the user for their username and password to login.
This page includes %%USERNAMEID%% and %%PASSWORDID%% tags. |
| Declined disclaimer page
(auth-reject-page) |
The page displayed if a user declines the disclaimer page. See Disclaimer on page 84. |
| SMS Token page
(auth-sms-token-page) |
The page prompting a user to enter their SMS token. See SMS on page 56. |
| Success message
(auth-success-msg) |
The page displayed when a user successfully authenticates. Prompts user to attempt their connection again (as the first was interrupted for authentication). |
Access to the Internet
A policy for accessing the Internet is similar to a policy for accessing a specific network, but the destination address is set to all. The destination interface is the one that connects to the Internet Service Provider (ISP). For general purpose Internet access, the Service is set to ALL.
Access to HTTP, HTTPS, FTP and Telnet sites may require access to a domain name service. DNS requests do not trigger authentication. You must configure a policy to permit unauthenticated access to the appropriate DNS server, and this policy must precede the policy for Internet access. Failure to do this will result in the lack of a DNS connection and a corresponding lack of access to the Internet.
Configuring authentication security policies
To include authentication in a security policy, the policy must specify user groups. A security policy can authenticate by certificate, FSSO, and NTLM. The two exceptions to this are RADIUS SSO and FSSO Agents.
Before creating a security policy, you need to configure one or more users or user groups.
Creating the security policy is the same as a regular security policy except you must select the action specific to your authentication method:
Authentication methods allowed for each policy Action
| Action |
Authentication method |
Where authentication is used |
| ACCEPT |
FSSO Agent or a security policy that specifies an FSSO user group |
Agent-based FSSO on page 147. |
| |
NTLM |
See NTLM authentication on page 86. |
| |
Certificates |
See Configuring certificate-based authentication on page 124. |
| |
RADIUS SSO |
See SSO using RADIUS accounting records on page 192. |
| DENY |
none |
none |
Disclaimer
A WiFi or SSL captive portal can include a disclaimer message presented after the user authenticates. The user must agree to the terms of the disclaimer to access network resources.
Customizing authentication replacement messages
Customizing disclaimers or other authentication replacement messages involves changing the text of the disclaimer message, and possibly the overall appearance of the message.
Changing the disclaimer in System > Replacement Messages is not the same as selecting to customize a disclaimer used in a captive portal. The captive portal location is a customized disclaimer that inherits the default format for the disclaimer message, but then can be customized for this portal.
To customize the disclaimer for a captive portal – web-based manager:
- Go to Network > Interfaces. Either select an existing interface or create a new one.
- Under Security Mode, select Captive Portal, and enable Customize Portal Messages.
- Select the Edit You can select and edit any of the pages. Change your text or layout as needed. Enabling security logging
There are two types of logging that relate to authentication — event logging, and security logging.
When enabled, event logging records system events such as configuration changes, and authentication. To configure event logging, go to Log & Report > Log Settings and enable Event Logging. Select the events you want to log, such as User activity event.
When enabled, security logging will log security profile and security policy traffic.
You must enable logging within a security policy, as well as the options that are applied to a security policy, such as security profiles features. Event logs are enabled within the Event Log page.
For more information on logging, see the FortiOS Log and Reporting guide.
For more information on specific types of log messages, see the FortiOS Log Message Reference.
To enable logging within an existing security policy – web-based manager:
- Go to Policy & Objects > IPv4 Policy.
- Expand to reveal the policy list of a policy.
- Select the security policy you want to enable logging on and then select Edit.
- To log all general firewall traffic, select the check box beside Log Allowed Traffic, and choose to enable Security Events or All Sessions.
- Select OK.
Identity-based policy
An identity-based policy (IBP) performs user authentication in addition to the normal security policy duties. If the user does not authenticate, access to network resources is refused. This enforces Role Based Access Control (RBAC) to your organization’s network and resources.
Identity-based policies also support Single Sign-On operation. The user groups selected in the policy are of the Fortinet Single Sign-On (FSSO) type.
User authentication can occur through any of the following supported protocols, including: HTTP, HTTPS, FTP, and Telnet. The authentication style depends on which of these protocols is included in the selected security services group and which of those enabled protocols the network user applies to trigger the authentication challenge.
For username and password-based authentication (HTTP, FTP, and Telnet) the FortiGate unit prompts network users to enter their username, password, and token code if two-factor authentication is selected for that user account. For certificate-based authentication, including HTTPS or HTTP redirected to HTTPS only, see Certificate authentication on page 96.
With identity-based policies, the FortiGate unit allows traffic that matches the source and destination addresses, device types, and so on. This means specific security policies must be placed before more general ones to be effective.
When the identity-based policy has been configured, the option to customize authentication messages is available. This allows you to change the text, style, layout, and graphics of the replacement messages associated with this firewall policy. When enabled, customizing these messages follows the same method as changing the disclaimer. See Disclaimer on page 84.
Types of authentication also available in identity-based policies are l NTLM authentication l Certificate authentication
NTLM authentication
NT LAN Manager (NTLM) protocol can be used as a fallback for authentication when the Active Directory (AD) domain controller is unreachable. NTLM uses the web browser to send and receive authentication information. See “NTLM” and “FSSO NTLM authentication support”.
To enable NTLM
- Edit the policy in the CLI to enable NTLM. For example, if the policy ID is 4:
- Go to Policy & Objects > IPv4 Policy and note the ID number of your FSSO policy.
- The policy must have an FSSO user group as Source User(s). There must be at least one FSSO Collector agent configured on the FortiGate unit.
config firewall policy edit 4 set ntlm enable
end
NTLM guest access
Guest profile access may be granted to users who fail NTLM authentication, such as visitors who have no user credentials on the network. To allow guest user access, edit the FSSO security policy in the CLI, like this:
config firewall policy edit 4 set ntlm enable set ntlm-guest enable
end
NTLM enabled browsers – CLI
User agent strings for NTLM enabled browsers allow the inspection of initial HTTP-User-Agent values, so that non-supported browsers are able to go straight to guest access without needlessly prompting the user for credentials that will fail. ntlm-guest must be enabled to use this option.
config firewall policy edit 4 set ntlm enable set ntlm-guest enable
set ntlm-enabled-browsers <user_agent_string>
next end
<user_agent_string> is the name of the browser that is NTLM enabled. Examples of these values include “MSIE”, “Mozilla” (which includes FireFox), and “Opera”.
Value strings can be up to 63 characters in length, and may not contain cross site scripting (XSS) vulnerability characters such as brackets. The FortiGate unit prevents use of these characters to prevent exploit of cross site scripting (XSS) vulnerabilities.
Kerberos authentication for explicit web and transparent web 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
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 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.
- 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
- 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
HTTP tunnel authentication
You can trigger user authentication on HTTP CONNECT request at the policy level. A new CLI entry has been added under config firewall proxy-policy which will trigger the authentication process get-user, even when there is no user or group configured.
Note that, as shown below, explicit web proxy must be set.
Syntax
config firewall proxy-policy edit {policyid} set proxy explicit-web
set http-tunnel-auth {enable | disable}
next
end
Certificate authentication
You can configure certificate-based authentication for FortiGate administrators, SSL VPN users, and IPsec VPN users.
Certificates are also inherent to the HTTPS protocol, where the browser validates the server’s identity using certificates. A site certificate must be installed on the FortiGate unit and the corresponding Certificate Authority (CA) certificate installed in the web browser.
To force the use of HTTPS, go to User & Device > Authentication Settings and select Redirect HTTP Challenge to a Secure Channel (HTTPS).
Restricting number of concurrent user logins
Some users on your network may often have multiple account sessions open at one time either to the same network resource or accessing to the admin interface on the FortiGate unit.
While there are valid reasons for having multiple concurrent sessions open, hackers also do this to speed up their malicious work. Often a hacker is making multiple attempts to gain access to the internal network or the admin interface of the FortiGate unit, usually from different IP addresses to appear to the FortiGate unit as legitimate users. For this reason, the more concurrent sessions a hacker has open at once, the faster they will achieve their goal.
To help prevent this, you can disallow concurrent administrative access using the same administrator user name. This allows only one session with the same username even if it is from the same IP.
To disable concurrent administrator sessions – CLI:
config system global set admin-concurrent disable
end
