Single Sign-On authentication for users

“Single Sign-On” means that users logged on to a computer network are authenticated for access to network resources through the FortiGate unit without having to enter their username and password again. FortiGate units directly provide Single Sign On capability for:

• Microsoft Windows networks using either Active Directory or NTLM authentication
• Novell networks, using eDirectory

In combination with a FortiAuthenticator unit, the FortiGate unit can provide Single Sign-On capability that integrates multiple external network authentication systems such as Windows Active Directory, Novell eDirectory, RADIUS and LDAP. The FortiAuthenticator unit gathers user logon information from all of these sources and sends it to the FortiGate unit.

Through the SSO feature, the FortiGate unit knows the username, IP address, and external user groups to which the user belongs. 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.

VPN authentication

Authentication involves authenticating the user. In IPsec VPNs authenticating the user is optional, but authentication of the peer device is required. This section includes:

l Authenticating IPsec VPN peers (devices) l Authenticating IPsec VPN users l Authenticating SSL VPN users l Authenticating PPTP and L2TP VPN users

Authenticating IPsec VPN peers (devices)

A VPN tunnel has one end on a local trusted network, and the other end is at a remote location. The remote peer (device) must be authenticated to be able to trust the VPN tunnel. Without that authentication, it is possible for a malicious hacker to masquerade as a valid VPN tunnel device and gain access to the trusted local network.

The three ways to authenticate VPN peers are with a preshared key, RSA X.509 certificate, or a specific peer ID value.

The simplest way for IPsec VPN peers to authenticate each other is through the use of a preshared key, also called a shared secret. The preshared key is a text string used to encrypt the data exchanges that establish the VPN tunnel. The preshared key must be six or more characters. The VPN tunnel cannot be established if the two peers do not use the same key. The disadvantage of preshared key authentication is that it can be difficult to securely distribute and update the preshared keys.

RSA X.509 certificates are a better way for VPN peers to authenticate each other. Each peer offers a certificate signed by a Certificate Authority (CA) which the other peer can validate with the appropriate CA root certificate.

For more information about certificates, see Certificate-based authentication on page 107.

 

You can supplement either preshared key or certificate authentication by requiring the other peer to provide a specific peer ID value. The peer ID is a text string configured on the peer device. On a FortiGate peer or FortiClient Endpoint Security peer, the peer ID provided to the remote peer is called the Local ID.

Authenticating IPsec VPN users

An IPsec VPN can be configured to accept connections from multiple dynamically addressed peers. You would do this to enable employees to connect to the corporate network while traveling or from home. On a FortiGate unit, you create this configuration by setting the Remote Gateway to Dialup User.

It is possible to have an IPsec VPN in which remote peer devices authenticate using a common preshared key or a certificate, but there is no attempt to identify the user at the remote peer. To add user authentication, you can do one of the following:

l require a unique preshared key for each peer l require a unique peer ID for each peer l require a unique peer certificate for each peer l require additional user authentication (XAuth)

The peer ID is a text string configured on the peer device. On a FortiGate peer or FortiClient Endpoint Security peer, the peer ID provided to the remote peer is called the Local ID.

Authenticating SSL VPN users

SSL VPN users can be l user accounts with passwords stored on the FortiGate unit l user accounts authenticated by an external RADIUS, LDAP or TACACS+ server l PKI users authenticated by certificate

You need to create a user group for your SSL VPN. Simply create a firewall user group, enable SSL VPN access for the group, and select the web portal the users will access.

SSL VPN access requires an SSL VPN security policy that permits access to members of your user group.

Authenticating PPTP and L2TP VPN users

PPTP and L2TP are older VPN tunneling protocols that do not provide authentication themselves. FortiGate units restrict PPTP and L2TP access to users who belong to one specified user group. Users authenticate themselves to the FortiGate unit by username/password. You can configure PPTP and L2TP VPNs only in the CLI. Before you configure the VPN, create a firewall user group and add to it the users who are permitted to use the VPN. Users are authenticated when they attempt to connect to the VPN. For more information about configuring PPTP or L2TP VPNs, see the FortiGate CLI Reference.

Types of authentication

FortiOS supports two different types of authentication based on your situation and needs.

Security policy authentication is easily applied to all users logging on to a network, or network service. For example if a group of users on your network such as the accounting department who have access to sensitive Types of authentication

data need to access the Internet, it is a good idea to make sure the user is a valid user and not someone trying to send company secrets to the Internet. Security policy authentication can be applied to as many or as few users as needed, and it supports a number of authentication protocols to easily fit with your existing network.

Virtual Private Network (VPN) authentication enables secure communication with hosts located outside the company network, making them part of the company network while the VPN tunnel is operating. Authentication applies to the devices at both ends of the VPN and optionally VPN users can be authenticated as well.

Security policy authentication

Security policies enable traffic to flow between networks. Optionally, the policy can allow access only to specific originating addresses, device types, users or user groups. Where access is controlled by user or user group, users must authenticate by entering valid username and password credentials.

The user’s authentication expires if the connection is idle for too long, five minutes by default but that can be customized.

Security policies are the mechanism for FSSO, NTLM, certificate based, and RADIUS SSO authentication.

FSSO

Fortinet Single Sign on (FSSO) provides seamless authentication support for Microsoft Windows Active Directory (AD) and Novell eDirectory users in a FortiGate environment.

On a Microsoft Windows or Novell network, users authenticate with the Active Directory or Novell eDirectory at logon. FSSO provides authentication information to the FortiGate unit so that users automatically get access to permitted resources. See Introduction to agent-based FSSO on page 142.

NTLM

The NT LAN Manager (NTLM) protocol is used when the MS Windows Active Directory (AD) domain controller can not be contacted. NTLM is a browser-based method of authentication.

The FSSO software is installed on each AD server and the FortiGate unit is configured to communicate with each

FSSO client. When a user successfully logs into their Windows PC (and is authenticated by the AD Server), the

FSSO client communicates the user’s name, IP address, and group login information to the FortiGate unit. The FortiGate unit sets up a temporary access policy for the user, so when they attempt access through the firewall they do not need to re-authenticate. This model works well in environments where the FSSO client can be installed on all AD servers.

In system configurations where it is not possible to install FSSO clients on all AD servers, the FortiGate unit must be able to query the AD servers to find out if a user has been properly authenticated. This is achieved using the NTLM messaging features of Active Directory and Internet Explorer.

Even when NTLM authentication is used, the user is not asked again for their username and password. Internet Explorer stores the user’s credentials and the FortiGate unit uses NTLM messaging to validate them in the Windows AD environment.

Note that if the authentication reaches the timeout period, the NTLM message exchange restarts. For more information on NTLM, see NTLM authentication on page 88 and FSSO NTLM authentication support on page 148.

Certificates

Certificates can be used as part of a policy. All users being authenticated against the policy are required to have the proper certificate. See Certificate-based authentication on page 107

RADIUS SSO

RADIUS Single Sign-On (RSSO) is a remote authentication method that does not require any local users to be configured, and relies on RADIUS Start records to provide the FortiGate unit with authentication information. That information identifies the user and user group, which is then matched using a security policy. See SSO using RADIUS accounting records on page 186.

FortiGuard Web Filter override authentication

Optionally, users can be allowed the privilege of overriding FortiGuard Web Filtering to view blocked web sites. Depending on the override settings, the override can apply to the user who requested it, the entire user group to which the user belongs, or all users who share the same web filter profile. As with other FortiGate features, access to FortiGuard overrides is controlled through user groups. Firewall and Directory Services user groups are eligible for the override privilege. For more information about web filtering and overrides, see the UTM chapter of this FortiOS Handbook.

Methods of authentication

FortiGate unit authentication is divided into three basic types: password authentication for people, certificate authentication for hosts or endpoints, and two-factor authentication for additional security beyond just passwords. An exception to this is that FortiGate units in an HA cluster and FortiManager units use password authentication.

Password authentication verifies individual user identities, but access to network resources is based on membership in user groups. For example, a security policy can be configured to permit access only to the members of one or more user groups. Any user who attempts to access the network through that policy is then authenticated through a request for their username and password.

Methods of authentication include:

l Local password authentication l Server-based password authentication l Certificate-based authentication l Two-factor authentication

Local password authentication

The simplest authentication is based on user accounts stored locally on the FortiGate unit. For each account, a username and password is stored. The account also has a disable option so that you can suspend the account without deleting it.

Local user accounts work well for a single-FortiGate installation. If your network has multiple FortiGate units that will use the same accounts, the use of an external authentication server can simplify account configuration and maintenance.

You can create local user accounts in the web-based manager under User & Device > User Definition. This page is also used to create accounts where an external authentication server stores and verifies the password.

Server-based password authentication

Using external authentication servers is desirable when multiple FortiGate units need to authenticate the same users, or where the FortiGate unit is added to a network that already contains an authentication server. FortiOS supports the use of LDAP, RADIUS, TACACS+, AD or POP3 servers for authentication.

When you use an external authentication server to authenticate users, the FortiGate unit sends the user’s entered credentials to the external server. The password is encrypted. The server’s response indicates whether the supplied credentials are valid or not.

You must configure the FortiGate unit to access the external authentication servers that you want to use. The configuration includes the parameters that authenticate the FortiGate unit to the authentication server.

You can use external authentication servers in two ways:

• Create user accounts on the FortiGate unit, but instead of storing each user’s password, specify the server used to authenticate that user. As with accounts that store the password locally, you add these users to appropriate user groups.
• Add the authentication server to user groups. Any user who has an account on the server can be authenticated and have the access privileges of the FortiGate user group. Optionally, when an LDAP server is a FortiGate user group member, you can limit access to users who belong to specific groups defined on the LDAP server.

Certificate-based authentication

An RSA X.509 server certificate is a small file issued by a Certificate Authority (CA) that is installed on a computer or FortiGate unit to authenticate itself to other devices on the network. When one party on a network presents the certificate as authentication, the other party can validate that the certificate was issued by the CA. The identification is therefore as trustworthy as the Certificate Authority (CA) that issued the certificate.

To protect against compromised or misused certificates, CAs can revoke any certificate by adding it to a Certificate Revocation List (CRL). Certificate status can also be checked online using Online Certificate Status Protocol (OCSP).

RSA X.509 certificates are based on public-key cryptography, in which there are two keys: the private key and the public key. Data encrypted with the private key can be decrypted only with the public key and vice versa. As the names suggest, the private key is never revealed to anyone and the public key can be freely distributed. Encryption with the recipient’s public key creates a message that only the intended recipient can read. Encryption with the sender’s private key creates a message whose authenticity is proven because it can be decrypted only with the sender’s public key.

Types

Server certificates contain a signature string encrypted with the CA’s private key. The CA’s public key is contained in a CA root certificate. If the signature string can be decrypted with the CA’s public key, the certificate is genuine. Certificate authorities

A certificate authority can be:

l an organization, such as VeriSign Inc., that provides certificate services l a software application, such as Microsoft Certificate Services or OpenSSH

For a company web portal or customer-facing SSL VPN, a third-party certificate service has some advantages. The CA certificates are already included in popular web browsers and customers trust the third-party. On the other hand, third-party services have a cost.

For administrators and for employee VPN users, the local CA based on a software application provides the required security at low cost. You can generate and distribute certificates as needed. If an employee leaves the organization, you can simply revoke their certificate.

Certificates for users

FortiGate unit administrators and SSL VPN users can install certificates in their web browsers to authenticate themselves. If the FortiGate unit uses a CA-issued certificate to authenticate itself to the clients, the browser will also need the appropriate CA certificate.

FortiGate IPsec VPN users can install server and CA certificates according to the instructions for their IPsec VPN client software. The FortiClient Endpoint Security application, for example, can import and store the certificates required by VPN connections.

FortiGate units are also compatible with some Public Key Infrastructure systems. For an example of this type of system, see RSA ACE (SecurID) servers on page 48.

Two-factor authentication

A user can be required to provide both something they know (their username and password combination) and something they have (certificate or a random token code). Certificates are installed on the user’s computer.

Two-factor authentication is available for PKI users. For more information, see Certificate on page 58.

Another type of two-factor authentication is to use a randomly generated token (multi-digit number) along with the username and password combination. One method is a FortiToken — a one time passcode (OTP) generator that generates a unique code every 60 seconds. Others use email or SMS text messaging to deliver the random token code to the user or administrator.

When one of these methods is configured, the user enters this code at login after the username and password have been verified. The FortiGate unit verifies the token code after as well as the password and username. For more information, see Two-factor authentication on page 57

What is authentication?

Businesses need to authenticate people who have access to company resources. In the physical world this may be a swipe card to enter the building, or a code to enter a locked door. If a person has this swipe card or code, they have been authenticated as someone allowed in that building or room.

Authentication is the act of confirming the identity of a person or other entity. In the context of a private computer network, the identities of users or host computers must be established to ensure that only authorized parties can access the network. The FortiGate unit enables controlled network access and applies authentication to users of security policies and VPN clients.

Whats New in FortiOS 5.6

The following section describes new authentication features added to FortiOS 5.6.0. and 5.6.1.

FortiOS 5.6.1

These features first appeared in FortiOS 5.6.1.

IPv6 RADIUS Support (309235, 402437, 439773)

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

Full certificate chain CRL checking (407988)

Certificate revocation/status check for peer certificates and intermediate CAs is now supported. Redesigned fnbam_auth_cert() API to use stack type of X509 instead of array for certificate chain. Removed obsolete fnbam API and parameters. Now authd, sslvpnd, and GUI send full certificate chains to fnbamd for verification.

 

5.6.1

New option under user > setting to allow/forbid SSL renegotiation in firewall authentication (386595)

A new option auth-ssl-allow-renegotiation is now available under config user setting to allow/forbid renegotiation. The default value is disable, where a session would be terminated by authd once renegotiation is detected and this login would be recorded as failure. Other behavior follows regular auth settings.

Syntax

config user setting set auth-ssl-allow-renegotiation {enable | disable}

end

New option to allow spaces in RADIUS DN format (422978)

Previously, IKEv2 RADIUS group authentication introduced a regression because it removed spaces from ASN.1 DN peer identifier string.

Reverted default DN format to include spaces. Added a new CLI option ike-dn-format to allow the user to select either with-space or no-space. Customers using the group-authentication option can select the ike-dn-format setting to match the format used in their RADIUS user database.

Added LDAP filter when group-member-check is user-attr (403140)

Added LDAP filter when group-member-check is user-attr. LDAP filter is deployed when checking user attribute.

Syntax

config user ldap edit <name> set group-filter ?

next

end

l group-filter is none by default, where the process is the same as before.

When group-filter is set, the LDAP filter takes effect for retrieving the group information.

Added Refresh button to the LDAP browser (416649)

Previously, cached LDAP data was used even if the LDAP server configuration was updated.

In FortiOS 5.6.1, a Refresh button has been added in the LDAP browser. In the LDAP server dialog page, the user can delete the DN field to browse the root level tree when clicking the Fetch DN button.

Differentiate DN option for user authentication and membership searching (435791)

Previously, LDAP used the same DN option for user authentication and membership searching. New CLI commands are introduced to config user ldap to resolve this issue:

• group-member-check user-attr

For user attribute checking, a new attribute group-search-base is added, which indicates the starting point for

5.6.1

the group search. If the group-search-base is not set, binddn is used as the search base. Removed searchtype when group-member-check is user-attr.

• group-member-check group-object

For group object checking, the group names in user group match rule will be picked up as the group search base. If there are multiple matching rules, each group name will trigger the ldapsearch query once. l group-member-check posix-group-object

Changed group-object-search-base to group-search-base for posix-group-object groupmember-check.

FTM Push when FAC is auth server (408273)

This feature adds support for FortiToken Mobile (FTM) push with FortiAuthenticator server in FortiOS. It also fixes a crash when adding a node to an RB tree, by checking if the same key has already been used in the tree. If yes, remove the node using the same key before adding a new node.

Non-blocking LDAP authentication (433700)

The previous LDAP authentication in fnbamd used openldap library. OpenLDAP supports non-blocking BIND but it is not event driven.

To support non-blocking LDAP in fnbamd, we stopped using the openLDAP library in fnbamd, instead using only liblber. Instead of using openLDAP, fnbamd will create its own event-driven connection with LDAP servers over LDAP/LDAPS/STARTTLS, make it non-blocking, do CRL checking if necessary, and compose all LDAP requests using liblber (including bind, unbind, search, password renewal, password query, send request and receive response, and parse response). The whole process is done in one connection.

This doesn’t change any openLDAP implementation but moves some data structure definitions and API definitions from some internal header files to public header files.

Manual certificate SCEP renewal (423997)

Added support of manual certificate SCEP renewal besides the auto-regeneration feature that already exists.

More detailed RADIUS responses shown in connectivity test (434303)

Improved on-demand test connectivity for RADIUS servers. Test results show RADIUS server reachability, NAS client rejection, and invalid User/Password. Test also shows RADIUS Attributes returned from the RADIUS server.

Example

FG100D3G12807101 # diagnose test authserver radius-direct

<server_name or IP> <port no(0 default port)> <secret> <user> <password>

FG100D3G12807101 # diagnose test authserver radius-direct 1.1.1.1 0 dd RADIUS server ‘1.1.1.1’ status is Server unreachable

FG100D3G12807101 # diagnose test authserver radius-direct 172.18.5.28 0 dd

RADIUS server ‘172.18.5.28’ status is Secret invalid

FG100D3G12807101 # diagnose test authserver radius-direct 172.18.5.28 0 fortinet jeff1 asdfasdf

5.6.0

RADIUS server ‘172.18.5.28’ status is OK Access-Reject

FG100D3G12807101 # diagnose test authserver radius-direct 172.18.5.28 0 fortinet ychen1 asdfasdf

RADIUS server ‘172.18.5.28’ status is OK

Access-Accept

AVP: l=6 t=Framed-Protocol(7) Value: 1

AVP: l=6 t=Service-Type(6) Value: 2

AVP: l=46 t=Class(25)

Value: 9e 2a 08 6d 00 00 01 37 00 01 17 00 fe 80 00 00 00 00 00 00 00 00 5e fe ac 12 05

1c 01 d2 cd b6 75 a6 80 56 00 00 00 00 00 00 00 1c

AVP: l=12 t=Vendor-Specific(26) v=Microsoft(311) VSA: l=6 t=MS-Link-Utilization-Threshold(14) Value: 50

AVP: l=12 t=Vendor-Specific(26) v=Microsoft(311)

VSA: l=6 t=MS-Link-Drop-Time-Limit(15) Value: 120

Firewall user authentication timeout range increased (378085)

The firewall user authentication timeout max value has increased from 3 days to 30 days.

Syntax

config user group set authtimeout <0 – 43200>

end

FortiOS 5.6.0

These features first appeared in FortiOS 5.6.0.

FortiToken Mobile Push (397912, 408273, 399839, 404872)

FortiToken Mobile push supports two-factor authentication without requiring users to enter a four-digit code to authenticate. Instead they can just accept the authentication request from their FortiToken Mobile app.

A new command has been added under config system ftm-push allowing you to configure the FortiToken

Mobile Push services server IP address and port number. The Push service is provided by Apple (APNS) and Google (GCM) for iPhone and Android smartphones respectively. This will help to avoid tokens becoming locked after an already enabled two-factor authentication user has been disabled. In addition, FortiOS supports FTM Push when FortiAuthenticator is the authentication server.

CLI syntax

config system ftm-push set server-ip <ip-address> set server-port [1-65535] Default is 4433. end

5.6.0

In addition, FTM Push is supported on administrator login and SSL VPN login for both iOS and Android. If an SSL VPN user authenticates with their token, then logs out and attempts to reauthenticate again within a minute, a new message will display showing “Please wait x seconds to login again.” This replaces a previous error/permission denied message.

The “x” value will depend on the calculation of how much time is left in the current time step.

CLI syntax

config system interface edit <name> set allowaccess ftm

next

end

Support V4 BIOS certificate (392960)

FortiOS now supports backwards compatibility between new BIOS version 4 and old BIOS version 3.

New BIOS V4 certificates:

• Fortinet_CA l Fortinet_Sub_CA l Fortinet_Factory

Old BIOS V3 certificates:

• Fortinet_CA_Backup l Fortinet_Factory_Backup

When FortiOS connects to FortiGuard, FortiCloud, FortiManager, FortiAnalyzer, FortiSandbox as a client, the new BIOS certificate Fortinet_Factory will be the default client certificate. When the server returns its certificate (chain) back, FortiOS looks up the issuer of the server certificate and either keeps client certificate as is or switches to the old BIOS certificate Fortinet_Factory_Backup. This process occurs in one handshake.

When FortiOS connects to FortiCare, the new BIOS certificate Fortinet_Factory is the only client certificate and Server Name Indication (SNI) is set. There is no switchover of certificate during SSL handshake.

When FortiOS acts as a server when connected by FortiExtender, FortiSwitch, FortiAP, etc., Fortinet_Factory is the default server certificate. FortiOS detects SNI in client hello, and if no SNI is found or if the CN in SNI is different from the CN of Fortinet_CA, it switches to use the old Fortinet_Factory_Backup.

Support extendedKeyUsage for x.509 certificates (390393)

As per Network Device Collaborative Protection Profile (NDcPP) v1.0 requirements, server certificates used for TLS connections between FortiGate and FortiAnalyzer should have the “Server Authentication” and “Client Authentication” extendedKeyUsage fields in FIPS/CC mode.

To implement this, a new CLI command has been added under log fortianalyzer setting to allow you to specify the certificate used to communicate with FortiAnalyzer.

CLI syntax config log fortianalyzer setting

5.6.0

set certificate <name>

end

Administrator name added to system event log (386395)

The administrator’s name now appears in the system event log when the admin issues a user quarantine ban on a source address.

Support RSA-4096 bit key-length generation (380278)

In anticipation of quantum computers, RSA-4096 bit key-length CSRs can now be imported.

New commands added to config user ldap to set UPN processing method and filter name (383561)

Added two new commands to config user ldap allowing you to keep or strip domain string of UPN in the token as well as the search name for this kind of UPN.

CLI syntax:

config user ldap set account-key-processing set account-key-name

end

User authentication max timeout setting change (378085)

To accommodate wireless hotspot users authenticated on the FortiGate, the user authentication max timeout setting has been extended to three days (from one day, previously).

Changes to Authentication Settings > Certificates GUI (374980)

Added new icons for certificate types and updated formatters to use these new icons.

Password for private key configurable in both GUI and CLI (374593)

FortiOS 5.4.1 introduced a feature that allowed you to export a local certificate and its private key in password protected p12, and later import them to any device. This option to set password for private key was available only in the CLI (when requesting a new certificate via SCEP or generating a CSR). This feature is now also configurable through the GUI.

The new Password for private key option is available under System > Certificates when generating a new CSR.

RADIUS password encoding (365145)

A new CLI command, under config user radius, has been added to allow you to configure RADIUS password encoding to use ISO-8859-1 (as per RFC 2865).

Certain RADIUS servers use ISO-8859-1 password encoding instead of others such as UTF-8. In these instances, the server will fail to authenticate the user, if the user’s password is using UTF-8.

5.6.0

CLI syntax

config user radius edit <example> set password-encoding <auto | ISO-8859-1>

end

This option will be skipped if the auth-type is neither auto nor pap.

RSSO supports Delegated-IPv6-Prefix and Framed-IPv6-Prefix (290990)

Two attributes, Delegated-IPv6-Prefix and Framed-IPv6-Prefix, have been introduced for RSSO to provide a /56 prefix for DSL customers. All devices connected from the same location (/56 per subscriber) can be mapped to the same profile without the need to create multiple /64 or smaller entries.

 

Introduction

Welcome and thank you for selecting Fortinet products for your network protection.

This chapter contains the following topics:

l Before you begin l How this guide is organized

Before you begin

Before you begin using this guide, please ensure that:

l You have administrative access to the web-based manager and/or CLI. l The FortiGate unit is integrated into your network. l The operation mode has been configured. l The system time, DNS settings, administrator password, and network interfaces have been configured. l Firmware, FortiGuard Antivirus and FortiGuard Antispam updates are completed. l Any third-party software or servers have been configured using their documentation.

While using the instructions in this guide, note that administrators are assumed to be super_admin administrators unless otherwise specified. Some restrictions will apply to other administrators.

How this guide is organized

This Handbook chapter contains the following sections:

Introduction to authentication describes some basic elements and concepts of authentication.

Authentication servers describes external authentication servers, where a FortiGate unit fits into the topology, and how to configure a FortiGate unit to work with that type of authentication server.

Users and user groups describes the different types of user accounts and user groups. Authenticated access to resources is based on user identities and user group membership. Two-factor authentication methods, including FortiToken, provide additional security.

Managing Guest Access explains how to manage temporary accounts for visitors to your premises.

Configuring authenticated access provides detailed procedures for setting up authenticated access in security policies and authenticated access to VPNs.

Captive portals describes how to authenticate users through a web page that the FortiGate unit presents in response to any HTTP request until valid credentials are entered. This can be used for wired or WiFi network interfaces.

Certificate-based authentication describes authentication by means of X.509 certificates.

Single Sign-On using a FortiAuthenticator unit describes how to use a FortiAuthenticator unit as an SSO agent that can integrate with external network authentication systems such as RADIUS and LDAP to gather user logon information and send it to the FortiGate unit. Users can also log on through a FortiAuthenticator-based web portal or the FortiClient SSO Mobility Agent.

Single Sign-On to Windows AD describes how to set up Single Sign-On in a Windows AD network by configuring the FortiGate unit to poll domain controllers for information user logons and user privileges.

Agent-based FSSO describes how to set up Single Sign-On in Windows AD, Citrix, or Novell networks by installing Fortinet Single Sign On (FSSO) agents on domain controllers. The FortiGate unit receives information about user logons and allows access to network resources based on user group memberships.

SSO using RADIUS accounting records describes how to set up Single Sign-On in a network that uses RADIUS authentication. In this configuration, the RADIUS server send RADIUS accounting records to the FortiGate unit when users log on or off the network. The record includes a user group name that can be used in FortiGate security policies to determine which resources each user can access.

Monitoring authenticated users describes FortiOS authenticated user monitor screens.

Examples and Troubleshooting provides configuration examples and troubleshooting suggestions.