Configuring authenticated access

When you have configured authentication servers, users, and user groups, you are ready to configure security policies and certain types of VPNs to require user authentication.

This section describes:

• Authentication timeout
• Password policy
• Authentication protocols
• Authentication in captive portals
• Authentication in security policies
• Authentication replacement messages
• VPN authentication

Authentication timeout

An important feature of the security provided by authentication is that it is temporary—a user must re-authenticate after logging out. Also if a user is logged on and authenticated for an extended period of time, it is a good policy to have them re-authenticate at set periods. This ensures a user’s session is cannot be spoofed and used maliciously for extended periods of time — re-authentication will cut any spoof attempts short. Shorter timeout values are more secure.

Security authentication timeout

You set the security user authentication timeout to control how long an authenticated connection can be idle before the user must authenticate again. The maximum timeout is 1440 minutes (24 hours).

To set the security authentication timeout - web-based manager:

1. Go to User & Device > Authentication Settings.
2. Enter the Authentication Timeout value in minutes.
   The default authentication timeout is 5 minutes.
3. Select Apply.

SSL VPN authentication timeout

You set the SSL VPN user authentication timeout (Idle Timeout) to control how long an authenticated connection can be idle before the user must authenticate again. The maximum timeout is 259 200 seconds. The default timeout is 300 seconds.

To set the SSL VPN authentication timeout - web-based manager:

1. Go to VPN > SSL-VPN Settings.
2. Enable Idle Logout and enter the Inactive For value in seconds.
3. Select Apply.

Password policy

Password authentication is effective only if the password is sufficiently strong and is changed periodically. By default, the FortiGate unit requires only that passwords be at least eight characters in length, but up to 128 characters is permitted. You can set a password policy to enforce higher standards for both length and complexity of passwords. Password policies can apply to administrator passwords or IPsec VPN pre-shared keys.

To set a password policy in the web-based manager, go to System > Settings. In the CLI, use the config system password-policy command.

Users usually create passwords composed of alphabetic characters and perhaps some numbers. Password policy can require the inclusion of uppercase letters, lowercase letters, numerals or punctuation characters.

Configuring password minimum requirement policy

Best practices dictate that passwords include:

• one or more uppercase characters
• one or more lower case characters
• one or more of the numerals
• one or more special characters.

The minimum number of each of these types of characters can be set in both the web-based manager and the CLI.

The following procedures show how to force administrator passwords to contain at least two uppercase, four lower care, two digits, and one special character. Leave the minimum length at the default of eight characters.

To change administrator password minimum requirements - web-based manager:

1. Go to System > Settings.
2. Select Enable Password Policy.
3. Select Must Contain at Least.
4. Enter the following information:

Upper Case Letters	2
Lower Case Letters	4
Numbers	2
Special Characters	1

5. Under Apply Password Policy to, select Administrator Password.
6. Select Apply.

To change administrator password minimum requirements - CLI:

config system password-policy

set status enable

set apply-to admin-password

set min-upper-case-letter 2

set min-lower-case-letter 4

set min-number 2

set min-non-alphanumeric 1

set change-4-characters enable

end

 

The change-4-characters option forces new passwords to change a minimum of four characters in the old password. Changing fewer characters results in the new password being rejected. This option is only available in the CLI.

To configure a guest administrator password policy - CLI:

As of FortiOS 5.4, a password policy can also be created for guest administrators. The following command shows all possible commands, which are also available under config system password-policy.

config system password-policy

set status {enable | disable} Enable/disable password policy.

set apply-to {guest-admin-password} Guest admin to which this password policy applies.

set minimum-length <8-128> Minimum password length.

set min-lower-case-letter <0-128> Min. lowercase characters in password.

set min-upper-case-letter <0-128> Min. uppercase characters in password.

set min-non-alphanumeric <0-128> Min. non-alphanumeric characters in password.

set min-number <0-128> Min. numeric characters in password.

set change-4-characters {enable | disable} Enable/disable changing at least 4 characters for new password.

set expire-status {enable | disable} Enable/disable password expiration.

set expire-day <1-999> Number of days before password expires.

set reuse-password {enable | disable} Enable/disable reuse of password.

end

Password best practices

In addition to length and complexity, there are security factors that cannot be enforced in a policy. Guidelines issued to users will encourage proper password habits.

Best practices dictate that password expiration also be enabled. This forces passwords to be changed on a regular basis. You can set the interval in days. The more sensitive the information this account has access to, the shorter the password expiration interval should be. For example 180 days for guest accounts, 90 days for users, and 60 days for administrators.

Avoid:

• real words found in any language dictionary
• numeric sequences, such as “12345”
• sequences of adjacent keyboard characters, such as “qwerty”
• adding numbers on the end of a word, such as “hello39”
• adding characters to the end of the old password, such as “hello39” to “hello3900”
• repeated characters
• personal information, such as your name, birthday, or telephone number.

In the case where the FortiGate is handling multiple keytabs in Kerberos authentication, use different passwords when generating each keytab.

Maximum login attempts and blackout period

When you login and fail to enter the correct password you could be a valid user, or a hacker attempting to gain access. For this reason, best practices dictate to limit the number of failed attempts to login before a blackout period where you cannot login.

To set a maximum of five failed authentication attempts before the blackout, using the following CLI command:

config user setting

set auth-invalid-max 5

end

 

To set the length of the blackout period to five minutes, or 300 seconds, once the maximum number of failed login attempts has been reached, use the following CLI command:

config user setting

set auth-blackout-time 300

end

Authentication protocols

When user authentication is enabled on a security policy, the authentication challenge is normally issued for any of the four protocols, HTTP, HTTPS, FTP, and Telnet, which are dependent on the connection protocol. By making selections in the Protocol Support list, the user controls which protocols support the authentication challenge. The user must connect with a supported protocol first, so that they can subsequently connect with other protocols.

For example, if you have selected HTTP, FTP, or Telnet, a username and password-based authentication occurs. The FortiGate unit then prompts network users to input their security username and password. If you have selected HTTPS, certificate-based authentication (HTTPS, or HTTP redirected to HTTPS only) occurs.

FTP and Telnet authentication replacement messages cannot be customized. For HTTP and HTTPS replacement messages see Authentication replacement messages.

For certificate-based authentication, you must install customized certificates on the FortiGate unit and on the browsers of network users. If you do not install certificates on the network user’s web browser, the network users may see an SSL certificate warning message and have to manually accept the default FortiGate certificate. The network user’s web browser may deem the default certificate as invalid.

When you use certificate authentication, if you do not specify any certificate when you create the security policy, the global settings are used. If you specify a certificate, the per-policy setting will overwrite the global setting. For more information about the use of certification authentication see Certificate-based authentication.

To set the authentication protocols

1. Go to User & Device > Authentication Settings.
2. In Protocol Support, select the required authentication protocols.
3. If using HTTPS protocol support, in Certificate, select a Local certificate from the drop-down list.
4. Select Apply.

Authentication in captive portals

Network interfaces, including WiFi interfaces, can perform authentication at the interface level using a captive portal — an HTML form that requests the user’s name and password. A captive portal is useful where all users connecting to the network interface must authenticate. Optionally, on a WiFi interface, the captive portal can be combined with a terms of service disclaimer to which the user must agree before gaining access. For more information, see Captive portals.

Once successfully authenticated, the user’s session passes to the firewall.

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
• Authentication replacement messages
• Access to the Internet
• Configuring authenticated access
• Identity-based policy
• NTLM authentication
• 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:

1. Go to User & Device > Authentication Settings.
2. 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.
3. Select the Certificate to use, for example Fortinet_Factory.
4. 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.
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.
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.
SMS Token page (auth-sms-token-page)	The page prompting a user to enter their SMS token. See SMS.
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 users or user groups. These users or user groups can be authenticated using local authentication, certificates, remote authentication services such as RADIUS or LDAP, RADIUS SSO (RSSO), FSSO, or NTLM. For information about RSSO, see SSO using RADIUS accounting records. For information about FSSO, see Introduction to FSSO agents.

Before creating a security policy, you need to configure one or more users or user groups. For more information, see Users and 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.
	NTLM	See NTLM authentication.
	Certificates	See Configuring certificate-based authentication.
	RADIUS SSO	See SSO using RADIUS accounting records.
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:

1. Go to Network > Interfaces. Either select an existing interface or create a new one.
2. Under Security Mode, select Captive Portal, and enable Customize Portal Messages.
3. Select the Edit icon. 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.

You need to set the logging severity level to Notification when configuring a logging location to record traffic log messages.

To enable logging within an existing security policy - web-based manager:

1. Go to Policy & Objects > IPv4 Policy.
2. Expand to reveal the policy list of a policy.
3. Select the security policy you want to enable logging on and then select Edit.
4. To log all general firewall traffic, select the check box beside Log Allowed Traffic, and choose to enable Security Events or All Sessions.
5. 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.

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.

Types of authentication also available in identity-based policies are

• NTLM authentication
• 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

1. Edit the policy in the CLI to enable NTLM. For example, if the policy ID is 4:
2. Go to Policy & Objects > IPv4 Policy and note the ID number of your FSSO policy.
3. 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.
• 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.

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

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

	In the case where the FortiGate is handling multiple keytabs in Kerberos authentication, use different passwords when generating each keytab.
	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

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

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

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.

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.

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)

 

4. 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.

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>

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

 

 

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 aW5lIAHkPMf4D+ZCKpGMU3x8Fpq0G+7uIbAvpblbXFA5vLfgb4/oRBx+B6R/v+CMCetP84e+Gdz5zEcMyOd3cjoBoIhFrpYJfXhRs4lSEOHezeVXfxwTSf5VJG+F11G/G5RpaY+AE8bortC8MBe7P2/uGQocFHu4Ilulp5I6OJvyk6Ei3hDZMjTd8iPp5IkRJZVVjQ==

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

 

 

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

next

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>

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. See Configuring certificate-based authentication.

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

VPN authentication

All VPN configurations require users to authenticate. Authentication based on user groups applies to:

• SSL VPNs
• PPTP and L2TP VPNs
• an IPsec VPN that authenticates users using dialup groups
• a dialup IPsec VPN that uses XAUTH authentication (Phase 1)

You must create user accounts and user groups before performing the procedures in this section. If you create a user group for dialup IPsec clients or peers that have unique peer IDs, their user accounts must be stored locally on the FortiGate unit. You cannot authenticate these types of users using a RADIUS or LDAP server.

Configuring authentication of SSL VPN users

The general procedure for authenticating SSL VPN users is:

1. Configure user accounts.
2. Create one or more user groups for SSL VPN users.
   
3. Enable SSL VPN.
4. Optionally, set inactivity and authentication timeouts.
5. Configure a security policy with the user groups you created for SSL VPN users.
   See FortiOS Handbook SSL VPN guide.

Configuring authentication timeout

By default, the SSL VPN authentication expires after 8 hours (28 800 seconds). You can change it only in the CLI, and the time entered must be in seconds. The maximum time is 72 hours (259 200 seconds). For example, to change this timeout to one hour, you would enter:

config vpn ssl settings

set auth-timeout 3600

end

If you set the authentication timeout (auth‑timeout) to 0 when you configure the timeout settings, the remote client does not have to re-authenticate unless they log out of the system. To fully take advantage of this setting, the value for idle-timeout has to be set to 0 also, so that the client does not time out if the maximum idle time is reached. If the idle-timeout is not set to the infinite value, the system will log out if it reaches the limit set, regardless of the auth-timeout setting.

Configuring authentication of remote IPsec VPN users

An IPsec VPN on a FortiGate unit can authenticate remote users through a dialup group. The user account name is the peer ID and the password is the pre-shared key.

Authentication through user groups is supported for groups containing only local users. To authenticate users using a RADIUS or LDAP server, you must configure XAUTH settings. See Configuring XAuth authentication.

To configure user group authentication for dialup IPsec - web-based manager:

1. Configure the dialup users who are permitted to use this VPN. Create a user group with Type set to Firewall and add them to it.
   For more information, see Users and user groups
2. Go to VPN > IPsec Wizard, select Remote Access, choose a name for the VPN, and enter the following information.

Incoming Interface	Select the incoming interface name.
Authentication Method	List of authentication methods available for users. Select Pre-shared Key and enter the pre-shared key.
User Group	Select the user group that is to be allowed access to the VPN. The listed user groups contain only users with passwords on the FortiGate unit.

3. Select Next and continue configure other VPN parameters as needed.
4. Select OK.

To configure user group authentication for dialup IPsec - CLI example:

The peertype and usrgrp options configure user group-based authentication.

config vpn ipsec phase1

edit office_vpn

set interface port1

set type dynamic

set psksecret yORRAzltNGhzgtV32jend

set proposal 3des-sha1 aes128-sha1

set peertype dialup

set usrgrp Group1

end

Configuring XAuth authentication

Extended Authentication (XAuth) increases security by requiring additional user authentication information in a separate exchange at the end of the VPN Phase 1 negotiation. The FortiGate unit asks the user for a username and password. It then forwards the user’s credentials (the password is encrypted) to an external RADIUS or LDAP server for verification.

XAuth can be used in addition to or in place of IPsec phase 1 peer options to provide access security through an LDAP or RADIUS authentication server. You must configure a dialup user group whose members are all externally authenticated.

To configure authentication for a dialup IPsec VPN - web-based manager:

1. Configure the users who are permitted to use this VPN. Create a user group and add the users to the group.
   For more information, see Users and user groups.
2. Go to VPN > IPsec Wizard, select Remote Access, choose a name for the VPN, and enter the following information.

Incoming Interface	Select the incoming interface name.
Authentication Method	List of authentication methods available for users. Select Pre-shared Key and enter the pre-shared key.
User Group	Select the user group that is to be allowed access to the VPN. The listed user groups contain only users with passwords on the FortiGate unit.

3. Select Next and continue configure other VPN parameters as needed.
4. Select OK.
5. Go to VPN > IPsec Tunnels, edit the Tunnel just created, select Convert To Custom Tunnel, and edit XAUTH as following:

Type	Select PAP, CHAP, or AUTO. Use CHAP whenever possible. Use PAP with all implementations of LDAP and with other authentication servers that do not support CHAP, including some implementations of Microsoft RADIUS. Use AUTO with the Fortinet Remote VPN Client and where the authentication server supports CHAP but the XAuth client does not.
User Group	Select the user group that is to have access to the VPN. The list of user groups does not include any group that has members whose password is stored on the FortiGate unit.

6. Select OK.

For more information about XAUTH configuration, see the IPsec VPN chapter of the FortiOS Handbook.

To configure authentication for a dialup IPsec VPN - CLI example:

The xauthtype and authusrgrp fields configure XAuth authentication.

config vpn ipsec phase1

edit office_vpn

set interface port1

set type dynamic

set psksecret yORRAzltNGhzgtV32jend

set proposal 3des-sha1 aes128-sha1

set peertype dialup

set xauthtype pap

set usrgrp Group1

end

 

Some parameters specific to setting up the VPN itself are not shown here. For detailed information about configuring IPsec VPNs, see the FortiOS Handbook IPsec VPN guide.

Configuring authentication of PPTP VPN users and user groups

Configuration of a PPTP VPN is possible only through the CLI. You can configure user groups and security policies using either CLI or web-based manager.

LDAP user authentication is supported for PPTP, L2TP, IPsec VPN, and firewall authentication. However, with PPTP, L2TP, and IPsec VPN, PAP (Packet Authentication Protocol) is supported, while CHAP (Challenge Handshake Authentication Protocol) is not.

To configure authentication for a PPTP VPN

1. Configure the users who are permitted to use this VPN. Create a security user group and add them to it.
   For more information, see Users and user groups.
2. Configure the PPTP VPN in the CLI as in this example.

config vpn pptp

set status enable

set sip 192.168.0.100

set eip 192.168.0.110

set usrgrp PPTP_Group

end

The sip and eip fields define a range of virtual IP addresses assigned to PPTP clients.

Configure a security policy. The source interface is the one through which the clients will connect. The source address is the PPTP virtual IP address range. The destination interface and address depend on the network to which the clients will connect. The policy action is ACCEPT.

Configuring authentication of L2TP VPN users/user groups

Configuration of a L2TP VPN is possible only through the CLI. You can configure user groups and security policies using either CLI or web-based manager.

LDAP user authentication is supported for PPTP, L2TP, IPsec VPN, and firewall authentication. However, with PPTP, L2TP, and IPsec VPN, PAP (Packet Authentication Protocol) is supported, while CHAP (Challenge Handshake Authentication Protocol) is not.

To configure authentication for a L2TP VPN

1. Configure the users who are permitted to use this VPN. Create a user group and add them to it.
   For more information, see Users and user groups.
2. Configure the L2TP VPN in the CLI as in this example.

config vpn l2tp

set status enable

set sip 192.168.0.100

set eip 192.168.0.110

set usrgrp L2TP_Group

end

The sip and eip fields define a range of virtual IP addresses assigned to L2TP clients.

3. Configure a security policy. The source interface is the one through which the clients will connect. The source address is the L2TP virtual IP address range. The destination interface and address depend on the network to which the clients will connect. The policy action is ACCEPT.