Managing Guest Access

Visitors to your premises might need user accounts on your network for the duration of their stay. If you are hosting a large event such as a conference, you might need to create many such temporary accounts. The FortiOS Guest Management feature is designed for this purpose.

A guest user account User ID can be the user’s email address, a randomly generated string, or an ID that the administrator assigns. Similarly, the password can be administrator-assigned or randomly generated.

You can create many guest accounts at once using randomly-generated User IDs and passwords. This reduces administrator workload for large events.

User’s view of guest access

1. The user receives an email, SMS message, or printout from a FortiOS administrator listing a User ID and password.
2. The user logs onto the network with the provided credentials.
3. After the expiry time, the credentials are no longer valid.

Administrator’s view of guest access

1. Create one or more guest user groups.

All members of the group have the same characteristics: type of User ID, type of password, information fields used, type and time of expiry.

2. Create guest accounts using Guest Management.
3. Use captive portal authentication and select the appropriate guest group.

Configuring guest user access

To set up guest user access, you need to create at least one guest user group and add guest user accounts. Optionally, you can create a guest management administrator whose only function is the creation of guest accounts in specific guest user groups. Otherwise, any administrator can do guest management.

Creating guest management administrators

To create a guest management administrator

1. Go to System > Administrators and create a regular administrator account. For detailed information see the System Administration
2. Select Restrict to Provision Guest Accounts.
3. In Guest Groups, add the guest groups that this administrator manages.

Creating guest user groups

The guest group configuration determines the fields that are provided when you create a guest user account.

Configuring guest user access

To create a guest user group:

1. Go to User & Device > User Groups and select Create New.
2. Enter the following information:

Creating guest user accounts

Guest user accounts are not the same as local user accounts created in User & Device > User Definition. Guest accounts are not permanent; they expire after a defined time period. You create guest accounts in User & Device > Guest Management.

To create a guest user account

1. Go to User & Device > Guest Management.
2. In Guest Groups, select the guest group to manage.
3. Select Create New and fill in the fields in the New User

Fields marked Optional can be left blank. The guest group configuration determines the fields that are available.

4. Select OK.

To create multiple guest user accounts automatically

1. Go to User & Device > Guest Management.
2. In Guest Groups, select the guest group to manage.

The guest group must have the Enable Batch Guest Account Creation option enabled.

3. Select Create New > Multiple Users.

Use the down-pointing caret to the right of Create New.

4. Enter Number of Accounts.
5. Optionally, change the Expiration.
6. Select OK.

Guest Management Account List

Go to User & Device > Guest Management to create, view, edit or delete guest user accounts.

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

Authentication timeout

An important feature of the security provided by authentication is that it is temporary—a user must reauthenticate 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 4320 minutes (72 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. Under Idle Logout, make sure that Logout users when inactive for specified period is enabled and enter

Password policy

the Inactive For value (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 preshared 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:

l one or more uppercase characters l one or more lower case characters l one or more of the numerals l 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:

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

Password policy

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 l numeric sequences, such as “12345” l sequences of adjacent keyboard characters, such as “qwerty” l adding numbers on the end of a word, such as “hello39” l adding characters to the end of the old password, such as “hello39” to “hello3900” Authentication protocols
• repeated characters l personal information, such as your name, birthday, or telephone number.

Maximum logon attempts and blackout period

When you logon 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 logon before a blackout period where you cannot logon.

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 logon 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 on page 84.

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 on page 107.

To set the authentication protocols

1. Go to User & Device > Authentication Settings.
2. In Protocol Support, select the required authentication protocols.

in Captive Portals

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 on page 99.

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, etcetera 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 logons

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 webpage 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

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. See SSO using RADIUS accounting records on page 186, and Introduction to FSSO agents on page 143.

Before creating a security policy, you need to configure one or more users or user groups. For more information, see Users and user groups on page 53.

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

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 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:

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 on page 94.

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

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

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 proxy users

Kerberos authentication is a new method for authenticating explicit 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.

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. 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
  • Add FortiGate to DNS

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

• 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

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 gorup(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

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

Certificate authentication

You can configure certificate-based authentication for FortiGate administrators, SSL VPN users, and IPsec VPN users. See Configuring certificate-based authentication on page 120.

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 logons

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: l SSL VPNs l PPTP and L2TP VPNs

VPN authentication

l an IPsec VPN that authenticates users using dialup groups l 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:Firewall and add them to it.

For more information, see Users and user groups on page 53

2. Go to VPN > IPsec Wizard, select Remote Access, choose a name for the VPN, and enter the following information.

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” on page 53.
2. Go to VPN > IPsec Wizard, select Remote Access, choose a name for the VPN, and enter the following information.

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

VPN authentication

5. Go to VPN > IPsec Tunnels, edit the Tunnel just created, select Convert To Custom Tunnel, and edit XAUTH as following:

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 on page 53.
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 on page 53.
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.

Captive portals

A captive portal is a convenient way to authenticate web users on wired or WiFi networks.

This section describes:

• Introduction to Captive portals
• Configuring a captive portal
• Customizing captive portal pages

Introduction to Captive portals

You can authenticate your users on a web page that requests the user’s name and password. Until the user authenticates successfully, the authentication page is returned in response to any HTTP request. This is called a captive portal.

After successful authentication, the user accesses the requested URL and can access other web resources, as permitted by security policies. Optionally, the captive portal itself can allow web access to only the members of specified user group.

The captive portal can be hosted on the FortiGate unit or on an external authentication server. You can configure captive portal authentication on any network interface, including WiFi and VLAN interfaces.

When a captive portal is configured on a WiFi interface, the access point initially appears open. The wireless client can connect to the access point with no security credentials, but sees only the captive portal authentication page.

WiFi captive portal types:

• Authentication — until the user enters valid credentials, no communication beyond the AP is permitted.
• Disclaimer + Authentication — immediately after successful authentication, the portal presents the disclaimer page—an acceptable use policy or other legal statement—to which the user must agree before proceeding.
• Disclaimer Only — the portal presents the disclaimer page—an acceptable use policy or other legal statement— to which the user must agree before proceeding. The authentication page is not presented.
• Email Collection — the portal presents a page requesting the user’s email address, for the purpose of contacting the person in future. This is often used by businesses who provide free WiFi access to their customers. The authentication page is not presented.

Certificate-based authentication

This section provides an overview of how the FortiGate unit verifies the identities of administrators, SSL VPN users, or IPsec VPN peers using X.509 security certificates.

The following topics are included in this section:

What is a security certificate?

• Certificates overview
• Managing X.509 certificates
• Configuring certificate-based authentication
• Support for per-VDOM certificates
• Certificate-based authentication
• Example — Generate and Import CA certificate with private key pair on OpenSSL
• Example — Generate an SSL certificate in OpenSSL

What is a security certificate?

A security certificate is a small text file that is part of a third-party generated public key infrastructure (PKI) to help guarantee the identity of both the user logging on and the web site they where they are logging in.

A certificate includes identifying information such as the company and location information for the web site, as well as the third-party company name, the expiry date of the certificate, and the public key.

FortiGate units use X.509 certificates to authenticate single sign-on (SSO) for users. The X.509 standard has been in use since before 2000, but has gained popularity with the Internet’s increased popularity. X.509 v3 is defined in RFC 5280 and specifies standard formats for public key certificates, certificate revocation lists, and a certification path validation algorithm. The unused earlier X.509 version 1 was defined in RFC 1422.

The main difference between X.509 and PGP certificates is that where in PGP anyone can sign a certificate, for X.509 only a trusted authority can sign certificates. This limits the source of certificates to well known and trustworthy sources. Where PGP is well suited for one-to-one communications, the X.509 infrastructure is intended to be used in many different situations including one-to-many communications. Some common filename extensions for X.509 certificates are listed below.

Certificates overview Common certificate filename extensions

Single Sign-On using a FortiAuthenticator unit

If you use a FortiAuthenticator unit in your network as a single sign-on agent,

• Users can authenticate through a web portal on the FortiAuthenticator unit.
• Users with FortiClient Endpoint Security installed can be automatically authenticated by the FortiAuthenticator unit through the FortiClient SSO Mobility Agent.

The FortiAuthenticator unit can integrate with external network authentication systems such as RADIUS and LDAP to gather user logon information and send it to the FortiGate unit.

User’s view of FortiAuthenticator SSO authentication

There are two different ways users can authenticate through a FortiAuthenticator unit.

Users without FortiClient Endpoint Security – SSO widget

To log onto the network, the user accesses the organization’s web page with a web browser. Embedded on that page is a simple logon widget, like this:

The SSO widget sets a cookie on the user’s browser. When the user browses to a page containing the login widget, the FortiAuthenticator unit recognizes the user and updates its database if the user’s IP address has changed. The user will not need to re-authenticate until the login timeout expires, which can be up to 30 days.

Users with FortiClient Endpoint Security – FortiClient SSO Mobility Agent

The user simply accesses resources and all authentication is performed transparently with no request for credentials. IP address changes, such as those due to WiFi roaming, are automatically sent to the

FortiAuthenticator unit. When the user logs off or otherwise disconnects from the network, the FortiAuthenticator unit is aware of this and deauthenticates the user.

The FortiClient SSO Mobility Agent, a feature of FortiClient Endpoint Security v5.0, must be configured to communicate with the appropriate FortiAuthenticator unit. After that, the agent automatically provides user name and IP address information to the FortiAuthenticator unit for transparent authentication.

Administrator’s view of FortiAuthenticator SSO authentication

You can configure either or both of these authentication types on your network.

You need to configure the Single Sign-On portal on the FortiAuthenticator unit. Go to Fortinet SSO Methods > SSO > Portal Services to do this. Copy the Embeddable login widget code for use on your organization’s home page. Identity-based security policies on the FortiGate unit determine which users or groups of users can access which network resources.

FortiClient SSO Mobility Agent

Your users must be running at least FortiClient Endpoint Security v5.0 to make use of this type of authentication.

On the FortiAuthenticator unit, you need to select Enable FortiClient SSO Mobility Agent Service, optionally select Enable Authentication and choose a Secret key. Go to Fortinet SSO Methods > SSO > General. You need to provide your users the FortiAuthenticator IP address and secret key so that they can configure the FortiClient SSO Mobility Agent on their computers. See Configuring the FortiGate unit on page 131.

Single Sign-On to Windows AD

The FortiGate unit can authenticate users transparently and allow them network access based on their privileges in Windows AD. This means that users who have logged on to the network are not asked again for their credentials to access network resources through the FortiGate unit, hence the term “Single Sign-On”.

The following topics are included:

• Introduction to Single Sign-On with Windows AD
• Configuring Single Sign On to Windows AD
• FortiOS FSSO log messages
• Testing FSSO
• Troubleshooting FSSO

Introduction to Single Sign-On with Windows AD

Introduced in FortiOS 5.0, Single Sign-On (SSO) support provided by FortiGate polling of domain controllers is simpler than the earlier method that relies on agent software installed on Windows AD network servers. No Fortinet software needs to be installed on the Windows network. The FortiGate unit needs access only to the Windows AD global catalog and event log.

When a Windows AD user logs on at a workstation in a monitored domain, the FortiGate unit l detects the logon event in the domain controller’s event log and records the workstation name, domain, and user, l resolves the workstation name to an IP address, l uses the domain controller’s LDAP server to determine which groups the user belongs to, l creates one or more log entries on the FortiGate unit for this logon event as appropriate.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. The selection consist of matching the FSSO group or groups the user belongs to with the security policy or policies that match that group. If the user belongs to one of the permitted user groups associated with that policy, the connection is allowed. Otherwise the connection is denied.

Agent-based FSSO

FortiOS can provide single sign-on capabilities to Windows AD, Citrix, Novell eDirectory, or, as of FortiOS 5.4, Microsoft Exchange users with the help of agent software installed on these networks. The agent software sends information about user logons to the FortiGate unit. With user information such as IP address and user group memberships from the network, FortiGate security policies can allow authenticated network access to users who belong to the appropriate user groups without requesting their credentials again.

For Windows AD networks, FortiGate units can provide SSO capability without agent software by directly polling the Windows AD domain controllers. For information about this type of SSO, seeSingle Sign-On to Windows AD on page 133.

The following topics are included:

• Introduction to agent-based FSSO
• FSSO NTLM authentication support
• Agent installation
• Configuring the FSSO Collector agent for Windows AD
• Configuring the FSSO TS agent for Citrix
• Configuring FSSO with Novell networks
• Configuring FSSO Advanced Settings
• Configuring FSSO on FortiGate units
• FortiOS FSSO log messages
• Testing FSSO
• Troubleshooting FSSO

Introduction to agent-based FSSO

Fortinet Single Sign-On (FSSO), through agents installed on the network, monitors user logons and passes that information to the FortiGate unit. When a user logs on at a workstation in a monitored domain, FSSO

l detects the logon event and records the workstation name, domain, and user, l resolves the workstation name to an IP address, l determines which user groups the user belongs to, l sends the user logon information, including IP address and groups list, to the FortiGate unit l creates one or more log entries on the FortiGate unit for this logon event as appropriate.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups associated with that policy, the connection is allowed. Otherwise the connection is denied.

FSSO can also provide NTLM authentication service for requests coming from FortiGate. SSO is very convenient for users, but may not be supported across all platforms. NTLM is not as convenient, but it enjoys wider support. See FSSO NTLM authentication support on page 148.

Introduction to FSSO agents

There are several different FSSO agents that can be used in an FSSO implementation:

• Domain Controller (DC) agent
• eDirectory agent
• Citrix/Terminal Server (TS) agent
• Collector (CA) agent

Consult the latest FortiOS and FSSO Release Notes for operating system compatibility information.

Domain Controller (DC) agent

The Domain Controller (DC) agent must be installed on every domain controller if you will use DC Agent mode, but is not required if you use Polling mode. See FSSO for Windows AD on page 144.

eDirectory agent

The eDirectory agent is installed on a Novell network to monitor user logons and send the required information to the FortiGate unit. It functions much like the Collector agent on a Windows AD domain controller.The agent can obtain information from the Novell eDirectory using either the Novell API or LDAP.

Citrix/Terminal Server (TS) agent

The Citrix/Terminal Server (TS) agent is installed on a Citrix terminal server to monitor user logons in real time. It functions much like the DC Agent on a Windows AD domain controller.

Collector (CA) agent

This agent is installed as a service on a server in the Windows AD network to monitor user logons and send the required information to the FortiGate unit. The Collector agent can collect information from

• Domain Controller agent (Windows AD)
• TS agent (Citrix Terminal Server)

In a Windows AD network, the Collector agent can optionally obtain logon information by polling the AD domain controllers. In this case, DC agents are not needed.

The Collector can obtain user group information from the DC agent or optionally, a FortiGate unit can obtain group information directly from AD using Lightweight Directory Access Protocol (LDAP).

On a Windows AD network, the FSSO software can also serve NT LAN Manager (NTLM) requests coming from client browsers (forwarded by the FortiGate unit) with only one or more Collector agents installed. See FSSO NTLM authentication support on page 148.

The CA is responsible for DNS lookups, group verification, workstation checks, and as mentioned FortiGate updates of logon records. The FSSO Collector Agent sends Domain Local Security Group and Global Security Group information to FortiGate units. The CA communicates with the FortiGate over TCP port 8000 and it listens on UDP port 8002 for updates from the DC agents.

The FortiGate unit can have up to five CAs configured for redundancy. If the first on the list is unreachable, the next is attempted, and so on down the list until one is contacted. See Configuring FSSO on FortiGate units on page 175.

All DC agents must point to the correct Collector agent port number and IP address on domains with multiple DCs.

A FortiAuthenticator unit can act much like a Collector agent, collecting Windows AD user logon information and sending it to the FortiGate unit. It is particularly useful in large installations with several FortiGate units. For more information, see the FortiAuthenticator Administration Guide.

FSSO for Microsoft Exchange Server

As of FortiOS 5.4, FSSO supports monitoring Microsoft Exchange Server. This is useful for situations when the user accesses the domain account to view their email, even when the client device might not be in the domain.

Support for the Exchange server is configured on the Back-end FSSO collector agent. For more information on the collector agent, see Collector agent installation:

1. On the FSSO collector agent, go to Advanced Settings > Exchange Server.
2. Select Add and enter the following information and select OK:

FSSO for Windows AD

FSSO for Windows AD requires at least one Collector agent. Domain Controller agents may also be required depending on the Collector agent working mode. There are two working modes to monitor user logon activity: DC Agent mode or Polling mode.

Collector agent DC Agent mode versus Polling mode

DC Agent mode

DC Agent mode is the standard mode for FSSO. In DC Agent mode, a Fortinet authentication agent is installed on each domain controller. These DC agents monitor user logon events and pass the information to the Collector agent, which stores the information and sends it to the FortiGate unit.

The DC agent installed on the domain controllers is not a service like the Collector agent — it is a DLL file called dcagent.dll and is installed in the Windows\system32 directory. It must be installed on all domain controllers of the domains that are being monitored.

FSSO in DC agent mode

DC Agent mode provides reliable user logon information, however you must install a DC agent on every domain controller. A reboot is needed after the agent is installed. Each installation requires some maintenance as well. For these reasons it may not be possible to use the DC Agent mode.

Each domain controller connection needs a minimum guaranteed 64kpbs bandwidth to ensure proper FSSO functionality. You can optionally configure traffic shapers on the FortiGate unit to ensure this minimum bandwidth is guaranteed for the domain controller connections.

Introduction to agent-based

Polling mode

In Polling mode there are three options — NetAPI polling, Event log polling, and Event log using WMI. All share the advantages of being transparent and agentless.

NetAPI polling is used to retrieve server logon sessions. This includes the logon event information for the Controller agent. NetAPI runs faster than Event log polling but it may miss some user logon events under heavy system load. It requires a query round trip time of less than 10 seconds.

Event log polling may run a bit slower, but will not miss events, even when the installation site has many users that require authentication. It does not have the 10 second limit on NetAPI polling. Event log polling requires fast network links. Event log polling is required if there are Mac OS users logging into Windows AD.

Event log using WMI polling: WMI is a Windows API to get system information from a Windows server, CA is a WMI client and sends WMI queries for user logon events to DC, which in this case is a WMI server. Main advantage in this mode is that CA does not need to search security event logs on DC for user logon events, instead, DC returns all requested logon events via WMI. This also reduces network load between CA and DC.

In Polling mode, the Collector agent polls port 445 of each domain controller for user logon information every few seconds and forwards it to the FortiGate unit. There are no DC Agents installed, so the Collector agent polls the domain controllers directly.

FSSO in Polling mode

A major benefit of Polling mode is that no FSSO DC Agents are required. If it is not possible to install FSSO DC Agents on your domain controllers, this is the alternate configuration available to you. Polling mode results in a less complex install, and reduces ongoing maintenance. The minimum permissions required in Polling mode are to read the event log or call NetAPI.

Collector agent AD Access mode – Standard versus Advanced

The Collector agent has two ways to access Active Directory user information. The main difference between Standard and Advanced mode is the naming convention used when referring to username information.

Standard mode uses regular Windows convention: Domain\Username. Advanced mode uses LDAP convention: CN=User, OU=Name, DC=Domain.

If there is no special requirement to use LDAP— best practices suggest you set up FSSO in Standard mode. This mode is easier to set up, and is usually easier to maintain and troubleshoot.

Standard and advanced modes have the same level of functionality with the following exceptions:

• Users have to create Group filters on the Collector agent. This differs from Advanced mode where Group filters are configured from the FortiGate unit. Fortinet strongly encourages users to create filters from CA.
• Advanced mode supports nested or inherited groups. This means that users may be a member of multiple monitored groups. Standard mode does not support nested groups so a user must be a direct member of the group being monitored.

FSSO for Citrix

Citrix users can enjoy a similar Single Sign-On experience as Windows AD users. The FSSO TS agent installed on each Citrix server provides user logon information to the FSSO Collector agent on the network. The FortiGate unit uses this information to authenticate the user in security policies.

Citrix SSO topology

Citrix users do not have unique IP addresses. When a Citrix user logs on, the TS agent assigns that user a range of ports. By default each user has a range of 200 ports.

FSSO for Novell eDirectory

FSSO in a Novell eDirectory environment works similar to the FSSO Polling mode in the Windows AD environment. The eDirectory agent polls the eDirectory servers for user logon information and forwards the information to the FortiGate unit. There is no need for the Collector agent.

When a user logs on at a workstation, FSSO:

• detects the logon event by polling the eDirectory server and records the IP address and user ID, l looks up in the eDirectory which groups this user belongs to,

FSSO NTLM authentication support

• sends the IP address and user groups information to the FortiGate unit.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups, the connection is allowed.

FSSO is supported on the Novell E-Directory 8.8 operating system.

For a Novell network, there is only one FSSO component to install — the eDirectory agent. In some cases, you also need to install the Novell Client.

FSSO security issues

When the different components of FSSO are communicating there are some inherent security features.

FSSO installation requires an account with network admin privileges. The security inherent in these types of accounts helps ensure access to FSSO configurations is not tampered with.

User passwords are never sent between FSSO components. The information that is sent is information to identify a user including the username, group or groups, and IP address.

NTLM uses base-64 encoded packets, and uses a unique randomly generated challenge nonce to avoid sending user information and password between the client and the server.

SSO using RADIUS accounting records

A FortiGate unit can authenticate users transparently who have already authenticated on an external RADIUS server. Based on the user group to which the user belongs, the security policy applies the appropriate UTM profiles. RADIUS SSO is relatively simple because the FortiGate unit does not interact with the RADIUS server, it only monitors RADIUS accounting records that the server forwards (originating from the RADIUS client). These records include the user’s IP address and user group.

After the initial set-up, changes to the user database, including changes to user group memberships, are made on the external RADIUS server, not on the FortiGate unit.

This section describes:

• User’s view of RADIUS SSO authentication l Configuration Overview l Configuring the RADIUS server l Creating the FortiGate RADIUS SSO agent l Defining local user groups for RADIUS SSO l Creating security policies
• Example: webfiltering for student and teacher accounts

User’s view of RADIUS SSO authentication

For the user, RADIUS SSO authentication is simple:

• The user connects to the RADIUS server and authenticates.
• The user attempts to connect to a network resource that is reached through a FortiGate unit. Authentication is required for access, but the user connects to the destination without being asked for logon credentials because the FortiGate unit knows that the user is already authenticated. FortiOS applies UTM features appropriate to the user groups that the user belongs to.

Configuration Overview

The general steps to implement RADIUS Single Sign-On are:

1. If necessary, configure your RADIUS server. The user database needs to include user group information and the server needs to send accounting messages.
2. Create the FortiGate RADIUS SSO agent.
3. Define local user groups that map to RADIUS groups.
4. Create a security policy which specifies the user groups that are permitted access.

Configuring the RADIUS server

You can configure FortiGate RSSO to work with most RADIUS-based accounting systems. In most cases, you only need to do the following to your RADIUS accounting system:

• Add a user group name field to customer accounts on the RADIUS server so that the name is added to the RADIUS Start record sent by the accounting system to the FortiOS unit. User group names do not need to be added for all users, only to the accounts of users who will use RSSO feature on the FortiGate unit.
• Configure your accounting system to send RADIUS Start records to the FortiOS unit. You can send the RADIUS Start records to any FortiGate network interface. If your FortiGate unit is operating with virtual domains (VDOMs) enabled, the RADIUS Start records must be sent to a network interface in the management VDOM.

IPv6 RADIUS Support

RADIUS authentication is supported with IPv6, allowing administrators to configure an IPv6 RADIUS server on the FortiGate for IPv6 RADIUS authentication traffic to pass between the server and FortiGate.

Syntax

Allow IPv6 access on an interface:

config system interface edit <name> config ipv6 set ip6-allowaccess {ping | https | ssh | snmp | http | telnet | fgfm | capwap} set ip6-address <xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/xxx>

next

next

end

Configure the IPv6 RADIUS server:

config user radius edit <name> set server <xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx> …

next

end

Monitoring authenticated users

This section describes how to view lists of currently logged-in firewall and VPN users. It also describes how to disconnect users.

The following topics are included in this section:

• Monitoring firewall users
• Monitoring SSL VPN users
• Monitoring IPsec VPN users
• Monitoring users Quarantine

Monitoring firewall users

To monitor firewall users, go to Monitor > Firewall User Monitor.

You can de-authenticate a user by selecting the Delete icon for that entry.

You can filter the list of displayed users by selecting the funnel icon for one of the column titles or selecting Filter Settings.

Optionally, you can de-authenticate multiple users by selecting them and then selecting De-authenticate.

Examples and Troubleshooting

This chapter provides an example of a FortiGate unit providing authenticated access to the Internet for both Windows network users and local users. The following topics are included in this section:

• Firewall authentication example
• LDAP Dial-in using member-attribute example
• RADIUS SSO example
• Troubleshooting

Firewall authentication example

Example configuration

Overview

In this example, there is a Windows network connected to Port 2 on the FortiGate unit and another LAN, Network_1, connected to Port 3.

All Windows network users authenticate when they logon to their network. Members of the Engineering and Sales groups can access the Internet without entering their authentication credentials again. The example assumes that the Fortinet Single Sign On (FSSO) has already been installed and configured on the domain controller.

LAN users who belong to the Internet_users group can access the Internet after entering their username and password to authenticate. This example shows only two users, User1 is authenticated by a password stored on the FortiGate unit, User2 is authenticated on an external authentication server. Both of these users are referred to as local users because the user account is created on the FortiGate unit.

Creating a locally-authenticated user account

User1 is authenticated by a password stored on the FortiGate unit. It is very simple to create this type of account.

To create a local user – web-based manager:

1. Go to User & Device > User Definition and select Create New.
2. Follow the User Creation Wizard, entering the following information and then select Create:

To create a local user – CLI:

config user local edit user1 set type password set passwd hardtoguess

end

Creating a RADIUS-authenticated user account

To authenticate users using an external authentication server, you must first configure the FortiGate unit to access the server.

To configure the remote authentication server – web-based manager:

1. Go to User & Device > RADIUS Servers and select Create New.
2. Enter the following information and select OK:

To configure the remote authentication server – CLI:

config user radius edit OurRADIUSsrv set server 10.11.102.15 set secret OurSecret set auth-type auto

Firewall authentication example

end

Creation of the user account is similar to the locally-authenticated account, except that you specify the RADIUS authentication server instead of the user’s password.

To configure a remote user – web-based manager:

1. Go to User & Device > User Definition and select Create New.
2. Follow the User Creation Wizard, entering the following information and then select Create:

To configure a remote user – CLI:

config user local edit User2 set name User2 set type radius

set radius-server OurRADIUSsrv

end

Creating user groups

There are two user groups: an FSSO user group for FSSO users and a firewall user group for other users. It is not possible to combine these two types of users in the same user group.

Creating the FSSO user group

For this example, assume that FSSO has already been set up on the Windows network and that it uses Advanced mode, meaning that it uses LDAP to access user group information. You need to

• configure LDAP access to the Windows AD global catalog l specify the collector agent that sends user logon information to the FortiGate unit l select Windows user groups to monitor
• select and add the Engineering and Sales groups to an FSSO user group

To configure LDAP for FSSO – web-based manager:

1. Go to User & Device > LDAP Servers and select Create New.
2. Enter the following information:

3. Leave other fields at their default values.
4. Select OK.

To configure LDAP for FSSO – CLI”

config user ldap edit “ADserver” set server “10.11.101.160”

set dn “cn=users,dc=office,dc=example,dc=com”

set type regular

set username “cn=administrator,cn=users,dc=office,dc=example,dc=com” set password set_a_secure_password

next

end

To specify the collector agent for FSSO – web-based manager

1. Go to User & Device > Single Sign-On and select Create New.
2. Enter the following information:

3. Select Apply & Refresh.

In a few minutes, the FortiGate unit downloads the list of user groups from the server.

To specify the collector agent for FSSO – CLI:

config user fsso edit “WinGroups” set ldap-server “ADserver” set password ENC

G7GQV7NEqilCM9jKmVmJJFVvhQ2+wtNEe9T0iYA5Sa+EqT2J8zhOrbkJFDr0RmY3c4LaoXdsoBczA

1dONmcGfthTxxwGsigzGpbJdC71spFlQYtj set server “10.11.101.160” end

Firewall authentication example

To create the FSSO_Internet-users user group – web-based manager:

1. Go to User & Device > User Groups and select Create New.
2. Enter the following information and then select OK:

To create the FSSO_Internet-users user group – CLI:

config user group edit FSSO_Internet_users set group-type fsso-service

set member CN=Engineering,cn=users,dc=office,dc=example,dc=com

CN=Sales,cn=users,dc=office,dc=example,dc=com end

Creating the Firewall user group

The non-FSSO users need a user group too. In this example, only two users are shown, but additional members can be added easily.

To create the firewall user group – web-based manager:

1. Go to User & Device > User Groups and select Create New.
2. Enter the following information and then select OK:

To create the firewall user group – CLI:

config user group edit Internet_users set group-type firewall set member User1 User2

end

Defining policy addresses

1. Go to Policy & Objects > Addresses.
2. Create the following addresses:

Creating security policies

Two security policies are needed: one for firewall group who connect through port3 and one for FSSO group who connect through port2.

To create a security policy for FSSO authentication – web-based manager:

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information:

3. Select OK.

To create a security policy for FSSO authentication – CLI:

config firewall policy edit 0 set srcintf port2 set dstintf port1 set srcaddr Windows_net set dstaddr all

LDAP Dial-in using member-attribute example

set action accept set groups FSSO_Internet_users set schedule always set service ANY set nat enable

end

To create a security policy for local user authentication – web-based manager

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information:

3. Select OK.

To create a security policy for local user authentication – CLI

config firewall policy edit 0 set srcintf port3 set dstintf port1 set srcaddr internal_net set dstaddr all set action accept set schedule always set groups Internet_users set service ANY set nat enable

end

FortiGate-7060E hardware assembly and rack mounting

The FortiGate-7060E chassis must be mounted in a standard 19-inch rack and requires 8U of vertical space in the rack. This chapter describes how to attach accessories to the FortiGate-7060E chassis, how to install the chassis in a 4-post or 2-post rack, and how to install FIM and FPM modules in the chassis front panel slots.

If you install the FortiGate-7060E chassis in a closed or multi-unit rack assembly, the operating ambient temperature of the rack environment may be greater than room ambient temperature. Make sure the operating ambient temperature does not exceed the manufacturer’s maximum rated ambient temperature.

It is recommended that you mount the FortiGate-7060E chassis near the bottom of the rack to avoid making the rack top-heavy and potentially falling over. If you are going to mount the chassis higher make sure the rack is well anchored. Since the chassis is over 100 lbs use a lift to raise the chassis into position before mounting it.

Installing accessories

These accessories are optional and not required for all configurations. If you have them, before mounting the chassis in a rack you should install the left and right front mounting brackets and the cable management brackets as shown in the following illustration.

Installing FortiGate-7060E accessories

You can also install power cord clamps into the front of the chassis beside each PSU. Install the clamps by inserting them into the holes adjacent each supply at the back of the chassis. Use the clamps to secure the AC power cords so they are not accidentally disconnected.

Mounting the FortiGate-7060E chassis in a four-post rack

The FortiGate-7060E package includes a set of extendable brackets that you can use to mount the chassis in a 4post rack. Install the brackets to create a 4-post rack mount tray that the chassis will slide on to. Attach each side of the tray to the 4-post rack using the front and back brackets as shown below. Make sure you install the tray with enough space above it for the chassis. The length of the tray sides adjusts to match your rack.

Once the 4-post rack mount tray has been installed, slide the chassis onto the tray and secure it to the rack mount tray as shown in the diagram.

Mounting the chassis in a four-post Rack

Mounting the FortiGate-7060E chassis in a two-post rack

The FortiGate-7060E package includes two mid-mount trays and two mid-mount ears that you can use to mount the chassis in a 2-post rack. As shown in the diagram, first attach the mid-mount trays to the rack making sure to leave enough space above the trays for the chassis. Then attach the mid-mount ears to the chassis also as shown in the diagram. Finally line up the mid-mount trays with the mid-mount ears so that the chassis is supported in the rack. Then use screws to attach the mid-mount ears and the chassis to the rack.

Mounting the chassis in a 2-post rack

screws

Air flow

For rack installation, make sure that the amount of air flow required for safe operation of the FortiGate-7060E chassis is not compromised. Make sure that the chassis ventilation openings at the front and back are not blocked by cables or other components. The recommended minimum clearance at the front of the chassis is 100 mm and the recommended clearance from the rear of the chassis is 100 mm. This results in a total footprint of 850 mm from front to back. See Cooling air flow and required minimum air flow clearance on page 13 for more details. hardware assembly and rack mounting Inserting FIM and FPM-7000 series modules

Inserting FIM and FPM-7000 series modules

All FortiGate-7060E chassis are shipped with a protective front panel installed in the chassis to protect internal chassis components. This panel must be removed before you install FIM and FPM modules.

Insert FIM modules into chassis slots 1 and 2. Insert FPM modules into chassis slots 3, 4, 5, and 6.

Do not operate the FortiGate-7060E chassis with open slots on the front or back panel. For optimum cooling performance and safety, each chassis slot must contain an FIM or FPM module or an FIM or FPM blank panel (also called a dummy card). For the same reason, all cooling fan trays, power supplies or power supply slot covers must be installed while the chassis is operating.

To insert FIM and FPM modules, see the guide supplied with the module.

You must carefully slide the module all the way into the chassis slot, close the handles to seat the module into the slot, and tighten the retention screws to make sure the module is fully engaged with the backplane and secured. You must also make sure that the sliding latches are fully closed by gently pushing them down. The handles must be closed, the retention screws tightened and the latches fully closed for the module to get power and start up. If the module is not receiving power all LEDs remain off.

All FIM and FPM-7000 series modules must be protected from static discharge and physical shock. Only handle or work with these boards at a static-free workstation. Always wear a grounded electrostatic discharge (ESD) preventive wrist strap when handling these boards.

Recommended slot locations for interface modules

If you are installing different FIM modules in the FortiGate-7060E chassis, for optimal configuration you should install the module with the lower model number in slot 1 and the module with the higher number in slot 2.

For example:

• if your chassis includes a FIM-7901E and a FIM-7904E, install the FIM-7901E in chassis slot 1 and the FIM-7904E in chassis slot 2.
• If your chassis includes a FIM-7904E and a FIM-7920E, install the FIM-7904E in chassis slot 1 and the FIM-7920E in chassis slot 2.

This applies to any combination of two different interface modules.

FortiGate-7060E Chassis

The FortiGate-7060E is a 8U 19-inch rackmount 6-slot chassis with a 80Gbps fabric and 1Gbps base backplane designed by Fortinet. The fabric backplane provides network data communication and the base backplane provides management and synch communication among the chassis slots.

FortiGate-7060E front panel

The chassis is managed by two redundant management modules. Each module includes an Ethernet connection as well as two switchable console ports that provide console connections to the modules in the chassis slots. The active management module controls chassis cooling and power management and provides an interface for managing the modules installed in the chassis.

FortiGate-7060E front panel, (example module configuration)

Do not operate the FortiGate-7060E chassis with open slots on the front or back panel. For optimum cooling performance and safety, each chassis slot must contain an FIM or FPM module or an FIM or FPM blank panel (also called a dummy card). For the same reason, all cooling fan trays, power supplies or power supply slot covers must be installed while the chassis is operating.

Power is provided to the chassis using four hot swappable 3+1 redundant 100-240 VAC, 50-60 Hz power supply units (PSUs). You can also optionally add up to six PSUs to provide 3+3 redundancy. The FortiGate-7060E can also be equipped with DC PSUs allowing you to connect the chassis to -48V DC power

The standard configuration of the FortiGate-7060E includes two FIM (interface) modules in chassis slots 1 and 2 and up to four FPM (processing) modules in chassis slots 3 to 6.

FIM modules

FIM modules are hot swappable interface modules that provide data and management interfaces, base backplane switching and fabric backplane session-aware load balancing for the chassis. The FIM modules include an integrated switch fabric and DP2 processors to load balance millions of data sessions over the chassis fabric backplane to FPM processor modules. The following FIM modules are available:

• The FIM-7901E includes thirty-two front panel 10GigE SFP+ fabric channel interfaces (A1 to A32). These interfaces are connected to 10Gbps networks. These interfaces can also be configured to operate as Gigabit Ethernet interfaces using SFP transceivers.
• The FIM-7904E includes eight front panel 40GigE QSFP+ fabric channel interfaces (B1 to B8). These interfaces are connected to 40Gbps networks. Using 40GBASE-SR4 multimode QSFP+ transceivers, each QSFP+ interface can also be split into four 10GBASE-SR interfaces and connected to 10Gbps networks.
• The FIM-7910E (shown in FortiGate-7060E front panel, (example module configuration) on page 5) includes four front panel 100GigE CFP2 fabric channel interfaces (C1 to C4). These interfaces can be connected to 100Gbps networks. Using 100GBASE-SR10 multimode CFP2 transceivers, each CFP2 interface can also be split into ten 10GBASE-SR interfaces and connected to 10Gbps networks.
• The FIM-7920E includes four front panel 100GigE QSFP28 fabric channel interfaces (C1 to C4). These interfaces can be connected to 100Gbps networks. Using a 100GBASE-SR4 QSFP28 or 40GBASE-SR4 QSFP+ transceiver, each QSFP28 interface can also be split into four 10GBASE-SR interfaces and connected to 10Gbps networks.

If you are installing different FIM modules in the FortiGate-7060E chassis, for optimal configuration you should install the module with the lower model number in slot 1 and the module with the higher number in slot 2. For example, if your chassis includes a FIM-7901E and a FIM-7904E, install the FIM-7901E in chassis slot 1 and the FIM7904E in chassis slot 2. Also, for example, if your chassis includes a FIM-7904E and a FIM-7920E, install the FIM-7904E in chassis slot 1 and the FIM-7920E in chassis slot 2. This applies to any combination of two different interface modules.

FPM-7620E FPM modules

The FPM-7620E modules are hot swappable processor modules that provide FortiOS firewalling and security services. The FPM modules function as workers, processing sessions load balanced to them by the FIM modules.

FPM modules include multiple NP6 network processors and CP9 content processors to accelerate traffic.

back panel

FortiGate-7060E back panel

The FortiGate-7060E back panel provides access to three hot swappable cooling fan trays and the chassis ground connector that must be connected to ground.

FortiGate-7060E back panel

Registering your FortiGate-7060E chassis

FortiGate-7000 series products are registered according to the chassis serial number. You need to register your chassis to receive Fortinet customer services such as product updates and customer support. You must also register your product for FortiGuard services. Register your product by visiting https://support.fortinet.com. To 7

FortiGate-7060E chassis schematic

register, enter your contact information and the serial numbers of the Fortinet products that you or your organization have purchased.

FortiGate-7060E chassis schematic

The FortiGate-7060E chassis schematic below shows the communication channels between chassis components including the management modules (MGMT), the FIM modules (called FIM1 and FIM2) and the FPM modules (FPM3, FPM4, FPM5, and FPM6).

By default MGMT2 is the active management module and MGMT1 is inactive. The active management module always has the IPMB address 0x20 and the inactive management module always has the IPMB address 0x22.

The active management module communicates with all modules in the chassis over the base backplane. Each module, including the management modules has a Shelf Management Controller (SMC). These SMCs support Intelligent Platform Management Bus (IPMB) communication between the active management module and the FIM and FPM modules for storing and sharing sensor data that the management module uses to control chassis cooling and power distribution. The base backplane also supports serial communications to allow console access from the management module to all modules, and 1Gbps Ethernet communication for management and heartbeat communication between modules.

FIM1 and FIM2 (IPMB addresses 0x82 and 0x84) are the FIM modules in slots 1 and 2. The interfaces of these modules connect the chassis to data networks and can be used for Ethernet management access to chassis components. The FIM modules include DP2 processors that distribute sessions over the Integrated Switch Fabric (ISF) to the NP6 processors in the FPM modules. Data sessions are communicated to the FPM modules over the 80Gbps chassis fabric backplane.

Chassis hardware information

FPM03, FPM04, FPM05, and FPM06 (IPMB addresses 0x86, 0x88, 0x8A, and 0x8C) are the FPM processor modules in slots 3 to 6. These worker modules process sessions distributed to them by the FIM modules. FPM modules include NP6 processors to offload sessions from the FPM CPU and CP9 processors that accelerate content processing.

Chassis hardware information

This section introduces FortiGate-7060E hardware components and accessories including power requirements and FIM and FPM modules that can be installed in the chassis.

Shipping components

The FortiGate-7060E chassis ships pre-assembled with the following components:

l The 8U FortiGate-7060E chassis l Two FIM modules l Up to four FPM modules l Two management modules installed in the front of the chassis l Four Power Supply Units (PSUs) installed in the front of the chassis l Three cooling fan trays installed in the back of the chassis l One protective front panel installed in the chassis to protect internal chassis components. This panel must be removed before installing FIM and FPM modules. l Four power cords with C15 power connectors l Four power cord management clamps l One set of 4-post rack mounting components l One set of 2-post rack mounting components l One pair of cable management side brackets l Two front mounting brackets l Twenty M4x6 flat-head screws l Six M4x8 large head pan-head screws l Six rubber feet l Two console cables l One RJ-45 Ethernet cable

Optional accessories and replacement parts

The following optional accessories can be ordered separately:

9

Chassis hardware information

You can also order the following:

• Additional FIM and FPM modules l Transceivers
• DC PSUs
• Air Filter kit
• FPM and FIM single slot cover trays to be installed in empty chassis slots The following optional accessories can be ordered separately:
• Additional FIM and FPM modules l Transceivers
• DC PSUs
• Additional AC PSUs l Additional FAN trays l Air Filter kit
• FPM and FIM blank panels to be installed in empty chassis slots

Physical description of the FortiGate-7060E chassis

The FortiGate-7060E chassis is a 8U chassis that can be installed in a standard 19-inch rack. The following table describes the physical characteristics of the FortiGate-7060E chassis.

Cooling fans, cooling air flow, and minimum clearance

Cooling fans, cooling air flow, and minimum clearance

The FortiGate-7060E chassis contains three hot swappable cooling fan trays installed in the back of the chassis. Each fan tray includes two fans that operate together. When the fan tray LED is green both fans are operating normally. If the LED turns red or goes off, one or both of the fans is not working and the fan tray should be replaced.

Cooling fans, cooling air flow, and minimum clearance

Cooling Fan Tray

Fan

LED

During normal chassis operation, all three fan trays are active and the fan speed is controlled by the active shelf manager. Fan trays are hot swappable. You can replace a failed fan tray while the chassis is operating. To replace a fan tray, unscrew the four retention screws and use the handles to pull the fan tray out of the chassis.

Install a replacement fan tray by sliding it into place in the empty slot and tightening the retention screws. As you slide the new fan into place it will power up and the fan tray LED will light.

The other fan trays will continue to operate and cool the chassis as a fan tray is being removed and replaced. However an open fan tray slot will result in less air flow through the chassis so do not delay installing the replacement fan tray.

Optional Air Filters

Cooling air flow and required minimum air flow clearance

When installing the chassis, make sure there is enough clearance for effective cooling air flow. The following diagram shows the cooling air flow through the chassis and the locations of fan trays. Make sure the cooling air intake and warm air exhaust openings are not blocked by cables or rack construction because this could result in cooling performance reduction and possible overheating and component damage.

FortiGate-7060E cooling air flow and minimum air flow clearance

Most cool air enters the chassis through the chassis front panel and all warm air exhausts out the back. For optimal cooling allow 100 mm of clearance at the front and back of the chassis and 50 mm of clearance at the sides. Under these conditions 80% of cooling air comes from the front panel air intake and 20% from the left and right side panels and 100% exits out the back. Side clearance is optional and chassis cooling will be sufficient if no side clearance is available.

Optional Air Filters

You can purchase an optional NEBS compliant air filter kit that includes a front filter that fits over the front of the chassis and two filters for the side cool air intakes. These filters are not required for normal operation but can be added if you require air filtration.

The air filters should be inspected regularly. If dirty or damaged, the filters should be disposed of and replaced.

The air filters can be fragile and should be handled carefully.

Power Supply Units (PSUs) and supplying power to the chassis

Power Supply Units (PSUs) and supplying power to the chassis

The FortiGate-7060E chassis front panel includes four hot swappable AC or DC PSUs. At least three PSUs (1, 2, and 3) must be connected to power. Power supplies 4 to 6 are backup power supplies that provide 3+1 , 3+2, and 3+3 redundancy. See FortiGate-7060E front panel on page 5 for locations of the PSUs.

All PSUs should be connected to AC power. To improve redundancy you can connect each power supply to a separate power source.

Use a C15 Power cable, supplied with the chassis, to connect power to each PSU C16 power connector. C15/C16 power connectors are used for high temperature environments and are rated up to 120°C.

To remove a PSU from the chassis, press the latch towards the handle until the PSU is detached then pull it out of the chassis. Insert a replacement PSU into the chassis and slide it in until the latch locks into place. Then connect the PSU to AC power. You can do this while the chassis is operating as long as at least three PSUs remain connected to power.

AC Power Supply Unit (PSU) showing C16 power connector

Connector

The PSU LED indicates whether the PSU is operating correctly and connected to power. If this LED is not lit check to make sure the PSU is connected to power. If the power connection is good then the PSU has failed and should be replaced.

Connecting the FortiGate-7060E chassis to ground

The FortiGate-7060E chassis includes a ground terminal on the rear the bottom of the FortiGate-7060E back panel. The ground terminal provides two connectors to be used with a double-holed lug such as Thomas & Betts PN 54850BE. This connector must be connected to a local ground connection. You need the following equipment to connect the FortiGate-7060E chassis to ground:

• An electrostatic discharge (ESD) preventive wrist strap with connection cord.
• One green 6 AWG stranded wire with listed closed loop double-hole lug suitable for minimum 6 AWG copper wire, such as Thomas & Betts PN 54850BE.

Power Supply Units (PSUs) and supplying power to the chassis

To connect the FortiGate-7060E chassis to ground

1. Attach the ESD wrist strap to your wrist and to an ESD socket or to a bare metal surface on the chassis or frame.
2. Make sure that the chassis and ground wire are not energized.
3. Connect the green ground wire from the local ground to the ground connector on the FortiGate-7060E chassis.
4. Secure the ground wire to the chassis.
5. Optionally label the wire GND.

Turning on FortiGate-7060E chassis power

Connect AC power to PSUs 1, 2, 3, and 4. Once the FortiGate-7060E chassis is connected to power the chassis powers up. If the chassis is operating correctly, the LEDs on the PSUs and fans should be lit. As well, the LEDs on the FortiGate-7060E management module should be lit.

When the chassis first starts up you should also hear the cooling fans operating.

In addition, if any modules have been installed in the chassis they should power on and their front panel LEDs should indicate that they are starting up and operating normally.

FortiGate-7060E Management Modules

The FortiGate-7060E chassis includes two hot swappable management modules (shelf managers), located at the top of the chassis front panel. The management models operate in an active-passive redundant configuration. By default, when the system starts up the management module in slot MGT2 is active and the management module in slot MGT1 is passive. The active management module always has IPMB address 0x20 and the passive management module always has IPMB address 0x22.

The management modules are hot swappable. If you remove the passive management module, or if the passive management module fails, the chassis just keeps operating with the active management module. If you remove the active management module, or if the active management module fails, the passive management module becomes active. If you insert a new management module it quietly starts up and becomes passive. The active management module synchronizes the following data to the passive management module:

l Chassis state and chassis policy l LAN parameters for each LAN channel, including, the IP address, gateway IP address, channel enable status, local interface/non-local interface setting, and the session support flag. l The console connect feature status (enable or disable).

FortiGate-7060E management module front panel

The active management module communicates with module SMCs in the chassis, each of which is responsible for local management of one or more Field Replaceable Units (FRUs), including FIM and FPM modules, fan trays, and power supplies. Management communication within a chassis occurs over the Intelligent Platform Management Bus (IPMB).

The active management module includes LED indicators that report on the status of many of the chassis components, including fans trays and power supplies. You can also use the management module console ports to connect to the management module CLI and to the CLI of the modules in chassis slots 1 to 6.

Management Module LEDs

The active management module controls chassis power allocation, monitors chassis operating parameters, monitors and controls chassis cooling, and generates alarms if the chassis encounters problems. All FIM and FPM modules installed in the chassis communicate with the management module through the module’s IPMC.

Management modules are hot swappable. You can replace a management module by loosening its retention screws, then pulling it out of the chassis. When a management module is removed, the other management module continues providing management functions. If both management module are removed, chassis fans speed up to maximum speed.

When an FIM or FPM module detects the absence of a management module for more than 30 seconds, the module will go to Standalone Mode. In standalone mode the modules autonomously control their own power. When a management module becomes the active management module, it assumes control of chassis fans, and the FIM and FPM modules switch back to normal mode.

In normal mode, FIM and FPM module power on/off requires authorization from the active management module and the management module controls the power supplied by the chassis power systems to the modules.

Each module in the chassis includes its own module Shelf Manager Controller (SMC) Serial Debug Interface (SDI) or SMC SDI console that communicates with the management module SMC SDI. You can connect a serial cable to the active management module console ports to connect to the management module SMC SDI and to connect to each module’s SMC SDI console. You can also interact with the SMC SDI consoles using an Intelligent Platform Management Interface (IPMI) tool.

Management Module LEDs

The following table describes the management Module LED indicators:

FortiGate-7060E Management Module LEDs

Management Module LEDs

Management Module LEDs

About management module alarm levels

About management module alarm levels

Minor, major and critical alarms are defined based on both IPMI, ATCA, and Telco standards for naming alarms.

• A minor alarm (also called an IPMI non-critical (NC) alarm) indicates that a temperature or a power level was detected by a sensor that is outside of the normal operating range but is not considered a problem. In the case of a minor temperature alarm the system could respond by increasing fan speed. A non-critical threshold can be an upper non-critical (UNC) threshold (for example, a high temperature or a high power level ) or a lower non-critical (UNC) threshold (for example, a low power level). l A major alarm (also called an IPMI critical or critical recoverable (CR) alarm) indicates a temperature or power level was detected by a sensor that is far enough outside of the normal operating range to require attention from the operator. It could also mean that the system itself cannot correct the alarm. For example, the cooling system cannot provide enough cooling to reduce the temperature. It could also mean that conditions are close to being outside of the allowed operating range. For example, the temperature is close to exceeding the allowed operating temperature. A critical threshold can also be an upper critical (UC) threshold (for example, a high temperature or a high power level ) or a lower critical (LC) threshold (for example, a low power level).
• A critical alarm (also called an IPMI non-recoverable (NR) alarm) indicates a temperature or power level was detected by a sensor that is outside of the allowed operating range and could potentially cause physical damage.

You can use the management module CLI to get details about alarm sensors, thresholds, and the events that trigger alarms.

Using the console ports

The active management module includes two console ports named Console 1 and Console 2 that can be used to connect to any serial console in the chassis. This includes the management module CLI, the FortiOS CLIs (also called host CLIs) of the FIM and FPM modules in chassis slots 1 to 6 and all of the SMC SDI consoles in the chassis.

Each module, including the management modules, includes an SMC SDI console. These consoles are used for low level programming of the module using an IPMI tool and are disabled by default. You can enable serial access to individual module SMC SDI consoles from the management module SMC SDI CLI using the command serial set sdi enable <slot>. During normal operation you may want to access the management module SMC SDI CLI, you shouldn’t normally require access to individual module SMC SDI consoles.

Connecting to the FortiOS CLI of the FIM module in slot 1

By default when the chassis first starts up Console 1 is connected to the FortiOS CLI of the FIM module in slot 1 and Console 2 is disconnected.

The default settings for connecting to each console port are: Baud Rate (bps) 9600, Data bits 8, Parity None, Stop bits 1, and Flow Control None.

The FIM and FPM modules use the standard FortiOS CLI. The SMC SDI CLIs are described in this chapter. You can use the console connection change buttons to select the CLI that each console port is connected to.

• Press the button to cycle through the FIM and FPM module FortiOS CLIs and disconnect this console.
• Press and hold the button to connect to the management module SMC SDI CLI. You can also cycle through each module’s SMC SDI CLI if they are enabled.

The console’s LEDs indicate what it is connected to. If no LED is lit the console is either connected to the management module SMC SDI console or disconnected. Both console ports cannot be connected to the same CLI at the same time. If a console button press would cause a conflict that module is skipped. If one of the console ports is disconnected then the other console port can connect to any CLI.

If you connect a PC to one of the management module console ports with a serial cable and open a terminal session you begin by pressing Ctrl-T to enable console switching mode, then you can do the following:

• Press Ctrl-T to cycle through the FIM and FPM module FortiOS CLIs (the new destination is displayed in the terminal window). If you press Ctrl-T after connecting to the FPM module in slot 6 the console is disconnected. Press Ctrl-T again to start over again at slot 1.
• Press Ctrl-R to connect to the management module SMC SDI CLI. You can also cycle through each module’s SMC SDI CLI if they are enabled (the new destination is displayed in the terminal window). After cycling through all of the enabled SMC SDI CLIs the next press of Ctrl-R disconnects the console port.

Once the console port is connected to the CLI that you want to use, press Ctrl-G to enable the CLI. When your session is complete you can press Ctrl-G to disable the CLI.

Connecting to the FortiOS CLI of the FIM module in slot 1

Use the following steps to connect to the FortiOS CLI of the FIM module in slot 1:

1. Connect the console cable supplied with your chassis to Console 1 and to your PC or other device RS-232 console port.
2. Start a terminal emulation program on the management computer. Use these settings: Baud Rate (bps) 9600, Data bits 8, Parity None, Stop bits 1, and Flow Control None
3. Press Ctrl-T to enter console switch mode.
4. Repeat pressing Ctrl-T until you have connected to slot 1.
5. Login with an administrator name and password.

The default is admin with no password.

For security reasons, it is strongly recommended that you change the password. 6. When your session is complete, enter the exit command to log out.

Connecting to the FortiOS CLI of the FIM module in slot 2

Use the following steps to connect to the FortiOS CLI of the FIM module in slot 2:

Connecting to the management module SMC SDI CLI

1. Connect the console cable supplied with your chassis to Console 1 and to your PC or other device RS-232 console port.
2. Start a terminal emulation program on the management computer. Use these settings: Baud Rate (bps) 9600, Data bits 8, Parity None, Stop bits 1, and Flow Control None
3. Press Ctrl-T to enter console switch mode.
4. Repeat pressing Ctrl-T until you have connected to slot 2.
5. Login with an administrator name and password.

The default is admin with no password.

For security reasons, it is strongly recommended that you change the password.

6. When your session is complete, enter the exit command to log out.

Connecting to the management module SMC SDI CLI

Use the following steps to connect to the management module SMC SDI CLI:

1. Connect the console cable supplied with your chassis to Console 1 and to your PC or other device RS-232 console port.
2. Start a terminal emulation program on the management computer. Use these settings: Baud Rate (bps) 9600, Data bits 8, Parity None, Stop bits 1, and Flow Control None Use the console change button or Ctrl-R to switch to the management module SMC SDI CLI.
3. Press Ctrl-G to connect to the CLI.
4. Login with an administrator name and password.

The default administrator name and password are admin/admin.

For security reasons, it is strongly recommended that you change the password.

6. You can begin entering commands at the #
7. When your session is complete, enter the exit command to log out.
8. Optionally press Ctrl-G to disable the CLI.

Changing the management module admin account password

Use the following procedure to change the management module admin account password.

1. Enter the following command to show all users and their user IDs. user list

The output should show that the admin user has a user ID of 2.

2. Use the command user set password <user-id> [<password>] to add a password for the admin account. For example:

user set password 2 <password>

3. Enter and confirm a new password for the admin

The password should be between 5 and 20 characters long and should include a combination of upper and lower case letters and numbers.

You can change the admin account password at any time.

Connecting to the management module using an IPMI tool

Connecting to the management module using an IPMI tool

You can install a remote IPMI tool on a management computer and then use this IPMI tool to start an IPMI session with the management module. You can use one of the console ports or the MGMT port to connect with the IPMI tool.

The IPMI commands are the same as the CLI commands described in this chapter but they have to be prefixed as shown in the following example that changes the MGMT interface IP address to 172.20.120.30 over a serial connection:

sudo ipmitool -I serial-terminal -D /dev/ttyS1:9600 -U <username> -P <password> lan set 4 ipaddr 172.20.120.30

Here is the same command over an Ethernet connection:

sudo ipmitool -I lanplus -H 10.160.19.30 -k gkey -U <username> -P <password> lan set 4 ipaddr 172.20.120.30

Use the following IPMI commands to change the management module password:

First from a console port connection:

sudo ipmitool -I serial-terminal -D /dev/ttyS1:9600 -U <username> -P <password> user set password 2 <password> And from an Ethernet connection:

sudo ipmitool -I lanplus -H 10.160.19.30 -k gkey -U <username> -P <password> user set password 2 <password>

To perform an operation on a module according to its chassis slot include the -t <slot> parameter in the IPMI command. For example, to list the sensors on the FIM module in chassis slot 2 (0x82), use the following IPMI command:

sudo ipmitool -I lanplus -H 10.160.19.30 -k gkey -U <username> -P <password0> -t 0x82 sensor

FortiGate-7060E chassis slots IPMB addresses

The following table lists the IPMB addresses of the FortiGate-7060E chassis slots.

Rebooting a chassis module from the SMC SDI CLI

You can use the IPMB address or chassis slot number to reference a chassis slot when entering commands in the shelf manager CLI. For example, enter either of the following commands to display sensor readings for the FIM module in slot 2:

sensor 0x84 sensor 2

When command syntax descriptions in this chapter include the <slot> variable you can replace it with a slot number (1 to 6) or an IPMB address number (0x82 to 0x8C)

Rebooting a chassis module from the SMC SDI CLI

A common use of the SMC SDI CLI is being able to remotely reboot a FIM or FPM module.

From any SMC SDI CLI use the following command to reboot the module in slot 3:

mc reset 3 warm

Use the following command to power off the module in slot 4:

fru deactivate 4

Use the following command to power on the FIM module in slot 2 (IPMI address 0x84):

fru activate 0x84

Use the following IPMI command to reset the module SMC to reboot the module in slot 3:

sudo ipmitool -I lanplus -H 10.160.19.30 -k gkey -U admin -P admin -t 0x86 mc reset warm Use the following IPMI command to power off the module in slot 4:

sudo ipmitool -I lanplus -H 10.160.19.30 -k gkey -U admin -P admin -t 0x88 picmg deactivate 0

Use the following IPMI command to power on the FIM module in slot 2 (IPMI address 0x84):

sudo ipmitool -I lanplus -H 10.160.19.30 -k gkey -U admin -P admin -t 0x84 picmg activate 0

Comlog

All module SMCs include a comlog system for writing and saving console log messages. When enabled, the comlog saves log messages in a local comlog file. Log messages include all local host console messages including BIOS boot up messages. In the comlog these messages include the following headers:

Comlog

The following comlog-related CLI commands are available:

System event log (SEL)

System event log (SEL)

The SMC in each module generates system event log (SEL) messages that record system events as they occur. All SEL messages are stored by individual FIM and FPM module SMCs. They are also all collected and stored by the management module SMC. From the management module you can use the following commands from the active or passive management module to view and clear SEL messages.

Sensor data record (SDR)

The sensor data record (SDR) contains static information about the sensors in each chassis module. Information includes the Sensor ID string, sensor type, sensor event/reading type, entity id, entity instance, sensor unit, reading linearization parameters, sensor thresholds, and so on. The following commands display information stored in the SDR.

Common management module CLI operations

Common management module CLI operations

The following table lists many of the operations you can perform from the management module CLI and the commands you use to perform them. Only a subset of these commands are available on the passive management module as indicated below. Also, the <slot> option is not available on the passive module.

Common management module CLI operations

Common management module CLI operations

Common management module CLI operations

Cautions and Warnings

Environmental Specifications

Rack Mount Instructions – The following or similar rack-mount instructions are included with the installation instructions:

Instructions de montage en rack – Les instructions de montage en rack suivantes ou similaires sont incluses avec les instructions d’installation:

Elevated Operating Ambient – If installed in a closed or multi-unit rack assembly, the operating ambient temperature of the rack environment may be greater than room ambient. Therefore, consideration should be given to installing the equipment in an environment compatible with the maximum ambient temperature (Tma) specified by the manufacturer.

Température ambiante élevée – S’il est installé dans un rack fermé ou à unités multiples, la température ambiante de fonctionnement de l’environnement du rack peut être supérieure à la température ambiante de la pièce. Par conséquent, il est important d’installer le matériel dans un environnement respectant la température ambiante maximale (Tma) stipulée par le fabricant.

Reduced Air Flow – Installation of the equipment in a rack should be such that the amount of air flow required for safe operation of the equipment is not compromised.

Ventilation réduite – Installation de l’équipement dans un rack doit être telle que la quantité de flux d’air nécessaire au bon fonctionnement de l’équipement n’est pas compromise.

Mechanical Loading – Mounting of the equipment in the rack should be such that a hazardous condition is not achieved due to uneven mechanical loading.

Chargement Mécanique – Montage de l’équipement dans le rack doit être telle qu’une situation dangereuse n’est pas lié à un chargement mécanique inégal.

Circuit Overloading – Consideration should be given to the connection of the equipment to the supply circuit and the effect that overloading of the circuits might have on overcurrent protection and supply wiring. Appropriate consideration of equipment nameplate ratings should be used when addressing this concern.

Surtension – Il convient de prendre l’ensemble des précautions nécessaires lors du branchement de l’équipement au circuit d’alimentation et être particulièrement attentif aux effets de la suralimentation sur le dispositif assurant une protection contre les courts-circuits et le câblage. Ainsi, il est recommandé de tenir compte du numéro d’identification de l’équipement.

Reliable Earthing – Reliable earthing of rack-mounted equipment should be maintained. Particular attention should be given to supply connections other than direct connections to the branch circuit (e.g. use of power strips).

FortiGate Open Ports

FortiGate Open Ports

FortiGate Open Ports

FortiAnalyzer Open Ports

FortiAnalyzer Open Ports

FortiAP-S Open Ports

FortiAP-S Open Ports

* – Only FortiAP models, not FortiAP-S.

FortiAuthenticator Open Ports

FortiAuthenticator Open Ports

FortiAuthenticator Open Ports

FortiCloud Open Ports

FortiDB Open Ports

FortiGuard Open Ports

FortiGuard Open Ports

FortiGuard Open Ports