DO NOT REPRINT

© FORTINET

FortiAuthenticator
Study Guide
for FortiAuthenticator 6.4
DO NOT REPRINT
© FORTINET
Fortinet Training Institute - Library

https://training.fortinet.com

Fortinet Product Documentation

https://docs.fortinet.com

Fortinet Knowledge Base

https://kb.fortinet.com

Fortinet Fuse User Community

https://fusecommunity.fortinet.com/home

Fortinet Forums

https://forum.fortinet.com

Fortinet Product Support

https://support.fortinet.com

FortiGuard Labs

https://www.fortiguard.com

Fortinet Training Program Information

https://www.fortinet.com/nse-training

Fortinet | Pearson VUE

https://home.pearsonvue.com/fortinet

Fortinet Training Institute Helpdesk (training questions, comments, feedback)

https://helpdesk.training.fortinet.com/support/home

7/15/2022
DO NOT REPRINT
© FORTINET

TABLE OF CONTENTS

01 Introduction and Initial Configuration 4

02 Administrative Users and High Availability 39
03 Administering and Authenticating Users 73
04 Managing Users and Troubleshooting Authentication 112
05 Two-Factor Authentication 149
06 FSSO Process and Methods 196
07 FSSO Deployment and Troubleshooting 230
08 Portal Services 260
09 PKI and FortiAuthenticator as a CA 311
10 Certificate Management 340
11 802.1X Authentication 376
12 SAML 414
13 FIDO2 Authentication 460
 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the key features and concepts of FortiAuthenticator and how to configure
the FortiAuthenticator for initial setup.

FortiAuthenticator is the central device for any authentication infrastructure.

FortiAuthenticator 6.4 Study Guide 4

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 5

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in authentication and the role of FortiAuthenticator, you will be able to define
authentication and understand the role of FortiAuthenticator in your own network.

FortiAuthenticator 6.4 Study Guide 6

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

Authentication is the act—or process—of verifying the validity of a claimed identity. Confirmation of identity is
necessary in the digital world, because granting access to a resource, approving a transaction request,
trusting the validity of a document, and so on, before verifying a person is who they say they are, can lead to a
serious network security breach.

So how do you confirm the identity of a digital user? You can confirm user identities based on something the
user knows (for example, a password or PIN), or something the user has (for example, a digital certificate or
token), or a combination of both methods.

FortiAuthenticator 6.4 Study Guide 7

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator is a device that provides standards-based secure authentication to the entire network
infrastructure. That is, it verifies the validity of a claimed identity. FortiAuthenticator accepts many different
user identification methods (token, digital certificate, and so on) through different access points (local, remote,
wireless, guest, and so on).

FortiAuthenticator also centralizes the management and storage of user identity information, increasing the
efficiency of administration, and increasing control over who accesses the network.

The example shown on this slide demonstrates the advantage of two-factor authentication. The user’s
username and password have been compromised by a bad actor (this is often done using phishing or spear
phishing attacks), but because the bad actor does not possess the token, access will still be denied.

FortiAuthenticator 6.4 Study Guide 8

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

This slide covers all of the hardware and virtual models available.

The virtual machine (VM) version of FortiAuthenticator is popular with customers that have existing virtual
infrastructure. One of the main benefits of the VM version is that you can add CPU and RAM to your systems
as your needs grow. You then purchase user licenses for the VMs to suit your customers needs. These
licenses are stackable, which makes them ideal for customers who are looking to expand over time.

FortiAuthenticator 6.4 Study Guide 9

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 10

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

Good job! You now understand authentication and the role of FortiAuthenticator.

Now, you will learn about the key features of FortiAuthenticator, and the comparisons between
FortiAuthenticator and FortiGate.

FortiAuthenticator 6.4 Study Guide 11

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding the key features of FortiAuthenticator, and the comparisons
between FortiAuthenticator and FortiGate, you will be able to use the device effectively in your own network.

FortiAuthenticator 6.4 Study Guide 12

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator is a user authentication and identity management device. Some of the key features include:
two-factor authentication, wired or wireless authentication using the 802.1X standard, certificate management,
portal services, and Fortinet single sign-on (FSSO).

Multi-factor authentication increases network security by requiring multiple pieces of identification (known as
factors). It combines something you know with something you have to reliably confirm your identity.

FortiAuthenticator supports wired and wireless networking with the IEEE 802.1X standard. 802.1X
authentication provides an additional security barrier for your intranet. Just as an authenticated wireless client
must submit a set of credentials to be validated before being allowed access, an 802.1X wired client must also
perform authentication before being able to send traffic over its switch port.

FortiAuthenticator has several roles that involve digital certificates, including acting as a certificate authority
(CA), a SCEP server, authenticating users against an external LDAP server, and authenticating users using
Extensible Authentication Protocol (EAP). You will explore certificate management further in the Certificate
Management lesson.

FSSO enables FortiAuthenticator to leverage your network’s existing authentication system for firewall
authentication. After a user logs in, they can access other network resources without having to authenticate
again—authentication is transparent. You will explore FSSO further in the Fortinet Single Sign-On lesson.

Portal services allows you to grant remote users access to specific portions of your network, using delegated
authentication. In this scenario, authentication requires the user to associate their device with the guest SSID,
as published by the FortiGate wireless controller.

FortiAuthenticator 6.4 Study Guide 13

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

The table on this slide shows some of the key differences in RADIUS capabilities between FortiGate and
FortiAuthenticator.

As a RADIUS server, FortiAuthenticator provides authentication and authorization both as a server and as a
proxy. RADIUS rules can be used for FSSO updates.

FortiAuthenticator 6.4 Study Guide 14

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

The table on this slide shows some of the key differences in LDAP capabilities between FortiGate and
FortiAuthenticator beyond active directory synchronization.

FortiAuthenticator 6.4 Study Guide 15

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator can retrieve FSSO identity information from a variety of sources, including the FortiClient
mobility agent, Syslog messaging, Windows domain polling, and RADIUS accounting. FortiAuthenticator then
passes gathered user, group, and IP address information to FortiGate devices.

You can use FortiAuthenticator to restrict the number of devices per FSSO user.

FortiAuthenticator 6.4 Study Guide 16

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator offers SAML support for end-user SSO and can act as both an identity provider (IdP) and a
service provider (SP).

FortiAuthenticator can act as a certificate authority (CA) and provide certificate auto-enrollment using SCEP
or OCSP.

FortiAuthenticator social authentication provides users with the ability to validate using social media sites,
such as Facebook, Twitter, LinkedIn, and Google.

FortiAuthenticator 6.4 Study Guide 17

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator can support up to 1 million users and offer two-factor authentication.

FortiAuthenticator provides the ability to centrally manage tokens. For example, a single token can be used to
access many FortiGate devices instead of a separate token for each FortiGate. Tokens can be pushed using
SMS.

Fast ID Online (FIDO) can provide secure authentication without a password.

FortiAuthenticator 6.4 Study Guide 18

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 19

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

Good job! You now understand the key features of FortiAuthenticator, and comparisons between
FortiAuthenticator and FortiGate.

Now, you will learn about the initial configuration.

FortiAuthenticator 6.4 Study Guide 20

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in the initial configuration of FortiAuthenticator, you will be able to deploy
FortiAuthenticator in your own network and perform basic administrative tasks.

FortiAuthenticator 6.4 Study Guide 21

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

To log in to FortiAuthenticator, you need to know:

- The factory default settings—you can find these in the QuickStart Guide for your FortiAuthenticator model
- The default user name and password

To connect to the management computer, you need to know:

- The IP address of port1 and the netmask
- The default supported management access protocols

The number of ports for each FortiAuthenticator model varies, however port1 is the management port, and its
default IP address is 192.168.1.99.

FortiAuthenticator 6.4 Study Guide 22

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

If you are using the GUI to configure FortiAuthenticator, you need to connect an Ethernet cable between
FortiAuthenticator and the management computer on port1. You also must configure the management
computer to be on the same subnet as the FortiAuthenticator port1 interface.

To log in, open a supported browser and enter the default IP address preceded by https://. At the login
screen, use the factory default information for the administrator account. The username is admin. When
prompted do not enter a password. During the initial login, FortiAuthenticator will prompt you to create a
password.

If you are using the CLI configuration tool to configure FortiAuthenticator, use a terminal emulation application,
such as PuTTY. Because of the limited functionality of the CLI, there is no CLI Console widget on the web-
based manager, like there is for other Fortinet products.

On the terminal emulation application, enter the default FortiAuthenticator port1 IP address and select a
supported management access protocol. SSH is the only protocol enabled by default.

FortiAuthenticator 6.4 Study Guide 23

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

The status dashboard is the landing page for administrators after login. The dashboard contains widgets that
display different types of real-time information. It should be one of the first places you look for any signs of
trouble every time you log in.

FortiAuthenticator 6.4 Study Guide 24

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

After you log in, you must configure the interface, the primary and secondary DNS server IP addresses, static
routing (which includes the default gateway), and system time. For the sake of simplicity, in this lesson, the
GUI is used to explain the configuration requirements.

You perform all initial configuration tasks on the same area of the GUI. Click System > Network.

You must fulfill some requirements for your network during configuration. At a minimum, you must ensure
specific ports are open in the security policies between the RADIUS authentication clients and
FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 25

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

You can configure the interface network settings on the Interfaces page. This includes setting an IP address
and netmask, as well as supported administrator access and system protocols.

You must edit the default IP address and netmask associated with the port1/MGMT interface, based on your
own network. This provides more security than using the default IP address and, if more than one
FortiAuthenticator is located in the network, different network settings are mandatory (the management
interface must have a dedicated address). You can assign IPv4 and IPv6 addresses, which must be static.
Administrator access for IPv4 and IPv6 have been separated, so you can mix and match the options you
want.

You must also select the administrative protocols you want to support. Any interface that is used to provide
administration access to FortiAuthenticator requires at least HTTP or HTTPS, for GUI access, or SSH for CLI
access. By default, HTTPS and SSH are enabled on FortiAuthenticator.

Finally, you must select the services you want to allow. These are tied to the functionality you want to employ
and several are already enabled by default. You will learn about many of these services throughout the
training.

FortiAuthenticator supports the receipt of messages from a syslog source over a TLS connection using TCP
port 6514.

FortiAuthenticator 6.4 Study Guide 26

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

For security reasons, hosts may access the FortiAuthenticator GUI only if they are on the same domain or on
the same network as FortiAuthenticator, and, even then, only if the interface has HTTP or HTTPS for GUI
access enabled. You can allow additional hosts by designated IP address or domain name, from the System
Access page.

FortiAuthenticator 6.4 Study Guide 27

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

You can define the number of REST API requests in the System Access view. Limiting the number of
requests is essential to preventing DoS attacks as well as providing scalability.

The inbound proxy settings allow FortiAuthenticator to determine origin of the source IP address after the
traffic has been forwarded through a proxy:
* From the FORWARDED HTTP header
* From the X_FORWARDED HTTP header

You can also set FortiAuthenticator to restrict admin access based on trusted IP addresses or subnets, by
configuring valid FORWARDED “by” values.

FortiAuthenticator 6.4 Study Guide 28

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

The domain name system (DNS), ensures human-friendly hostnames are translated into IP addresses—the
DNS resolves hostnames. Specific FortiAuthenticator functionalities rely on the use of the DNS, for example,
any feature that requires sending notification emails to users or administrators. For this reason,
FortiAuthenticator must have a reliable and stable connection to a DNS server.

You can configure the DNS on the DNS page. The DNS servers must be reachable from the networks to
which FortiAuthenticator connects and should specify two different addresses: a primary and a secondary.
The secondary DNS server is used in cases where there is no reply from the primary DNS server.

The default primary and secondary DNS server addresses are the FortiGuard DNS servers. You can use
these or change the address to another.

Note that in an Active Directory (AD) environment and using AD authentication, you should use the domain
DNS servers as the DNS servers.

FortiAuthenticator 6.4 Study Guide 29

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

You can configure the default gateway associated with the interface on the Static Routing page.

The default gateway is the next hop that routes internal traffic to another, usually external, network. To
simplify, a default gateway acts as an entry and exit point in a network. All computers on your local network
need to know the default gateway IP address in order to access the Internet. To configure, click Edit and add
the next hop IP address of FortiAuthenticator to the Gateway field.

If you want to configure another port on FortiAuthenticator, you can assign specific IPv4 or IPv6 static routes
to a different gateway so that packets are delivered by a different route. Click Create New to create a new
route. Here, you need to configure the destination IP address and mask, the gateway, and the interface (port).

You can create, edit, and delete the static routes.

FortiAuthenticator 6.4 Study Guide 30

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

You can either manually set the FortiAuthenticator system time and date, or configure FortiAuthenticator to
automatically keep its system time correct by synchronizing with an NTP server. NTP is a standard protocol
used for clock synchronization. You should synchronize FortiAuthenticator with an NTP server because, for
many features to work, the FortiAuthenticator system time must be accurate.

For example, for the time-based one-time password (TOTP) method used in two-factor authentication to
function correctly, it is critical for the time to be accurate and stable. NTP servers provide this necessary
accuracy and stability.

You can configure NTP servers in the System Information widget. In the System Time field, click Change
and then enable NTP enabled, and type the IP address of the NTP server. By default, the FortiAuthenticator
uses Fortinet NTP servers (ntp1.fortinet.net).

FortiAuthenticator 6.4 Study Guide 31

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

It’s always a good idea to make sure all the integral configurations are in place, such as:
• Network interfaces
• DNS servers (required for token/SMS/license registration)
• Time zone and NTP server (critical if using time-based tokens)
• License (trial license provides limited functionality)
• Mail servers (After configuration, don’t forget to set the default mail server!)

FortiAuthenticator 6.4 Study Guide 32

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

As a best practice, after complete the FortiAuthenticator deployment, you should back it up to your
management computer. The Restore/Backup option is located in the dropdown list in the upper-right of the
GUI.

The backup includes both the CLI and GUI device configurations. It also includes information on users, user
groups, the FortiToken device list, the authentication client list, the LDAP directory tree, FSSO settings,
remote LDAP, and certificates.The backup file is encrypted to prevent tampering. You can create multiple
backups, from different points in time. Make sure you name the file to indicate the time of the backup.

If you make changes to FortiAuthenticator that negatively affect your network, you can restore a configuration
from any of the backups.

The backup files can be encrypted using a password. The administrator must supply the password when
restoring an encrypted configuration file. Encryption is disabled by default. The backup files can be password
protected to prevent unauthorized restoration.

Note that you can restore the configuration only to the same build and hardware version.

FortiAuthenticator 6.4 Study Guide 33

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

This diagram shows all the FortiAuthenticator ports. It is a useful reference that you can use when you
configure your FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 34

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

Finally, to locate general system and diagnostic information, you can enter the status and hardware-
info commands on the CLI.

The get system status command displays the firmware build number, unit serial number, system time,
disk usage and size, and HA status.

The get hardware command displays information about the CPU, memory, NIC, disk, and RAID.

FortiAuthenticator 6.4 Study Guide 35

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 36

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 37

 Introduction and Initial Configuration

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned about the key features of FortiAuthenticator,
and how to configure FortiAuthenticator for initial setup.

FortiAuthenticator 6.4 Study Guide 38

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the key features and concepts of FortiAuthenticator and how to configure
FortiAuthenticator for initial setup.

FortiAuthenticator is the central device for any authentication infrastructure.

FortiAuthenticator 6.4 Study Guide 39

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 40

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in the initial configuration of FortiAuthenticator, you will be able to set up
administrator privileges and provide administrator roles to users.

FortiAuthenticator 6.4 Study Guide 41

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

FortiAuthenticator includes two administrator profiles by default (Sponsor and Read-only Administrator).
You can create additional administrator profiles using the permission sets and individual permissions.

An administrator profile comprises one or more permission sets. A permission set, in turn, comprises
individual permissions. For example, the Local LDAP Service permission shown on this slide includes the
individual permissions within this permission set. Note that the list of permissions shown on this slide is not
the full list.

Administrative profiles are useful for dividing responsibilities and controlling administrator access. For
example, an administrator user who has been granted only the Certificate Management permission set
cannot add or delete local users, because those permissions are assigned, by default, to a different
permission set (users and devices).

By default, the admin administrator has full access, which includes all permission sets and associated
permissions.

FortiAuthenticator 6.4 Study Guide 42

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You can create administrator profiles on the Admin Profiles page. You must assign a name to the profile and
optionally provide a description.

You can specify whether the admin profile:

• Should not have one of the default permission sets, by selecting None next to the permission set
• Should have read access to that permission set only, by selecting Read-only next to the permission set
• Should have read and write access to that permission set, by selecting Read & Write next to the
permission set.

To see which individual permissions make up a permission set, click Permission sets, and then click the
permission set name.

FortiAuthenticator 6.4 Study Guide 43

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

After you click Permission sets, the full list of built-in permission sets opens.

Built-in permission sets are static. You cannot add or remove individual permissions; however, you can clone
the built-in permission sets and then customize the cloned permission sets.

In this lesson, you will look at how to clone and modify a built-in permission set and create a new, custom one.

FortiAuthenticator 6.4 Study Guide 44

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

To clone an existing permission set for customization, select the permission set you want to clone and click
Clone. A page opens that shows you which permissions are currently associated with the cloned permission
set (these are located on the Selected user permissions pane), and which permissions are available to use
(these are located on the Available user permissions pane). You can move permissions to and from these
two panes using the arrow buttons.

FortiAuthenticator 6.4 Study Guide 45

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

If you would rather create a new permission set than clone an existing one, click Create New. Provide your
new permission set with a name and then move individual permissions from the Available user permissions
pane to the Selected user permissions pane.

You can continue to add or remove permissions at any time. Just ensure the name or description aptly
identifies the permission set after modification.

FortiAuthenticator 6.4 Study Guide 46

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

After you have some administrator profiles, you can create administrator user accounts and assign profiles.
You can create an administrator user account on the Local Users page by clicking Create New. You must set
a user name and password.

There are three ways to handle the password. You can specify a password and communicate it to the
administrator user, have FortiAuthenticator create a random password and automatically email it to the
administrator user (you must assign an email to the user), or specify token-based authentication rather than
password-based authentication. With the last option, FortiAuthenticator adds the account, but it is disabled
until you associate a FortiToken with the user account. You will examine FortiTokens further in another
lesson.

FortiAuthenticator 6.4 Study Guide 47

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

In the Role field, select Administrator to make the user an administrator user. As you can see, administrator
accounts on FortiAuthenticator are standard user accounts (local or remote users) flagged as administrators.
You will learn about creating end users in another lesson.

You can assign the administrator full permissions, which provides all permission sets and associated
permissions like a super user (this is what the admin administrator is assigned), or select a preconfigured
administrator profile in the Admin profiles drop-down list.

FortiAuthenticator 6.4 Study Guide 48

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

After you add the administrator user account, you are presented with additional account settings that you can
configure, such as:

• Admin profiles: You can apply multiple administrator profiles to an administrative account. The most
permissive of the union will be applied.
• Web service access: Allows administrators to access web services using REST API or a client
application.
• Restrict admin login from trusted management subnets only: Allows you to restrict administrator
access to the GUI based on IP address. You can even restrict an administrator to a single IP address if you
define only one trusted host IP. However, FortiAuthenticator allows you to configure up to 10 trusted hosts.

You can also expand each of the sections shown on the slide to configure additional settings. This includes
specifying additional user information (address, phone/mobile number, language, and organization),
alternative email addresses, groups, email routing, and more. You can also set password recovery options.
Here, FortiAuthenticator can send local users a password recovery link for lost or forgotten passwords,
through email or in a browser, in response to a prearranged security question. The user must then set a new
password.

FortiAuthenticator 6.4 Study Guide 49

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You can define certificate bindings and RADIUS attributes as part of a local user configuration for use during
authentication. The certificate bindings require a designation of the common name (CN) on the certificate as
well as the certificate authority (CA). The defined RADIUS attributes will be passed upon authentication to the
authenticator. These attributes can specify user-related information.

FortiAuthenticator 6.4 Study Guide 50

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

When you complete the creation of an administrative user, or attempt to apply modifications to an existing
administrative user, you must supply the currently logged-in administrative user’s password as validation. This
validation provides an additional layer of security. If validation is not successful FortiAuthenticator ends the
user's session.

FortiAuthenticator 6.4 Study Guide 51

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 52

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

Good job! You now understand the administrator profiles of FortiAuthenticator.

Now, you will learn about high availability (HA) modes and messaging services.

FortiAuthenticator 6.4 Study Guide 53

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in HA and messaging services, you will be able to explain the different HA
modes; list the HA roles; configure message settings for SMTP, email, and SMS gateway; and configure
SNMP.

FortiAuthenticator 6.4 Study Guide 54

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

If your deployment has more than one FortiAuthenticator device, you can choose to operate the
FortiAuthenticator devices as an HA cluster, to provide even higher reliability. All devices must run the same
firmware version.

You can configure HA in the following modes:

• Cluster (active-passive) mode (Cluster member designation in the GUI): In this mode, everything is
synchronized and is failover only. You designate one device as the primary and one as the secondary.
Layer 2 connectivity is required for data synchronization.
• An active-passive cluster can have up to 10 load-balancers.
• Active-passive clusters cannot be a mix of physical and virtual appliances.
• Load-balancing (active-active mode or geo-HA). In this mode, one device acts as the primary (Standalone
Primary designation on the GUI) with up to 10 load balancing systems (Load Balancer designation on the
GUI). You can separate the load balancers geographically, and you can distribute the load across the
devices using your preferred method, such as round-robin DNS, or Auth/NAS client load distribution. You
can also use external load balancing devices. This type of configuration is intended for two
FortiAuthenticator deployments because it syncs the user authentication configuration (such as users,
groups, tokens, and so on). It does not sync FSSO and certificates.
• Load balancing can use a mix of physical and virtual appliances.

FortiAuthenticator 6.4 Study Guide 55

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You can configure load balancing as part of a FortiAuthenticator active-passive cluster to achieve fault
tolerance. In the example shown on this slide, Ottawa and Ottawa-DR are configured in an active-passive HA
configuration. Layer 2 connectivity between Ottawa and the Ottawa-DR location is required for
synchronization. If Ottawa became unresponsive, Ottawa-DR would no longer receive updates and would
become the primary. You select a port to be dedicated for data synchronization between the active and
standby FortiAuthenticator. The interface should not have an IP address already assigned and it must be the
same interface on both the primary and standby device. Fortinet recommends a direct cable connection for
data synchronization.

You can synchronize administrator or sponsor accounts. Each administrator and sponsor account has an
option to include the account in load balancing HA configurations. In addition, FortiAuthenticator synchronizes
certificate bindings for both local and remote users.

FortiAuthenticator 6.4 Study Guide 56

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You enable HA on the High Availability page. Depending on which HA role you select, different fields appear
in order to configure that particular role.

Cluster member: In the cluster member role, one device is active and the other is on standby (passive). If the
active device fails, the standby becomes active. The cluster is configured as a single authentication server on
FortiGate. Authentication requests made during a failover from one device to another are lost, but subsequent
requests complete normally. The failover process takes approximately 30 seconds. You can configure up to
10 load balancing devices.

Use one of the maintenance modes when you need to make changes to a system setup and quickly return to
it to its HA role. The three maintenance mode options are:

• Disabled: Unit is not in maintenance mode.

• Enabled with synchronization: Unit is in maintenance mode and continues to synchronize data, similar to
the passive unit in a active-passive deployment.
• Enabled without synchronization: Full maintenance mode, not participating in HA.

Interface: The interface that will be used for data synchronization between the primary and standby
FortiAuthenticator. The IP address for this interface is configured here.

Password: A password must be entered for use as a shared key for Ipsec encryption, and must be the same
on both the primary and standby devices.

FortiAuthenticator 6.4 Study Guide 57

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You can use load balancing as an HA method across geographically separated locations and Layer 3
networks. In this configuration, FortiAuthenticator is designated as the standalone primary device. Up to 10
other FortiAuthenticator devices can be configured as load balancers. The standalone primary device keeps
the load balancers synchronized, and the traffic is balanced using an external method chosen by the
administrator.

FortiAuthenticator 6.4 Study Guide 58

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You configure geographically distributed load balancing on the High Availability page.

The Role setting for the standalone primary FortiAuthenticator should be Standalone primary. The
standalone primary is the primary system where users, groups, and tokens are configured. The load
balancers are synchronized to the primary. To improve the resilience of the primary system, up to 10 load-
balancer devices can be configured.

The Password field must configured in the standalone primary configuration, and again in the load balancer
configurations.

The load balancing FortiAuthenticator devices must be added to the Load Balancers list using the Add
Secondary Load Balancer button. You must provide a name and IP address for each load balancer.

FortiAuthenticator 6.4 Study Guide 59

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

The Role setting for each FortiAuthenticator that will participate as a load balancer must be Load Balancer.
The Load Balancing primary IP address field must contain the IP address of the standalone primary. The
Password field must match the password set in the standalone primary configuration.

FortiAuthenticator 6.4 Study Guide 60

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

FortiAuthenticator can be also be configured as an active-passive cluster with geographically distributed load
balancing. In the example shown on this slide, Ottawa and Ottawa-DR are configured in an active-passive HA
configuration.

Regardless of which member of the active-passive cluster is currently active, the load is distributed across the
load balancers, using your preferred method, such as round-robin DNS, Auth/NAS client load distribution, or
external load balancing devices. The primary and secondary systems can also each function as a standalone
primary device.

FortiAuthenticator synchronizes certificate bindings to load balancers for both local and remote users.

FortiAuthenticator 6.4 Study Guide 61

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

The HA Status page displays the current status of the device, including Node type (for example, Cluster
member, Standalone Primary, or Load Balancer), Priority (high or low), Serial number, and Status.

FortiAuthenticator 6.4 Study Guide 62

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

By default, FortiAuthenticator uses the built-in SMTP server. This is provided for convenience, but is not
necessarily optimal for production environments. Antispam methods can block mail, so you should relay email
through an official, external mail server for your domain.

To configure a new SMTP server, you require a name, server IP address, port (default 25), and sender email
address. You can also choose to use a secure connection to the mail server by selecting STARTTLS. Note
that you must import the CA certificate that validates the server’s certificate for STARTTLS to work. You will
examine CA certificates in another lesson.

Lastly, if the email server requires that you authenticate when sending mail, you can enable authentication
and set the account username and password.

FortiAuthenticator 6.4 Study Guide 63

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You can select any configured SMTP server and click on the Set as Default button to designate that server
as the default SMTP server. On the Email Services page, you can select the server that will be used by
administrators and the server that will be used for users. The SMTP Server drop-down list will contains all
configured SMTP servers, as well as a selection to use the server marked as default.

FortiAuthenticator 6.4 Study Guide 64

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

To provide more actionable information, FortiAuthenticator provides detailed logging of failed SMTP send
attempts for administrative users. You can review these logs in the Logs view.

FortiAuthenticator 6.4 Study Guide 65

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

FortiAuthenticator provides two distinct email services: one for administrators and one for users.

For each recipient group (administrators and users), you can specify the SMTP server to use, as well as
customize the public address, which is the address or link to the site that the email recipients will receive.
Options include:

• Automatic discovery: Use DNS domain name if configured, or automatically obtain address from the
browser or an active network interface.
• Specify an address: Manually enter the address and port number.
• Use the IP address for a network interface: Select a specific network interface in the drop-down list.

FortiAuthenticator 6.4 Study Guide 66

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

If you want to send SMS messages to users, you must configure the SMS gateways. The FortiAuthenticator
SMS gateway configuration differs according to the protocol your SMS provider uses, such as SMTP, HTTP,
or HTTPS, so you must ask your SMS provider for information about using its gateway.

When configuring SMS gateways you can specify how the mobile number is sent. The available options are
JSON String and JSON Number.

FortiAuthenticator 6.4 Study Guide 67

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

SNMP allows you to monitor hardware on your network. You can configure the hardware, such as the
FortiAuthenticator SNMP agent, to report system information and send traps (alarms or event messages) to
SNMP managers. An SNMP manager, or host, is typically a computer running an application that can read the
incoming trap and event messages from the agent, and send SNMP queries to the SNMP agents.

Using an SNMP manager, you can access SNMP traps and data from any FortiAuthenticator interface
configured for SNMP management access. Part of configuring an SNMP manager is listing it as a host in a
community on the FortiAuthenticator device it will be monitoring. Otherwise, the SNMP monitor does not
receive any traps from that device, and cannot query that device.

Note that the FortiAuthenticator SNMP implementation is read-only. SNMP v1, v2c, and v3 managers have
read-only access to system information through queries and can receive trap messages from
FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 68

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

You can configure SNMP on the SNMP page. The SNMP settings allow you to set the thresholds that trigger
various SNMP traps. Note that a setting of zero disables the trap.

However, before you can monitor FortiAuthenticator system information and receive FortiAuthenticator traps,
you must do the following:

• Configure one or more interfaces to accept SNMP connections. This allows a remote SNMP manager to
connect to the Fortinet agent. You can enable SNMP connections by enabling the SNMP service on the
required interface.
• Download the Fortinet and FortiAuthenticator MIB files for your SNMP manager. A MIB is a text file that
lists the SNMP data objects that apply to the device to be monitored. These MIBs provide information that
the SNMP manager needs to interpret the SNMP trap, event, and query messages sent by the
FortiAuthenticator SNMP agent. You can download the MIB files on the SNMP page on the GUI or from
the Customer Service & Support portal at https://support.fortinet.com. They are located in the
Firmware Images folder for the FortiAuthenticator product.

FortiAuthenticator 6.4 Study Guide 69

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 70

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 71

 Administrative Users and High Availability

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this
lesson, you learned about the key features of FortiAuthenticator, and how to configure FortiAuthenticator for
initial setup.

FortiAuthenticator 6.4 Study Guide 72

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to administer user account policies and management settings, and how to
authenticate users through LDAP and RADIUS, as well as the self-service portal.

FortiAuthenticator 6.4 Study Guide 73

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

In this lesson, you will explore the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 74

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in creating local users, you will be able to import users, manually add users,
assign user roles, and describe RADIUS attributes.

FortiAuthenticator 6.4 Study Guide 75

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

There are two ways you can add local users to FortiAuthenticator:
• Import users from a CSV file or FortiGate configuration file
• Manually add users

Note that FortiAuthenticator does include a self-service portal, so users can register themselves. Self-
registration is covered in this lesson.

FortiAuthenticator 6.4 Study Guide 76

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can import local user accounts from a CSV file or from a FortiGate configuration file, on the Local Users
page.

If you are importing from a CSV file, the file must contain only one record per line in the accepted format. The
accepted format is available in the FortiAuthenticator Administration Guide. If you do not include the optional
password in the record, FortiAuthenticator emails the user temporary login credentials and requests that the
user configure a new password.

If you are importing from a FortiGate configuration file, FortiAuthenticator provides the following options:
• Import users only
• Import users and only their associated FortiToken hardware
• Import all users and the FortiToken hardware (imports unassigned FortiTokens as well)

You must also enter the password associated with the FortiGate configuration file when importing, if one is
assigned.

FortiAuthenticator 6.4 Study Guide 77

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

The other way you can add local users is by manually creating them. You can do this on the same Local
Users page by clicking Create New.

First, you must set a username (253 characters or less and can include only letters, digits, and specific
symbols) and a password. There are three ways to handle the password:

• Specify a password: The administrator assigns a password immediately, and communicates it to the
user.
• Set and email a random password: FortiAuthenticator creates a random password and automatically
emails it to the new user. To use this option, you must enter the email address of the user.
• No password, FortiToken authentication only: No password is assigned because only token-based
authentication will be used. If you select this option, the user account is added, but is disabled until you
associate a FortiToken with the user account. You will learn more about FortiTokens later in this lesson.
• Allow RADIUS authentication: Locally created users will be allowed to authenticate through RADIUS.

FortiAuthenticator 6.4 Study Guide 78

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

After you set the user name and password, you must assign a user role. You can select Administrator to
create an administrator account, or User to create a user account. This lesson focuses on creating end users.
To create an end user, select User as the role. After you select the user role, you can enable account
expiration in the event the user never activates the account or the account is meant to be temporary. You can
set the user account to expire after a set length of time (for example, 8 hours) or by a specific date. After you
add the local user account, FortiAuthenticator provides additional account settings that you can configure.

Similar to administrator users, you can specify additional user account information (address, phone/mobile
number, language, and organization), alternative email addresses, password recovery options, groups, and
email routing.

However, there are additional settings specific to user accounts, including:

• Allow LDAP browsing: This allows viewing of directory contents (that is, read-only operations that do not
modify LDAP directory contents). It applies only to non-administrator users.
• RADIUS Attributes: This allows FortiAuthenticator to receive information about an authenticated user
through RADIUS vendor-specific attributes. Attributes in user accounts can specify user-related
information. You will learn about RADIUS attributes in more detail, in this lesson.
• Certificate Bindings: This allows you to bind a local certificate to a user’s account.

The Sponsor role is equivalent to an administrator with read-write permissions to the Guest Users submenu
only.

FortiAuthenticator 6.4 Study Guide 79

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

Some RADIUS clients can receive information about users through vendor-specific RADIUS attributes. When
a RADIUS user successfully authenticates, FortiAuthenticator sends the user’s RADIUS attributes and values
to the RADIUS client.

The example shown on this slide passes FirewallAdmins to the client for remote user aduser1 as the
Fortinet attribute Fortinet-Group-Name. As another example, there is a Fortinet-proprietary attribute called
Fortinet-Client-IP-Address. It specifies the IP address assigned to that specific user when establishing an
SSL VPN tunnel. So, you can configure FortiAuthenticator and FortiGate to always assign the same static IP
address to a user. FortiAuthenticator stores the IP addresses as part of the user account information and
sends them to FortiGate, after the user has successfully authenticated.

You can configure RADIUS attributes on the Local Users or Remote Users pages.

FortiAuthenticator 6.4 Study Guide 80

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can also configure RADIUS attributes per user group on the User Groups page. In the example shown
on this slide, members of the group Firewall Admin have the Fortinet attribute Fortinet-Group-Name
returned with a value of Remote-AD-admins. If attributes have been set on both a user and group level, the
client will determine how to handle the multiple attributes.

FortiAuthenticator 6.4 Study Guide 81

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 82

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

Good job! You now understand how to create local users.

Now, you will learn how to configure remote authentication servers.

FortiAuthenticator 6.4 Study Guide 83

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring remote authentication servers, you will be able to describe
remote authentication with LDAP and RADIUS as well as importing remote users.

FortiAuthenticator 6.4 Study Guide 84

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can configure FortiAuthenticator to connect to a remote LDAP server on the LDAP page. You must enter
all required information about the remote LDAP server, such as the IP address (or FQDN) as well as the
connecting port. You also have the option to set up a secondary server. When adding the base distinguished
name (dn) of the remote LDAP server, you must use the correct X.500 or LDAP format.

When selecting a bind type, which determines how the authentication information is sent to the server, you
can select:
• Simple, to bind using the user’s password, which is sent to the server in plaintext without a search.
• Regular, to bind using the user’s dn and password and then perform a search. Regular bind is required, if
searching for a user across multiple domains.

You can select a server type and apply an associated template. The template populates the Query Element
fields for that server type.

If you want to have a secure connection between FortiAuthenticator and the remote LDAP server, enable
Secure Connection and include the LDAP server protocol (LDAPS or STARTTLS) as well as any trusted CA
certificates.

FortiAuthenticator 6.4 Study Guide 85

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can configure FortiAuthenticator to connect to a remote RADIUS server on the RADIUS page. You can
also use this feature to migrate away from third-party two-factor authentication platforms. Support for RADIUS
over TCP and TLS (RADSEC) ensures complete security.

You must enter all required information about the remote RADIUS server, such as the IP address, port, and
shared secret. You also have the option to set up a secondary server for redundancy.

If you want to record and learn what users are authenticating against this RADIUS server, enable Enable
learning mode in the User Migration section. You should enable this option if you need to migrate users
from the server to FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 86

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You add remote LDAP and remote RADIUS users to FortiAuthenticator differently.

For remote LDAP users, you must import users into the FortiAuthenticator user database from their remote
LDAP servers.

You can create remote RADIUS users based on a remote RADIUS server. You can migrate remote RADIUS
users to LDAP users, as well as edit and delete them. You can also flag remote RADIUS users with the user
role or administrator role.

FortiAuthenticator 6.4 Study Guide 87

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can import remote LDAP users on the Remote Users page. In the upper-right corner, make sure LDAP
users is selected, and then click Import.

You must select a preconfigured remote LDAP server and then either import users or import users by group
membership.

After FortiAuthenticator connects to your preconfigured LDAP server, you can see your remote users based
on the default LDAP filter (&(objectClass=user)(objectCategory=person)). The default configuration, shown on
this slide, imports the attributes commonly associated with Microsoft Active Directory LDAP implementations.
The filter value varies depending on the LDAP server type. You can also configure the user attributes to edit
the remote LDAP user mapping attributes.

Select the users you want to import. If you have organizations configured, you can choose to add users to a
specific organization.

FortiAuthenticator 6.4 Study Guide 88

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

The LDAP attributes, and the fields they are mapped to, can be defined using the User attributes button. This
provides you the flexibility to customized the attributes being imported.

FortiAuthenticator 6.4 Study Guide 89

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

FortiAuthenticator also allows you to create synchronization rules to control how and when remote LDAP
users are synchronized. You can do this on the Remote User Sync Rules page.

At a minimum, you must:

• Select the preconfigured remote LDAP server from where users will be synced.
• Specify the token-based authentication sync priorities. Drag and drop the options up and down the list to
set a priority order.
• Specify whether you want to sync users as remote LDAP users, Remote RADIUS users, or local users.
• Specify if you want to sync FIDO authentication for user accounts.
• Specify how often FortiAuthenticator should perform the sync (for example, every <x> minutes, every <x>
hours, or every <x> days).

When selecting to sync remote users as local users, FortiAuthenticator will create a password for the record.
All other user information will be synched.
You can assign roles to new user accounts, and create a group association.

FortiAuthenticator 6.4 Study Guide 90

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can create remote RADIUS users on the Remote Users page. In the upper-right corner, select RADIUS
users, then click Create New.

You need to select a preconfigured remote RADIUS server and create a username for the remote RADIUS
user. You can specify the type of authentication and select the user role to assign to the account, either
Administrator, Sponsor, or User.

Once created, you have the option to perform the following tasks on one or more accounts at the same time:
• Re-enable user accounts in the event they are disabled.
• Migrate RADIUS users to LDAP users.
• Set whether FortiAuthenticator should force token-based authentication (if configured) or whether it should
bypass it.

You also have the option to edit or delete any remote RADIUS user account.

FortiAuthenticator 6.4 Study Guide 91

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 92

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure remote authentication servers.

Now, you will learn how to configure LDAP and RADIUS services.

FortiAuthenticator 6.4 Study Guide 93

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring LDAP and RADIUS services, you will be able to set up the
FortiAuthenticator as a RADIUS or LDAP server.

FortiAuthenticator 6.4 Study Guide 94

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

When you configure the LDAP service on FortiAuthenticator, you must specify the LDAP server certificate
settings on the General page. This includes configuring:

• The certificate that the server will present

• The certificate authority (CA) type (that is, whether it is a Local CA or Trusted CA)
• The CA certificate that issued the server certificate

The LDAP User Auto Provisioning settings allow you to select which users are automatically provisioned
(added to), the FortiAuthenticator LDAP directory structure. In the example shown on this slide, the user
user1, was manually created in the GUI as a local user. User1 was then auto provisioned to selected
container in the directory tree. Users can be auto provisioned when they are created using any of the following
four methods:
• GUI (Manually created local users)
• GUI (Imported local users)
• Self-registration
• API

FortiAuthenticator 6.4 Study Guide 95

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

Another item you must configure is the LDAP directory tree. The directory tree includes a root distinguished
name (dn) and subordinate objects such as containers and leafs.

The root dn is the top level of the LDAP directory, such as dc=training,dc=lab, and there can be only one.
Everything else in your directory branches off the root dn. Choose a dn that makes sense for your
organization.

Place subordinate objects under the root dn. The objects you add depend on your requirements. Click the
green plus icon next to the root dn to add objects. In the example shown on this slide, the object is an
organizational unit (ou) container people.

Note that if your organization changes their structure or expands, you can move the branch in the LDAP
directory tree. Click and drag the branch from its current location to its new location.

FortiAuthenticator 6.4 Study Guide 96

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

This is an example of a simple LDAP hierarchy, where all user account entries reside at the organization unit
(ou) level, just below dc.

You must configure the FortiGate device (acting as an LDAP client) requesting authentication to address its
request to the correct part of the hierarchy, where user records exist. This is the distinguished name (dn). In
this example, the dn is ou=people,dc=training,dc=lab.

The authentication request must also specify the particular user account entry. This can be either the common
name (cn) or, on a computer network, the user ID (uid), because that is the information users use to log in.
Note that if the object name includes a space, such as John Smith, you must enclose the text with double
quotation marks. For example: cn=“John Smith”.

FortiAuthenticator 6.4 Study Guide 97

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You must add user entries at the appropriate place in the LDAP tree. Using the previous example, this would
be under ou=people. In the Class drop-down list, select Local User (uid), and then move the users that
appear in the Available Users list (left) to the Chosen Users list (right). The users must already be defined in
the FortiAuthenticator user database.

FortiAuthenticator 6.4 Study Guide 98

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

After you have defined the LDAP tree, you can configure FortiGate to access FortiAuthenticator as an LDAP
server and authenticate users.

On your FortiGate device, click User & Device > Authentication > LDAP Server, and then create a new
LDAP server with the FortiAuthenticator LDAP server information.

FortiAuthenticator 6.4 Study Guide 99

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

Before getting into the specifics about the RADIUS service on FortiAuthenticator, take a moment to review
what RADIUS is. RADIUS is a standard protocol that provides AAA services.

When a user is authenticating, the client (for example, FortiGate) sends an Access-Request packet to the
RADIUS server (for example, FortiAuthenticator). The reply from the server will be one of the following:

• Access-Accept, which means that the user credentials are valid

• Access-Reject, which means that the credentials are wrong
• Access-Challenge, which means that the server is requesting a secondary password ID, token, or
certificate. This is typically the reply from the server when using two-factor authentication.

Not all RADIUS clients support the RADIUS challenge method.

FortiAuthenticator 6.4 Study Guide 100

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

A RADIUS client on FortiAuthenticator is just a network access server (NAS) using a RADIUS infrastructure. It
provides some level of access to a larger network. The client sends connection requests and accounting
messages to a RADIUS server for authentication, authorization, and accounting.

You can add RADIUS clients on the Clients page. FortiAuthenticator sends answers only to the RADIUS
clients on this list. For example, for FortiAuthenticator to accept RADIUS authentication requests from
FortiGate, you must register the FortiGate as an authentication client on FortiAuthenticator. You must include
the IP of the client and the shared secret.

FortiAuthenticator allows both RADIUS and remote authentication for RADIUS authentication client entries.

FortiAuthenticator 6.4 Study Guide 101

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

RADIUS policies allow you to define the way RADIUS client requests are addressed by FortiAuthenticator. A
RADIUS policy can be applied to any number of RADIUS clients, and the RADIUS clients can be assigned to
multiple polices. The RADIUS clients tab provides you the ability to name the policy and select which RADIUS
clients will have their requests processed by that policies settings.

The RADIUS attributes criteria allows you to key on specific attributes within authentication requests before
the request is processed. The request can then be ignored, if it does not contain the required attributes.

FortiAuthenticator 6.4 Study Guide 102

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can include RADIUS clients in any number of RADIUS policies, and you can prioritize policies. Matching
RADIUS attributes can provide granularity during policy evaluation. The RADIUS request is processed as
defined by the matching policy with the highest priority. You can adjust the policy priority by clicking the
arrows in the Priority column.

In the example shown on this slide, users authenticating through M-FortiGate-1, and connecting to the
Contractor SSID, would have their credentials validated based on the ManchesterContractor policy. All
other users connecting through that FortiGate would get the ManchesterPolicy. All users connecting through
the Corp-FortiGate would be authenticated using the Fortigate_Default policy.

FortiAuthenticator 6.4 Study Guide 103

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

The Authentication type tab allows you to set the desired security protocol to one of the following:
• Password/OTP authentication: Allows for password or one time password (OTP) authentication. EAP
can be enabled for this option and limited to one or more EAP protocols (PEAP, EAP-TLS, EAP-GTC,
EAP-MSCHAPv2)
• MAC authentication bypass (MAB): Provides the option to authenticate based on MAC address, and can
offer a solution for non-802.1x capable devices.
• Client Certificates (EAP-TLS): Provides authentication through client certificates.

The Identity source tab can define the username format and any desired realms. Groups can be filtered for a
more granular end user designation.

Note that If you want to authenticate users in an Active Directory environment, enable the Windows Active
Directory Domain Authentication option on the LDAP server configuration screen and enter the required
Windows AD domain controller information. You can then configure your RADIUS client to specify whether
authentication is available for all Windows AD users, or only for Windows AD users who belong to specific
groups that you select.

FortiAuthenticator 6.4 Study Guide 104

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

The Authentication factors tab provides you the ability to define the allowed authentication methods, and the
RADIUS response tab summarizes the configuration for successful and failed results.

FortiAuthenticator 6.4 Study Guide 105

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

The FortiAuthenticator RADIUS service also employs the concept of realms. Realms allow multiple domains
to authenticate to a single FortiAuthenticator device and support both LDAP and RADIUS remote servers.
Each realm is associated with a name, such as a domain or company name, that is used during the login
process to indicate the remote (or local) database in which the user resides.

For example, if you are a service provider that hosts multiple domains and you want each domain to have
different permissions, you can set up a realm on FortiAuthenticator for each domain. So even though each
domain is using the same RADIUS client, realms allow you to control access and permissions.

You can create realms on the Realms page.

FortiAuthenticator 6.4 Study Guide 106

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

The connection between RADIUS clients and the server used for authentication is defined by the RADIUS
policy. The diagram shown on this slide visually represents the relationship. It illustrates that the RADIUS
client points to FortiAuthenticator, and based on the RADIUS policy, FortiAuthenticator validates the
authentication request. RADIUS policy-3 has been configured with multiple realms, and the AD realm has
been further filtered to a specific group. Users without a realm appended to the user name are authenticated
against the default realm (internal DB). Users with the AD realm appended to the username, are authenticated
against the Active Directory, and must be a member of the designated group (StandardUsers).

FortiAuthenticator 6.4 Study Guide 107

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

You can designate the ports FortiAthentictor uses for the different RADIUS services. The example shown on
this slide displays the default values.

FortiAuthenticator 6.4 Study Guide 108

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 109

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 110

 Administering and Authenticating Users

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to administer user account policies and
management settings, and how to authenticate users through LDAP and RADIUS as well as the self-service
portal.

FortiAuthenticator 6.4 Study Guide 111

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to manager user account policies and management settings, , configure the
self-service portal, and troubleshoot authentication issues.

FortiAuthenticator 6.4 Study Guide 112

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

In this lesson, you will explore the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 113

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives on this slide.

By demonstrating competence in configuring user account policies, you will be able to understand the lockout
policy settings, password policy settings, and configure the custom user fields.

FortiAuthenticator 6.4 Study Guide 114

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

On the General Settings page, you can configure some user account settings. You can:

• Automatically purge disabled user accounts at a scheduled time (for example, weekly at 2 AM) and purge
users that were disabled for any of the following reasons: They were manually disabled, they were
inactive, or their account expired.
• Discard stale RADIUS authentication requests.
• Look up geo-location based on user IP address.

FortiAuthenticator 6.4 Study Guide 115

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

FortiAuthenticator allows you to lock a user account after repeated unsuccessful attempts to log in, which may
indicate an attempt at unauthorized access. You can configure the lockout policy settings on the Lockouts
page by selecting Enable user account lockout policy setting. By default, users are locked out after three
failed login attempts. If you decide to change the default value, ensure it provides room for human error, while
still securing your network from attacks. Usually, from three to five attempts are used. It is advised to enable a
lockout policy.

Along with enabling a lockout policy, you have the option to specify a lockout period. The default is set to 60
seconds (that is, users are locked out for 60 seconds after three failed login attempts), but you can set it to
between 60 and 86,400 seconds. If you disable this setting, FortiAuthenticator permanently disables locked-
out users until an administrator (with appropriate permissions) manually re-enables them.

Finally, you can disable user accounts if there is no login activity for a specified number of days. If you enable
this setting, you must specify the number of days a user account can be inactive before being locked out. The
inactive user lockout period must be between 1 and 1825 days.

You can monitor your top locked-out users on the dashboard, in the Top User Lockouts widget. You can
view currently locked-out users on the Locked-out Users page.

FortiAuthenticator 6.4 Study Guide 116

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

For security purposes, you may also want to enforce password complexity for user passwords, as well as
force users to change their passwords after a specified time has passed.

You can configure the password policy settings on the Edit Password Policy page.

User Password Complexity settings include:

• Specifying a minimum length for users passwords.
• Configuring password requirements, such as the minimum number of upper-case letters, lower-case
letters, numeric characters, and non-alphanumeric characters.

User Password Change Policy settings include:

• Configuring whether users are required to change their password after a set period of time. Users are
notified through an email, when their password is expiring. Accounts with expired passwords are disabled.
• Configuring whether to prevent users from creating a new password that is the same as the current
password or recently used ones.
• Configuring whether to force random generated passwords to expire after a set number of hours. Random
passwords are meant to be temporary, and as such, the active period is generally low, for security
purposes.

FortiAuthenticator 6.4 Study Guide 117

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

FortiAuthenticator allows you to create custom fields that you can use to gather user information not
represented by the default fields.

You can configure the custom fields on the Custom User Fields page. Click the Edit icon associated with the
custom field and enter your custom field in the text box that appears. The custom field will appear in the User
Information portion of local user records, and can be populated by users during self-registration.

You can add a maximum of three custom fields.

FortiAuthenticator 6.4 Study Guide 118

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 119

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure user account policies and management settings.

Now, you will learn about configuring the self-service portal.

FortiAuthenticator 6.4 Study Guide 120

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring the self-service portal, you will be able to configure the self-
service portal and replacement messages, and set up user self-registration.

FortiAuthenticator 6.4 Study Guide 121

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

In order to allow users to self register, you must first configure the self-service portal. Users must access the
portal to complete various self-service tasks. You can configure the general settings of the portal on the portal
page. These include:

• Name: The name of the portal

• Description: An optional field to add information
• SMS gateway: Designate an SMS gateway for self-registration users
• Pre-Login Services: Available options before user registration or login
• Post-Login Services: Services provided to the user after login

FortiAuthenticator 6.4 Study Guide 122

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Pre-Login services allow you to define the services available to a user before login. A disclaimer can be
presented to the end user, and they must accept it before proceeding to the login page. The disclaimer can be
customized in the Login Disclaimer Page under the Replacement Messages view. You can also provide the
users with a password reset link in the event they have forgotten their password.

To enable users to request registration through the FortiAuthenticator login page, you must enable the
Account Registration pre-login service option.

After you enable self-registration, you are presented with configuration options for the self-registration
process. For example, you can:
• Specify mandatory administrator approval for every self-registration.
• Set the account to expire after a specified period of time.
• Set the user’s mobile number as their user name.
• Place users in a pre-defined group.
• Specify how the user password is created (user defined or randomly generated).
• Specify how the account information is sent to the user (SMS or email).
o If administrator approval is not required, you have the option to display the account information on
the browser page.

In the Required Field Configuration section, you can also specify which information-gathering fields are
required when a user registers (for example, first name, last name, and email address), and can include any
custom user fields.

FortiAuthenticator 6.4 Study Guide 123

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

You can grant users the ability to perform self-revocation and reprovisioning of tokens, directly from the user
portal. The user portal includes a link for this capability. Users can revoke FortiToken and FIDO tokens and
use other OTP options.

The Usage Extension Notifications option allows a user who has exceeded their allowed time or data usage
settings to request an extension.

FortiAuthenticator 6.4 Study Guide 124

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Post-login services provide the users the ability to manage many aspects of their account. They include the
following:

• Profile: Allow authenticated users to view or edit their account information.

• Password Change: Allow local and/or remote users to change their passwords.
• Token Registration: Allows you to grant users the ability to self-provision the different types of
FortiTokens or FIDO tokens directly from the user portal, and can be restricted to the group level.
• Smart Connect: Assign a Smart Connect connection profile for automated wireless configuration.
• Device Tracking and Management: Require users to register their devices, and also place registered
devices in a MAC device user group.

FortiAuthenticator 6.4 Study Guide 125

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Replacement messages are customized messages FortiAuthenticator sends to users upon self-registration.
You can view and customize the default messages on the Replacement Messages page. You may need to
do this based on your self-service configuration. For example, on the pre-login services view you learned that
administrators can specify which information-gathering fields they want to display to the user when they self-
register. The default self-registration message may include fields asking for information you didn’t ask for from
the user. As such, you have to remove those fields from the message.

To customize, select the default message and edit the plain text or HTML code. You can always restore the
default message, if required.

On this page, you can also manage images you want to include in the message. For example, you can
manage your company logo or images containing links to your company’s social media pages.

FortiAuthenticator 6.4 Study Guide 126

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

On the Policy type page, you specify a name for the portal policy, an optional description, and the portal to
associate with the policy.

On the Identity sources page, you can configure which users or groups can access the network. You must
specify:

• The input format for the user name. Options include username@realm, realm\username,
realm/username. The realm name is optional when authenticating against the default realm.
• The realm(s) with which the user will be associated. This is the default realm for this client. You can add
additional realms by clicking Add a realm. Note that you must have preconfigured these realms.
• Whether to allow local users to override remote users.

You can use the group filter to filter users based on group membership.

FortiAuthenticator 6.4 Study Guide 127

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

The Authentication factors page is where you specify which authentication factors to verify by selecting one
of the following options:
• Mandatory password and OTP: Requires two-factor authentication.
• All configured password and OTP factors: Two-factor authentication is necessary if it is enabled on the
user’s account.
• Password-only: Does not require two-factor authentication.
• OTP-only: Token verification only.
• Adaptive Authentication: Users can bypass OTP validation if they belong to a trusted subnet.
• FIDO authentication (effective once a token has been registered): Once a user has a Fast ID Online
(FIDO) token registered they can be required to log in with only the FIDO token or both a password and the
FIDO token.

The Advanced options provide the option to leverage FortiToken push notifications, resolve users’
geolocation based on their IP address, and reject usernames containing uppercase letters.

FortiAuthenticator 6.4 Study Guide 128

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

The post-login options you configured on the portal appears after a user successfully authenticates. By
default, the options appear as buttons. The example shown on this slide is a portal with each of the five post-
login options enabled:
• Profile
• Password Change
• Token Registration
• Device Tracking and Management
• Smart Connect

FortiAuthenticator 6.4 Study Guide 129

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

After you configure the self-service portal, users can self-register.

Step 1: A user must connect HTTP or HTTPS to the FortiAuthenticator GUI. When self-registration is enabled,
the access login page shows a Register link.

Step 2: After clicking Register, the user is presented with a form with information-gathering fields, such as
username, name, email and so on. If you did not configure FortiAuthenticator to randomly generate
passwords, the user must also specify a password.

Step 3a: If FortiAuthenticator is configured so that administrator approval is required for self-registrations, the
administrator receives an email that contains a link to the new user request (with filled-out form) and the
option to either approve or deny the registration.

Step 3b: After the account is approved (whether by an administrator or automatically), the user will receive a
confirmation through the medium you specified while configuring the self-service portal. This could be email,
SMS, or, if no administrator approval is required, on the browser page. If you configured FortiAuthenticator to
use randomly generated passwords, the email or SMS confirmation will contain the user password.

FortiAuthenticator 6.4 Study Guide 130

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 131

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure the self-service portal.

Now, you will learn about troubleshooting.

FortiAuthenticator 6.4 Study Guide 132

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in troubleshooting, you will be able to debug using the FortiAuthenticator logs
and extended logs.

FortiAuthenticator 6.4 Study Guide 133

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

On the Logs page on the GUI, you can find the normal level of debugging required for everyday use. Log
types include:

• Admin Configuration, for changes in the configuration

• Authentication, for successful or unsuccessful authentication events
• System, for system events such system restarts and firmware upgrades
• High Availability, for high availability sync and failover events
• User Portal, for logins for the user portal

You can also download a debug report, which is encrypted, and send it to the FortiAuthenticator team for
further investigation, if necessary.

FortiAuthenticator 6.4 Study Guide 134

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

This slide shows some example logs for portal login and RADIUS login, with both user name and password as
well as token.

FortiAuthenticator 6.4 Study Guide 135

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

You can find more detailed debug logs at https://<FortiAuthenticator_IP>/debug.

In the Service drop-down list, you can select the service from which you want to gather logs. The RADIUS
authentication service allows you to enable verbose logging by clicking Enter debug mode. This has a
performance impact, so remember to turn it off.

The max log file size can be selected from a list ranging from 200 KB and 500 MB. The logs is displayed in
pages, with the number of entries defined by the user. Clicking the download icon will download log.

FortiAuthenticator 6.4 Study Guide 136

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

If your logs do not go back as far as you want, check the Log Settings page for your log configuration. You
may have set them to automatically delete. However, if you configured your logs to remotely back up to an
FTP server or syslog server, you may be able to find your history logs there.

FortiAuthenticator 6.4 Study Guide 137

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

When debugging RADIUS issues, ensure you verify the user configuration on the User Management page.
Check whether the account has been accidentally disabled. Also check whether the correct token is assigned
to the user. You may want to disable the token to rule out any issues.

By default, RADIUS authentication is enabled, but you can disable it per user.

FortiAuthenticator 6.4 Study Guide 138

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Another thing to check is the RADIUS client configuration. Verify that the secret and RADIUS client IP are
correct? Remember, the IP could be changed if you are using NAT.

FortiAuthenticator 6.4 Study Guide 139

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Another thing to check is the RADIUS policy configuration. Here are some things to consider:

• Is the correct realm being authenticated? Try allowing local user override and testing with a local user.
• Are there any group filters in place? Try removing and testing again.
• Are you using MSCHAPv2 in place of PAP, and an external active directory (AD)? If so, make sure to
enable Use Windows AD domain authentication.
• Are you using RADIUS attributes to assign different RADIUS policies? It’s often helpful to walk through
each step of the policy to validate settings.
• Is two-factor authentication enforced when the user has no token?

FortiAuthenticator 6.4 Study Guide 140

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

If you are still experiencing issues with RADIUS, there are three steps that you should take.

The first step is to verify whether traffic is reaching FortiAuthenticator. Use the various tcpdump commands in
the CLI. Then, if no traffic is reaching FortiAuthenticator, validate the intervening firewall policies and the
RADIUS client configuration.

FortiAuthenticator 6.4 Study Guide 141

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

The second step is to check the log files. Try the following recommendations if any of the following scenarios
occur:

• Authentication attempt fails with no log entry: In this case, check that your RADIUS client is correctly
configured to send authentication to FortiAuthenticator. Also verify traffic is reaching FortiAuthenticator and
is not prevented by a firewall policy.
• Authentication attempt fails with “Invalid Password”: In this case, reset the user password and try again. If
it still fails, verify the network access server shared secret.
• Authentication attempt fails with two-factor authentication enabled: In this case, verify the user is not trying
to use a previously used token passcode (for example, a one-time password token). Also verify the time
and time zone on FortiAuthenticator is correct and preferably synchronized using NTP. Finally, verify the
token is correctly synched with FortiAuthenticator (that is, it hasn’t drifted).

You may also want to check the extended logs as well at http://<FortiAuthenticator_IP>/debug.

FortiAuthenticator 6.4 Study Guide 142

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

The third step is to reduce the complexity of the RADIUS configuration. Usually this is not required, because
the logs provide enough information for troubleshooting purposes. However, just in case try, the following:

• Remove two-factor authentication from the equation by disabling the token in the user account
• Remove any group filters

After the complexity is reduced, test authentication using a simple client tool, such as NTRADPing, from a
laptop. Don’t forget to add the laptop as an allowed RADIUS client in the FortiAuthenticator configuration!

FortiAuthenticator 6.4 Study Guide 143

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

The following slides show some common issues for RADIUS login failures. In the scenario shown on this
slide, the user exists on the system, but RADIUS authentication fails. Logs say Authentication failed,
user not found.

To debug, verify the user has RADIUS authentication enabled and that the account is not disabled.

FortiAuthenticator 6.4 Study Guide 144

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

In the scenario shown on this slide, the user exists on the system, but RADIUS authentication fails. Logs show
no success or failure.

To debug, verify that a RADIUS client entry exists for the authenticating system and that the traffic is really
sourced from the IP of the network access server and is not being NATed. Also check the RADIUS log for
errors and sniff the traffic.

FortiAuthenticator 6.4 Study Guide 145

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 146

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 147

 Managing Users and Troubleshooting Authenticatoin

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to administer user account policies and
management settings, and how to authenticate users through LDAP and RADIUS as well as the self-service
portal.

FortiAuthenticator 6.4 Study Guide 148

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about two-factor authentication and FortiTokens. Specifically, you will learn how to
provision, create, and administer FortiTokens for use as your step-up authentication solution.

FortiAuthenticator 6.4 Study Guide 149

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 150

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating knowledge of password tokens and validation servers, you will be able to use them in your
network.

FortiAuthenticator 6.4 Study Guide 151

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Typically, an OTP token is not used as a standalone solution, but as an additional authentication mechanism on
top of a user name and static password—the something you have in two-factor authentication.

OTP tokens generate passwords that can be used only once. They are more secure than static passwords
because they are not vulnerable to replay attacks. For example, even if an attacker obtains an OTP, the
password invalidates after a short interval (usually 60 seconds).

Because memorizing OTP passwords is practically impossible, you need something that can generate OTPs for
you. There are three main ways of acquiring one-time passwords:
• Hardware tokens, which are physical devices, such as the FortiToken 200 series
• Software tokens, which are software applications on a smart phone, such as FortiToken Mobile
• FortiToken Cloud uses cloud-based token validation using FortiToken Mobile
• Tokenless (email or SMS)

FortiAuthenticator 6.4 Study Guide 152

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

There are two main standards, governed by OATH, to generate one-time password tokens: time-based and
event-based.

TOTPs generate passcodes using a combination of time (time passed since an epoch) and a secret key. The
passcode changes at regular intervals and, because they are OTPs, are single use only. FortiAuthenticator
validates the entered passcode using time and the secret key. Fortinet products that use TOTP include
FortiToken 200 (hardware token) and FortiToken Mobile (software token). With time-based tokens, it is important
to have FortiAuthenticator’s system clock accurately adjusted. Therefore, it is highly recommended that you use
an NTP server for system time synchronization.

HOTPs generate passcodes using a combination of a counter (an input to a cryptographic hash function) and a
secret key. Whenever a new passcode is generated, the counter value is incremented, and therefore the
passcodes are different each time. They remain valid until used. Because they are OTPs, the passcodes are
single use only.

TOTP is considered more secure because the passcode keeps changing and is only valid for a short period of
time. HOTP passcodes can be valid for an unknown amount of time (they remain valid until used).

FortiAuthenticator 6.4 Study Guide 153

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

This slide shows the details of how tokens are used within a two-factor authentication environment.

1. The token generates a passcode. The passcode is based on a seed, which is a randomly-generated number
that does not change in time, and a time, obtained from an internal, accurate clock. The seed and time go through
an algorithm that generates a passcode. A single passcode is valid for only a short interval (usually 60 seconds)
and then a new one generates. The cycle of generating passwords repeats over and over again.

2. The user authenticates through a username and static password (first factor), and then the one-time passcode
provided by the token (second factor).

3. A validation server receives the username and static password and validates those credentials.

4. The validation server then validates the OTP. The validation server knows the seed used by the token and its
system time is synchronized with the time in the token. By using the same algorithm, the validation server can
generate the code again and compare it with the one received from the user. If the static password is valid and
the one-time passwords match, the user is successfully authenticated. Again, both the token and the validation
server must have the same seed. Also, both system clocks must be synchronized (this is why an NTP server is
highly recommended).

FortiAuthenticator 6.4 Study Guide 154

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

RADIUS authentication is a method used by a RADIUS client delegating authentication (and sometimes
authorization) to a third-party user database; that is, the RADIUS server. In RADIUS authentication there are
usually three parties: the user, the RADIUS client or NAS (which is usually a FortiGate or another network access
device), and the RADIUS server. When the user authenticates, the RADIUS client requests the users credentials
and passes them to the RADIUS server for validation.

In most cases, the RADIUS client will support a RADIUS challenge-response. The RADIUS challenge-response
method is the preferred mechanism for two-factor authentication, because it is most natural for the end user.

If the RADIUS client supports the use of the RADIUS challenge packet, the remote user authenticates by entering
the username and password first, which is then forwarded by the RADIUS client to the RADIUS server. The
credentials are validated and, if correct and two-factor authentication is required, the RADIUS server replies with
an access challenge message indicating to the RADIUS client that it must ask the user for the token passcode.
The user now sends the one-time passcode, which is also forwarded to the RADIUS server for validation. The
RADIUS server also calculates the one-time passcode, compares it with what is provided, and replies with
“access accept” or “access reject”.

OTP passcode appended method can be used when the RADIUS client does not support the RADIUS challenge
packets, which is sometimes the case in old or legacy systems, the user must type and send the static password
and the token code all together. The user must know to append their OTP passcode to the end of their password.
The RADIUS client forwards those credentials to the RADIUS server, which replies with an answer indicating if
the password and the token code are valid or not.

FortiAuthenticator 6.4 Study Guide 155

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator supports FortiToken OTP push notifications, or FTMv4 push notifications.

PUSH notifications are used to send alerts to the end user’s device each time a login request is made.

The alert contains information about the login attempt, for example the location from which the attempt originated.

Using FTMv4, when required to authenticate themselves, FortiToken Mobile users don't have to look up a code in
FortiToken and enter the code into their browser.

Instead, FortiToken Mobile is queried and the user simply taps to approve or deny the request.

If approved, a new OTP is automatically generated and sent by FortiToken Mobile to transparently authenticate
the end-user in the background.

If denied, FortiToken Mobile automatically sends an alert to the system administrator.

FortiAuthenticator 6.4 Study Guide 156

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

To some extent, FortiGate (without FortiAuthenticator) does support two-factor authentication. So, what are the
benefits of using FortiAuthenticator for two-factor authentication?

FortiGate has a built-in validation server and can also integrate with an existing AD/LDAP infrastructure.
However, and by design, the scope of two-factor authentication without FortiAuthenticator is specific and limited
to one instance of FortiGate (or HA pairs). So, it works well only in cases where tokens are stored on only one
FortiGate device.

FortiAuthenticator can support multiple FortiGate devices or other third-party vendor devices. With
FortiAuthenticator, one FortiToken can be used to authenticate to multiple systems.

Other advantages are that FortiAuthenticator has a built-in LDAP server and an API for integrating authentication
services within a corporate Web site or application. It also supports wireless authentication through social
channels, extends guest management capabilities, and delivers certificate management.

FortiToken Cloud provides a high availability managed service for two factor authentication that allows
administrators to easily deploy and manage their token inventory. Support for FortiToken Mobile Push simplifies
end user interaction during two factor authentication. FortiToken Cloud also adds the benefit of two factor
authentication across multiple FortiGates with a single token.

FortiAuthenticator 6.4 Study Guide 157

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 158

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand OTP tokens.

Now, you will learn about the different OTP products.

FortiAuthenticator 6.4 Study Guide 159

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in explaining hardware and software tokens, you will be able to use them
knowledgeably in your network.

Fortinet has a USB smart card token that can be used for two-factor authentication as well. However, since the
USB smart card token uses an x.509 certificate for authentication (rather than an OTP), it is described in the
Certificate Management lesson.

FortiAuthenticator 6.4 Study Guide 160

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

This slide shows the FortiToken hardware device options: FortiToken 200B and FortiToken 220. They each
generate tokens that expire after 60 seconds. After the current interval expires, the devices transition to sleep
mode to save battery life.

The benefits of the FortiToken 200B and 220, compared to third-party devices, is that the tokens are perpetual
and will function for as long as the battery remains functional (unlike RSA tokens, for example, which expire after
a fixed period).

FortiAuthenticator 6.4 Study Guide 161

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

The FortiToken 200B is a small keychain-sized hardware token that provides easy-to-use single-button token
generation. The token is displayed on a large easy-to-read LCD screen, with an indicator that shows the time
remaining before the next token is generated.

The FortiToken 220 is a mini credit card format FortiToken, that like the FortiToken 200B, provides easy-to-use
single-button token generation. The token is displayed on a easy-to-read LCD screen, with an indicator that
shows the time remaining before the next token is generated.

FortiAuthenticator 6.4 Study Guide 162

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

FortiToken Mobile is installed on any Android or iOS mobile device as an app. It is a PIN-protected application
that displays the 6-digit or 8-digit code on the user’s mobile phone in 30-second or 60-second timesteps (the
default is 60 seconds). The application stores the seed encrypted, and it can be configured to erase the seed
when the number of failed PIN attempts exceeds a threshold.

FortiAuthenticator 6.4 Study Guide 163

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 164

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand the different OTP products.

Now, you will learn about how to provision OTP tokens.

FortiAuthenticator 6.4 Study Guide 165

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in provisioning both hardware and software tokens, and configuring users for two-
factor authentication, you will be able to use both in your network.

FortiAuthenticator 6.4 Study Guide 166

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

These are the steps that an administrator must follow to provision any new token:

1. Obtain token data which consists of the serial number and seed.
2. Register or add the tokens on the validation server.
3. Assign tokens to users.
4. Configure users for two-factor authentication.

Remember, the validation server can be either FortiGate or FortiAuthenticator, depending on your requirements.

You will learn about these steps in detail in this lesson, using FortiAuthenticator as the validation server.

FortiAuthenticator 6.4 Study Guide 167

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Because the first step involves obtaining the token data, which includes the seeds, let’s quickly examine token
seeds. A seed is a factory-encoded random key, which, along with the built-in clock, generates the authentication
code.

The seed for the FortiToken 200 is generated randomly and is 160 bits long. After the seed is generated, it is
encrypted using 2048-bit RSA and stored in a secure database. The system automatically injects the seeds into
the tokens, so the seed number is never exposed to human operators. Upon request from a customer, the seed
can be destroyed.

FortiToken Mobile includes seeds as well. FortiToken Mobile seeds are generated on demand when the token is
provisioned to the user on the FortiGate or FortiAuthenticator. When a provisioning request is received, a random
data source is used to generate the seed and store it, encrypted, until it is securely retrieved by FortiAuthenticator
and the user’s FortiToken Mobile application. After it is retrieved, the seed is irretrievably destroyed on
FortiGuard. If the seed is not downloaded within the designated time frame (up to 30 days), it is automatically
destroyed.

When you use FortiAuthenticator, FortiAuthenticator generates the seed and then pushes it to the cloud.

FortiAuthenticator 6.4 Study Guide 168

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Once the token is seeded, the token data (serial number and seed) must be delivered to the validation server
administrator.

You can receive the token data in the following two ways. The second method is the more secure of the two.

• Activate encrypted seeds online through the FortiGuard network. To reduce the impact of entering all token
seeds, all tokens associated with a purchase order can be imported in bulk by entering a single token serial
number. Alternatively, you can scan the barcode on the back of each token using a barcode scanner.

• Generate and provision the seeds in-house using a token provisioning tool. This in-house method is intended
for high-security organizations that want to have full control of the seeds as soon as they are generated. With
this method, Fortinet ships blank tokens with no seeds. You must inject the seeds within your secure
premises, which requires a seed-injection system and a hardware token seed-burning system. This can be a
time-consuming process, but it is highly customizable and secure.

FortiAuthenticator 6.4 Study Guide 169

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

You must register any new token—either the FortiToken hardware or FortiToken Mobile—with FortiAuthenticator.
You can do this through the FortiToken page.

There are two ways you can add tokens to FortiAuthenticator: manually create them or import them.

To manually create tokens, click Create New. If you are registering a FortiToken hardware, you need to enter the
serial number. If you are registering FortiToken Mobile, you need to enter the activation code. If you have multiple
tokens, you must add them one at a time, or you can add all tokens from the same purchase order by enabling
Add all FortiTokens from the same Purchase Order.

To import tokens, click Import. You can import by serial number file (CSV), seed file (CSV), or FortiGate
configuration file.

The Serial number file is a CSV file that contains the token serial numbers. FortiToken devices have a serial
number barcode on them that is used to create the import file.

The Seed File is a CSV file that contains the token serial numbers, encrypted seeds, and IV values.

The FortiGate configuration file provides you the ability to import FortiToken Hardware only, FortiToken
Hardware and only their associated users, or Import all FortiToken Hardware and users. The selected
option will be extracted from the uploaded FortiGate configuration file.

Each time you register new FortiTokens, the connectivity between FortiAuthenticator and FortiGuard must be up,
because FortiAuthenticator needs to validate each FortiToken against the FortiGuard servers. FortiAuthenticator
requires full Internet connectivity (through port 443) and proper DNS resolution. After the FortiTokens are
registered, the connection to FortiGuard is no longer essential.

FortiAuthenticator 6.4 Study Guide 170

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

You can assign a token to a local user or remote user on the User Management page. Enable Token-based
authentication and select FortiToken. From here, you can select Hardware, Mobile, or Cloud. For hardware or
mobile you select the token from a drop-down list, remember, the token must first be registered with
FortiAuthenticator.

For local users only, you can choose to send a temporary passcode for a FortiToken Hardware or FortiToken
Mobile over email, SMS, or both. This allows you to assign a temporary authentication method, should a user
temporarily misplace their token or leave it at home without the need to de-provision the old token method.

FortiAuthenticator 6.4 Study Guide 171

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Once you assign a FortiToken hardware to a user, that FortiToken is ready to use. It should be delivered to the
user safely and your company should have a vetting process in place to ensure the correct person is receiving
the assigned token. An organization’s policy for hardware token delivery is outside the scope of this training.

Once the user physically has the token and attempts to access a protected resource on the network, the user is
prompted to enter their token code. The user must press the button on the FortiToken hardware to display the
code.

FortiAuthenticator 6.4 Study Guide 172

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

If you assign a FortiToken Mobile (soft-token) to a user, the process of user activation is as follows:

1. The administrator assigns a soft token to a user.

2. FortiAuthenticator sends a provisioning request to FortiGuard, shown on the slide as 2a, then
FortiAuthenticator sends an email or SMS to the user notifying them of the token delivery, shown on the slide
as 2b. This message also contains the activation code.
3. The user enters the activation code and the FortiToken Mobile app contacts FortiGuard to activate the soft
token.

FortiAuthenticator 6.4 Study Guide 173

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Before provisioning the first FortiToken Mobile app, go to the FortiGuard page and select the required activation
timeout, token size, PIN length, and algorithm. The default Token algorithm is TOTP (Time-based One-time
Password) with default time step of 60 seconds. The time step defines the time between token generation. The
Hash-based One-time Password (HOTP) algorithm option will generate a single use token.

FortiAuthenticator 6.4 Study Guide 174

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

You can also customize the FortiToken Mobile app with your organization’s logo. First, you must configure your
organization’s logo on the Logos page. Then, you can assign it to the user. Edit the user entry on the User
Management page (either local or remote user), and, in the User Information section, select the logo in the
FortiToken Logo drop-down list. The logo will then appear on the FortiToken Mobile app.

FortiAuthenticator 6.4 Study Guide 175

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

As mentioned, once you assign a FortiToken Mobile to a user, the user receives an SMS or email with
instructions. Note that the user account must include a valid mobile phone number or email address.

This slide shows an example of the email that is sent. The email includes a link to the FortiToken Mobile User
Guide for either iOS or Android, the activation code, and a QR code containing the activation code for easier
activation. The email also includes a time by which the user must activate the token. If not activated before expiry,
the user must contact the administrator to receive a new activation code. In this lesson, you will learn how to
modify the passcode validity time.

The user must open the FortiToken Mobile application on their iOS or Android mobile device and enter the
activation code. The application will then contact FortiGuard to validate the activation code.

FortiAuthenticator 6.4 Study Guide 176

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

FortiToken Cloud provides Authentication as a Service (AaaS), centralizing management, provisioning, and token
authentication in the cloud. This provides you an additional option, beyond local, for two-factor authentication as
well as cloud-based SSO. It provides FTM push without the need to open firewall ports, and cross-platform token
transfer. FortiToken Cloud works with FortiAuthenticator and does not interfere with the initial user name and
password login process. No additional hardware or software is required. The cloud-based service offers high
availability.

FortiAuthenticator 6.4 Study Guide 177

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

If you assign a FortiToken Cloud to a user, the process of user activation is as follows:

1. The administrator assigns a soft token to a user.

2. FortiAuthenticator sends a provisioning request to FortiToken Cloud
3. FortiToken Cloud sends an email or SMS to the user notifying them of the token delivery. This message also
contains the activation code.
4. The user enters the activation code and the FortiToken Mobile app contacts FortiToken Cloud to activate the
soft token.

FortiAuthenticator 6.4 Study Guide 178

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

In addition to the hardware and software tokens, FortiAuthenticator can deliver a one-time password (or token
code) by either email, SMS or both. If email is used as a delivery method, you need to ensure you have
configured the user account to include a valid email address. If SMS is used as a delivery method, you need to
ensure you have configured the user account to include a valid mobile phone number. This slide shows an
example of the delivery of a token code by email.

FortiAuthenticator 6.4 Study Guide 179

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Just because a user is assigned a FortiToken and they have registered or activated it, does not mean they must
use it as their step-up authentication method. You must enable two-factor authentication on FortiAuthenticator
first. You can do this on the User Management page by enabling both Password-based authentication (this
will be used as the first factor) and One-Time Password (OTP) authentication (this will be used as the second-
factor).

FortiAuthenticator 6.4 Study Guide 180

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

You can configure two-factor authentication for RADIUS authentication requests from a RADIUS client. There are
four authentication methods available. They are:

Mandatory password and OTP: If the user does not have a token, they cannot be authenticated for this client.
This is the most common method used to enforce secure authentication.

All configured password and OTP factors: If the user has a provisioned token, it must be used. If the user
does not have a token, they can still log in. This authentication method is used in a mixed environment where
only certain high-risk users need to authenticate with two-factor authentication. You can also use it in combination
with RADIUS attributes, where RADIUS attributes are used to elevate user permissions and only those users
require secure authentication.

Password-only: Removes the need for use of the token passcode even if it is provisioned. This method is used
in low-risk situations where added security is not required for the specific client. This method is not recommended
and should be used use with caution.

OTP-only: This authentication method validates only the token passcode. Entering the password will fail and a
challenge will not be made. This method is used where the first factor (username and password) is validated
externally, for example, for integration with a banking web application where username and password are
validated against a separate SQL or other type of database.

FortiAuthenticator 6.4 Study Guide 181

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 182

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand how to provision OTP tokens.

Now, you will learn how to manage the FortiTokens.

FortiAuthenticator 6.4 Study Guide 183

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in token-related tasks, such as configuration, synchronization, and monitoring, you
will be able to effectively manage FortiTokens.

FortiAuthenticator 6.4 Study Guide 184

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

On the Tokens page, you can configure various token settings for both time-based and event-based tokens. For
example, you can:
• Set a time window (or counter window for event-based tokens) so that a FortiToken code will be marked as
valid inside the window. For example, if the field is set to 1 minute, the token code that is issued in the last,
current, or next minute is considered valid.
• Set a sync window (or counter window for event-based tokens) so that, if a FortiToken code is invalid but is
still inside this window, it will be marked out of synchronization.
• Set the length of time after which a token passcode sent by email or SMS will be marked as expired.
• Offline support allows Windows agents to cache future-dated tokens for when the end station is offline.
• Emergency codes help users without access to FortiToken, SMS, or email to complete 2FA. They can be
supplied to the user by an administrator.

You can reduce security by changing these settings. For example, by changing the time-based valid window from
1 minute to 100 minutes, you would increase the chance of being able to guess a token from 1/1,000,000 to
100/1,000,000 or 1/1,000. Use caution when changing this setting.

FortiAuthenticator 6.4 Study Guide 185

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

The system clock in the token must be synchronized with the system clock in FortiAuthenticator. Perfect
synchronization is always impossible to achieve. There is always a difference, called a drift, between the two
clocks. The drift usually increases with time, causing both device clocks to become out of sync.

A time step (which is equivalent to the frequency that a new code is generated) is 60 seconds. FortiAuthenticator
will accept the valid code for the current time step, the one before, and the one after. So, any drift that is not
bigger than +/-1 time step is tolerated. If the drift is larger, a re-synchronization is required. This ensures that the
device provides the token code that FortiAuthenticator expects, because the codes are time-based. Fortinet
recommends synchronizing all new FortiTokens.

You can re-synchronize a FortiToken on the FortiToken page. Locate the FortiToken you want to synchronize
and click Synchronize. You must enter the code currently displayed on the FortiToken, wait for a new time step,
and then type the next code displayed. In this way, FortiAuthenticator can calculate the drift and adjust
accordingly.

FortiAuthenticator 6.4 Study Guide 186

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Remote user synchronization rules allow you to configure token-based authentication sync priorities, how and
when remote LDAP users are synchronized, and the role assigned to the imported users. The prevents the
administrator from having to assign tokens to users one at a time.

You can enable the Token-based authentication sync priorities setting, and then prioritize the entries by
dragging them up or down in the list.

You can assign the new user imports FortiAuthenticator the role of Administrator, Sponsor, or User.

Enable Email password recovery to provide an email password recovery option to new and existing remote
LDAP users, if they have a valid email address.

You can delete synchronized users when they are no longer found on the remote server. This option is available
only when the Proceed with rule even when response is empty option is not enabled.

Enabling the Proceed with rule even when response is empty will result in the deletion of all users in a
FortiAuthenticator group when the synchronization returns no results.

FortiAuthenticator 6.4 Study Guide 187

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

The User Inventory widget on the FortiAuthenticator dashboard indicates the total number of registered
FortiToken devices and the total number of disabled FortiTokens.

From the FortiTokens page, you can:

• Unlock locked tokens in bulk

• View the status of each FortiToken
• View the last time a token was used
• View the user to which each FortiToken is assigned
• View the time drift of each FortiToken

FortiAuthenticator 6.4 Study Guide 188

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

You can export FortiTokens to a CSV file on the FortiTokens page by clicking Export FTK Hardware.

Tokens are removed from FortiGuard once provisioned, so it is not possible to reprovision them onto another
system without opening a support ticket. By providing an export option, you can reprovision tokens without
needing additional support. Furthermore, it is currently not possible to import configuration backups from different
appliance models. So the ability to export tokens (and users) allows for easy migration between systems.

FortiAuthenticator 6.4 Study Guide 189

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Changing devices requires the user to install new tokens on their new device because the unique device ID is
used to form the seed decryption key.

If you wipe data from your device, or upgrade your device, you must reprovision your accounts.

If it is not enabled, FortiAuthenticator blocks all requests to transfer activation codes.

FortiAuthenticator 6.4 Study Guide 190

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

The process for transferring a token to a new device is as follows:

1. The end user selects the FortiToken Mobile menu option: Initiate Token Transfer.
2. FortiToken Mobile requests a new token transfer request service from FortiGuard, and includes the token
data.
3. FortiGuard stores the token data and creates a Transfer Activation Code.
4. FortiGuard signals back to FortiToken Mobile on the old device that transfer initialization is complete.
5. The user is prompted for approval, and when approved, the tokens are deleted from the old device.
6. On the old device, FortiToken Mobile sends a request to FortiAuthenticator for the Transfer Activation
Code.
7. FortiAuthenticator retrieves the Transfer Activation Code from FortiGuard and signals back to
FortiToken Mobile (on the old device) that the Transfer Activation Code request was successful.
8. FortiAuthenticator sends either an email or SMS to the end user with the transfer code (as a QR code from
email).
9. On the new device, the end user selects the FortiToken Mobile menu option Complete Token Transfer and
enters the transfer code (or scans the QR code).
10. FortiToken Mobile receives the token data from FortiGuard and installs the token(s) on the new device. All
tokens are removed on the old device after the transfer is complete.
When transitioning from one iOS device to another iOS device, the process of transferring tokens may not be
necessary if the device was backed up to iCloud.

FortiAuthenticator 6.4 Study Guide 191

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

If a user reports a FortiToken lost or stolen, you can lock the FortiToken. Select the FortiToken on the
FortiTokens page and click Lock. You must provide a reason for locking the FortiToken. A temporary SMS or
email token can be provided to the user for logging in until new arrangements have been made. The device can
be unlocked if it is recovered.

FortiAuthenticator 6.4 Study Guide 192

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 193

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 194

 Two-Factor Authentication

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to apply and manage two-factor
authentication using tokens.

FortiAuthenticator 6.4 Study Guide 195

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to use FortiAuthenticator as a login event collector that uses the Fortinet Single
Sign-On (FSSO) communication framework to transparently authenticate users.

FortiAuthenticator 6.4 Study Guide 196

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 197

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding FSSO, you will be able to identify the different methods of
collecting login events from AD as well as understand the FSSO framework.

FortiAuthenticator 6.4 Study Guide 198

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

FSSO offers a solution for transparently identifying (and implicitly trusting) users who have already authenticated
to the network through a different system.

FSSO differs from the generic single sign-on (SSO) in that FSSO is a single sign-on into the FortiGate firewall
policy only, as opposed to a single sign-on into any web or similar application.

FSSO is commonly used to transparently authenticate Microsoft AD users, but with FortiAuthenticator, it is not
limited to that environment. FSSO can also transparently authenticate users in non-Microsoft environments by
leveraging the Fortinet mobility agent, syslog SSO, and SAML SSO.

FortiAuthenticator 6.4 Study Guide 199

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

The FSSO process is as follows:

1. The user authenticates only once, against an authentication server that is usually a Windows Domain
Controller (DC).
2. The user login information is forwarded and distributed to all the firewalls and authentication devices in the
network. Login information usually contains the user name, IP address, and user groups. This way, firewalls
know which user is at which IP address.
3. The firewall uses the source IP address of the packets, and the login information received from the
authentication server, to identify the user and apply the proper firewall policy depending on the user group.
The firewall will not ask the user to authenticate again.

This process is also similar if a user is accessing an internal network resource. The firewall uses the source IP
address to identify the user and determine if they can have access to a specific network service.

FortiAuthenticator 6.4 Study Guide 200

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

This slide shows the multitude of ways FortiAuthenticator can identify users over the FSSO framework.

The FortiAuthenticator FSSO framework has five layers:

• The first layer is the identity source: the method by which the user identity is ascertained.
• The second layer is the identity discovery: the methods by which the user identity and their location (IP) are
discovered. You will learn each of these methods in the FSSO User Identity Discovery Methods section.
• The third layer is aggregation and embellishment: the collection of user identity and addition of any missing
information, such as group, which is gathered from the external LDAP/AD.
• The fourth layer is the communication framework: the method by which the authentication information is
communicated with the subscribing device.
• The fifth layer is the subscribing device: for example, FortiGate. The user information is forwarded to the
subscribing device where the information can be used in firewall policies.

Note that you can also combine multiple methods. For example, Single Sign-On Mobility Agent may be used for
Microsoft Windows domain PCs but fall back to the login portal with embedded widgets for non-Windows systems
or unauthenticated PCs.

FortiAuthenticator 6.4 Study Guide 201

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In the case of Microsoft AD users, there are two ways of collecting login events:

• Domain controller (DC) agent mode

• Windows AD polling mode

Now, you will take a closer look at both of these methods.

FortiAuthenticator 6.4 Study Guide 202

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

The DC agent mode requires a DC agent to be installed on each of the Windows domain controllers. It also
requires FortiAuthenticator or a Windows domain server with a software collector agent installed to act as a
collector agent. This is how this mode works:

1. When the user logs into the Windows network, a login event is recorded in one of the domain controllers.
2. The DC agent installed in that DC detects the login event and forwards it to the collector agent. In that way,
the collector agent collects the login events from multiple DCs.
3. The FortiAuthenticator or Windows domain server, configured as a collector agent, gathers the login events,
looks up the missing information such as group membership, and then forwards the appropriate collected
login events to FortiGate. The information forwarded contains the user name, user groups, and user IP
address.

When traffic is coming from that user IP address, FortiGate knows in advance which user is there, and applies
the correct firewall policies depending on the user, the user groups, and the traffic destination.

FortiAuthenticator 6.4 Study Guide 203

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

It’s worth mentioning WMI polling, because it relies on DC agent mode. FortiAuthenticator supports WMI polling
to detect workstation logout. This validates the currently logged in user for an IP address that has been
discovered by the DC polling detection method.

Note that remote WMI access requires that the related ports are opened in the Windows firewall, and access to a
domain account that has sufficient permissions, such as domain admins.

FortiAuthenticator 6.4 Study Guide 204

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

Unlike DC agent mode, Windows AD polling mode does not require DC agents and therefore is an alternative for
customers with third-party installation limitations. However, it is not as scalable as the DC mode, and requires
more CPU and memory. Polling can be done directly from FortiGate, so a FortiAuthenticator or other collector
agent is not always needed.

It works as follows:

1. The user logs on to the network, which generates a login event.

2. The collector agent is periodically polling the DCs to extract the login events.
3. The collector agent gathers the login events, looks up the missing information such as group memberships,
and then forwards the appropriate collected login events to FortiGate. The information forwarded contains the
user name, user groups, and user IP address.

When traffic is coming from that user IP address, FortiGate knows in advance which user is there, and applies
the right firewall policies and profiles.

FortiAuthenticator 6.4 Study Guide 205

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

So, if you can have single sign-on without FortiAuthenticator, why configure it?

FortiAuthenticator offers two main advantages:

1. Both DC agent mode and polling mode work only in Windows AD environments. You can use
FortiAuthenticator to implement FSSO in both Microsoft and non-Microsoft environments. It can collect login
events from many different sources, which you will learn about later.
2. It offers a Windows AD polling mode that does not require the use of a domain agent and it is more scalable
than polling directly from FortiGate.

FortiAuthenticator 6.4 Study Guide 206

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

FortiAuthenticator therefore takes the FSSO framework introduced in FortiGate and enhances it with several
authentication methods:
• Users can authenticate through a web portal and a set of embeddable widgets
• Users with FortiClient Endpoint Security installed can be automatically authenticated through the FortiClient
SSO Mobility Agent
• SAML authentication can be used to trigger an FSSO authentication
• Users can be identified through the FortiAuthenticator API which is useful for integration with third-party
systems

FortiAuthenticator 6.4 Study Guide 207

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 208

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

Good job! You now have a brief understanding of FSSO.

Now, you will learn about the different FSSO user identity discovery methods and how to configure them.

FortiAuthenticator 6.4 Study Guide 209

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding and configuring FSSO discovery methods, you will be able to
implement the different FSSO methods in your network.

FortiAuthenticator 6.4 Study Guide 210

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

FortiAuthenticator has taken the concept of FSSO, as used on FortiGate and the FSSO software client, and
extended it with several new user identification methods. Because of flexibility built in to FortiAuthenticator, this
list is continually growing. This section examines current FSSO user identity discovery methods, including the
following:
• Active Directory polling
• Kerberos-based FSSO
• FortiClient SSO Mobility Agent
• RADIUS accounting
• External syslog
• Rest API
• DC and TS collector agents
• RADIUS accounting proxy
• FortiNAC

You can enable one or more discovery methods on FortiAuthenticator on the General page in the Fortinet
Single Sign-On (FSSO) section.

Some methods require further configuration other than enabling the method shown on this slide. You will explore
the configurations in this section.

FortiAuthenticator 6.4 Study Guide 211

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

FortiAuthenticator is able to poll Windows domain controllers to monitor the security event logs for login events.
Polling of the Security Event Log is configured to occur every 5 seconds so that any login event that has occurred
since the previous poll is captured and entered into FSSO.

Note that while login events can be detected from the security event logs, logout events cannot. This is due to the
fact that logout events can be triggered by many different processes, many that are not indicative of the user
logging out.

While some methods natively support logout detection (like the FortiClient SSO Mobility Agent), others such as
AD polling do not. To enable logout detection, FortiAuthenticator supports Windows Management Instrumentation
(WMI) polling to identify the current logged on user state for a device and log the user out. A manual timeout
period can also be set to remove the user from the authorization table.

FortiAuthenticator 6.4 Study Guide 212

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In order to use domain controller polling, you must enable Windows Active Directory (AD) domain controller
polling.

After you enable it, you must create a domain controller. This allows FortiAuthenticator to poll the AD event log to
track user logins as well as poll the WMI logs to track the user logouts. You can configure domain controllers on
the Windows Event Log Source page. You must enter the NETBIOS name of the controller, the domain
controller IP address, and the account credentials that can poll the event and WMI logs. Administrator privileges
are not essential, you only need an account that can bind with the domain controller.

For this method, FortiAuthenticator and FortiGate must be prepared.

Security event selection is accessible from the Configure Events link.

FortiAuthenticator 6.4 Study Guide 213

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

To avoid the need to poll the domain controller while still retaining the ability to transparently authenticate
Windows users, FortiAuthenticator supports use of Kerberos tickets passed by the browser and validated against
the key distribution center (KDC) to identify users. In this case, unauthenticated users are redirected from
FortiGate to FortiAuthenticator. FortiAuthenticator requests the service ticket from the browser and then decrypts
and uses the ticket to validate the user identity.

FortiAuthenticator 6.4 Study Guide 214

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

The FortiClient SSO Mobility Agent is part of the standard FortiClient product installation. When installed, the
SSO Mobility Agent identifies Windows Domain users transparently and communicates the user identity and IP
address to FortiAuthenticator for use in FSSO. The agent also monitors the system for IP address changes, such
as those caused by Wi-Fi roaming, and automatically updates FortiAuthenticator. When the user logs out or shuts
down, the user is also logged out of FortiAuthenticator. In cases where an unclean disconnection is made (for
example, power failure, hibernation, network failure), a heartbeat system is implemented so the user will be de-
authenticated following a configurable number of heartbeat failures.

FortiAuthenticator 6.4 Study Guide 215

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In order to use the SSO Mobility Agent, the service must be enabled. This involves setting the FortiClient listening
port number (by default, it is 8001) and enabling authentication in the communication between FortiAuthenticator
and the FortiClient devices. This requires you to enter the secret key. You can also configure the duration
between keepalive transmissions from 1 to 60 minutes, and the idle time-out period.

The Enable NTLM option helps to prevent attacks based on a user authenticating to an unauthorized AD server
in order to spoof a legitimate user login through the FortiClient SSO Mobility Agent. FortiAuthenticator will initiate
NTLM authentication with the client, proxying the communications only to the legitimate AD servers it is
configured to use. If NTLM is enabled, FortiAuthenticator requires NTLM authentication when:
• The user logs in to a workstation for the first time
• The user logs out and then logs in again
• The workstation IP address changes
• The workstation user changes
• NTLM authentication expires (user configurable)

FortiClient must be configured on the end station by supplying the FortiAuthenticator IP address, communication
port, and secret key.

FortiAuthenticator 6.4 Study Guide 216

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In situations where device or user identity cannot be established transparently, such as non-domain BYOD
devices or shared kiosk machines, a web portal can be used to prompt users for login. Often this method is used
with other transparent methods and used as a catch-all. Once authenticated, the user remains authenticated until
they log out of the browser.

Because repeated manual reauthentication may impact the user experience, FortiAuthenticator supports
automated user identification for subsequent access through the use of portal widgets. The widget
implementation, which uses an HTML iframe, can be incorporated into a web page, such as an intranet webpage
for users to use for login. Following a successful login, a time-limited cookie, the validity of which is configurable
for up to 30 days, is stored in the user’s browser. On subsequent visits, the user will be transparently
reauthenticated using the user’s cookie key (assuming it matches that stored on FortiAuthenticator). When the
cookie times out, or should the user clear the cache or visit a new machine, the user will be required to
reauthenticate.

FortiAuthenticator 6.4 Study Guide 217

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In order to use portal services--which support multiple authentication methods, including manual authentication,
embeddable widgets, and Kerberos authentication--you have to configure portal services on the Portal Services
page.

If you want to use manual portal authentication or widgets, enable Enable SSO on login portal. You must
specify if you want to authenticate local users, or remote users, or both (in a remote LDAP server) in the self-
service portal policy. You can also specify if all users can authenticate, or only users that belong to specific
groups.

If you want to use Kerberos authentication so FortiAuthenticator can identify connecting users through a Kerberos
exchange after a redirect from FortiGate, you must first generate a keytab file that describes your Kerberos
infrastructure, and import it. You can use a ktpass utility to generate the file. The code provided in the
FortiAuthenticator Administration Guide can be used in a batch file to simplify the keytab file creation.

The SAML portal enables support for Security Assertion Markup Language (SAML), allowing users to provide one
set of credentials to gain access to many different websites. SAML will be covered, in detail, in another lesson.

The SSO web service refers to SSO using the API. This configuration is needed to allow the API to accept SSO
logins, and to tell the API which type of users will be authenticating.

FortiAuthenticator 6.4 Study Guide 218

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

The RADIUS accounting method uses RADIUS start, interim, and stop accounting packets to trigger login/logout
to FSSO. Such RADIUS packets are commonly sent by networking devices such as SSL-VPN devices, wireless
controllers, and switches.

The benefit of this method is that, for vendors who support sending such packets, no direct support is required by
FortiAuthenticator (they use standard RADIUS which is already supported) and minimal change is required to
enable the input of the user authentication data into the FSSO.

FortiAuthenticator 6.4 Study Guide 219

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

To accept and process the start, interim, and stop packets you must enable the Enable RADIUS accounting
SSO clients option.

Once enabled, you have to configure RADIUS accounting on the RADIUS Accounting Sources page. Here, you
will configure FortiAuthenticator as a RADIUS accounting server to the RADIUS accounting source. The source
could be a RADIUS server, a switch, a Fortigate device, or any other device that can generate RADIUS
accounting packets.

To configure a RADIUS accounting SSO client, you must select a name for the RADIUS accounting client, enter
the IP address of the RADIUS accounting client, and enter the RADIUS client’s preshared key. You must also
select the type of SSO user the client will provide (external, local, remote). If required, you can also customize the
user name, client IP address, and user group RADIUS attributes to match the ones used in the incoming RADIUS
accounting records.

FortiAuthenticator 6.4 Study Guide 220

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

The configuration of FortiAuthenticator to accept and process syslog messages from external sources includes
identifying the sources, defining the syslog rules, and associating the rules with the sources.

Sources identify the entities sending the syslog messages, and the associated rules extract the events from the
syslog messages. Messages coming from non-configured sources are dropped.

The syslog rule configurations provide FortiAuthenticator with the necessary information to parse username and
IP address information from a syslog feed, and inject this information into FSSO so it can be used in FortiGate
firewall policies.

FortiAuthenticator 6.4 Study Guide 221

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

The configurations necessary for leveraging syslog information is as follows:

1. Enable the syslog SSO method.
2. Create a syslog rule. Rules are required for every syslog source. Predefined rules are available for FortiNAC,
Cisco, and Aruba wireless controllers. For other systems, new rules can be created to parse the messages.
3. Configure the syslog sources on the Syslog Sources page. This includes selecting a name and configuring
the IP address of the source. Each syslog source must be defined for traffic to be accepted by the syslog
daemon. You must also select a matching rule. Finally, you must select an SSO user type (external, local, or
remote).

FortiAuthenticator 6.4 Study Guide 222

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

To enable integration with third-party systems, FortiAuthenticator offers a programmatic REST API that can be
used to authenticate and deauthenticate users into FSSO. This can be used for integration with third-party
applications such as portals and identity management systems.

For more information, see the FortiAuthenticator REST API Solution Guide.

FortiAuthenticator 6.4 Study Guide 223

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

FortiAuthenticator devices support the collection of login information from Windows Active Directory systems
through the installation of the DC agent on the domain controller. Terminal services (TS) agent is a similar
concept, except it collects user login information from Citrix or Windows terminal servers. Citrix users do not have
unique IP addresses. When a Citrix user logs in, the TS agent assigns that user a range of source ports.

FortiAuthenticator 6.4 Study Guide 224

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

In order to use the DC agent and/or TS agent, FortiAuthenticator must be set to listen and accept the incoming
packets from the agents. To do this, enable DC/TS Agent Clients. Remember, FortiAuthenticator can implement
the polling functionality directly, but it can also accept a feed from both DC agent and TS agent installations, if
necessary.

To configure, you must also specify a UDP port (the default is 8002). To enable authentication, select Enable
Authentication and enter the secret key of the DC/TS agent.

FortiAuthenticator 6.4 Study Guide 225

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

RADIUS accounting proxy is different from the previously mentioned RADIUS accounting.

• RADIUS accounting is used to convert, for example, third-party (or FortiGate Wi-Fi/VPN login) RADIUS events
to RSSO. This is most useful in an enterprise environment for adding third-party user identity sources.
• RADIUS accounting proxy, on the other hand, takes in one accounting source and redistributes it to multiple
FortiGate devices. This is most commonly used by ISPs and carriers.

The RADIUS accounting proxy must be configured with:

• Rule sets to define or derive the RADIUS attributes that FortiGate requires
• The source of the RADIUS accounting records (the RADIUS server)
• The destinations of the accounting records (the FortiGate devices using this information for RADIUS SSO
authentication)

Once configured on FortiAuthenticator, FSSO can include users.

FortiAuthenticator 6.4 Study Guide 226

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 227

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 228

 FSSO Process and Methods

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to use FortiAuthenticator as a login event
collector that uses the FSSO communication framework to transparently authenticate users.

FortiAuthenticator 6.4 Study Guide 229

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to use FortiAuthenticator as a login event collector that uses the Fortinet Single
Sign-On (FSSO) communication framework to transparently authenticate users.

FortiAuthenticator 6.4 Study Guide 230

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 231

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in preparing FortiAuthenticator and FortiGate for FSSO, you will be able to set up
FSSO using FortiAuthenticator on your network.

FortiAuthenticator 6.4 Study Guide 232

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Each FortiGate that uses FortiAuthenticator to provide SSO authentication must be configured to use
FortiAuthenticator as an SSO server. To do this, you need to create an FSSO agent—which sets
FortiAuthenticator as an SSO server—on FortiGate.

You can configure the FSSO agent on FortiGate on the External Connectors page. You must select FSSO
Agent on Windows AD as the type of SSO agent, enter a name for the agent, enter the IP address of your
FortiAuthenticator, and finally, enter a secret key. The secret key must be the same as the one you will define on
FortiAuthenticator when you enable FSSO authentication later in the process.

FortiAuthenticator 6.4 Study Guide 233

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

When a user tries to access network resources, FortiGate selects the appropriate firewall policy for the
destination. The selection consists of matching the FSSO group the user belongs to with the firewall policy that
matches 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.

You can configure the FSSO user group on FortiGate on the User Groups page. You must enter a name for the
group and select Fortinet Single Sign-On (FSSO) as the group type.

FortiAuthenticator 6.4 Study Guide 234

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

To allow FortiAuthenticator to listen for requests from authentication clients, you must enable FSSO
authentication.

You can enable FSSO authentication on FortiAuthenticator on the General page. You must enable Enable
authentication and then type the secret key in the Secret key field. The secret key that you type here must be
the same secret key that you defined when creating the FSSO agent on FortiGate.

FortiAuthenticator 6.4 Study Guide 235

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

In order to provide FSSO to specific groups on a remote LDAP server, you can filter the polling information so
that it includes only those groups.

You can create a FortiGate filter on the FortiGate Filtering page. You must name the filter, provide the IP
address of FortiGate, enable Forward FSSO information for users from the following subset of
users/groups/containers only, and select the LDAP server and remote group on which you want to filter.

In some situations is may be desirable to exclude designated IP addresses from the FSSO process, for example,
domain controllers or Exchange servers. This is accomplished through the creation of IP filtering rules. Once
crated these rules can be added to the FortiGate filtering configuration.

Note that FortiGate filtering has no effect on which FSSO events are stored on FortiAuthenticator. The filters
affect only which events are passed down to FortiGate.

FortiAuthenticator 6.4 Study Guide 236

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Finally, in order to allow FortiGate to receive a list of user groups from FortiAuthenticator, you need to add the
SSO group on FortiAuthenticator to the FSSO agent on FortiGate.

If you already created your FSSO agent on FortiGate, you just need to edit it, and then click Apply & Refresh, or
from the CLI, issue the command: execute fsso refresh. FortiGate is able to view the remote group that
you set to filter. The group can now be used in firewall policies.

FortiAuthenticator 6.4 Study Guide 237

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

To use FortiNAC as an SSO session source, you must first configure FortiNAC to participate in SSO session
information transfer. This is accomplished from the Fortinet FSSO Settings page in the System
Communication folder. You must enable Enable FSSO Communications, a port designated for communication
(the default is 8000), and set a password. You must use the same password when configuring devices to gather
SSO session information from FortiNAC.

FortiAuthenticator 6.4 Study Guide 238

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

On the FortiAuthenticator FortiNACs settings page, you will create a FortiNAC entry for each FortiNAC device
the FortiAuthenticator will gather SSO session information from. Each entry will contain a name for the FortiNAC
device, the IP/FQDN of the FortiNAC device, the communication port (this must match the setting on FortiNAC),
and a password (this must match the one configured on FortiNAC).

FortiAuthenticator 6.4 Study Guide 239

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

You must enable the FortiNAC SSO method on FortiAuthenticator. You do this on the General settings page.
After you enable the Enable FortiNAC SSO setting in the Fortinet Single Sign-On (FSSO) section, you can add
FortiNAC sources. The available sources are the FortiNAC devices that have been added to this
FortiAuthenticator. FortiAuthenticator can now begin pulling the SSO session information.

FortiAuthenticator 6.4 Study Guide 240

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 241

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure FortiAuthenticator and FortiGate for FSSO.

Now, you will learn about how to optimize the additional settings for FSSO.

FortiAuthenticator 6.4 Study Guide 242

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring additional settings for FSSO, you will be able to fine-tune the
FortiAuthenticator to work seamlessly with FortiGate for FSSO authentication.

FortiAuthenticator 6.4 Study Guide 243

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Fine-grained controls provides options to include or exclude a user or group from SSO, and set the maximum
number of concurrent sessions that a user or group can have.

You can adjust the controls on the Fine-grained Controls page.

FortiAuthenticator 6.4 Study Guide 244

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Use SSO users and groups only when you need to modify the behavior of a user or group before sending it to
FortiGate. For example, you would use users and groups when you want to:

Exclude a user from SSO (only supported as a user, not as a group). This is needed in the following scenarios:
• Some antivirus products will log in using service accounts on the PC and overwrite the user credentials,
breaking FSSO.
• To override the default number of concurrent devices a user or group can have in FSSO.

FortiAuthenticator 6.4 Study Guide 245

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

You can configure user group membership on the General page to specify how to cache group information once
FortiAuthenticator has obtained it. There are two ways to cache information: passive mode and active mode.

In passive mode, items have an expiry time after which they are removed and re-queried upon the next login. In
active mode, items are periodically updated for all currently logged in users.

FortiAuthenticator 6.4 Study Guide 246

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Multiple FortiAuthentictor devices can be configured to work in a hierarchical tiering configuration. The supplier
FortiAuthenticator devices gather information locally, then send the information to the upstream FortiAuthenticator
collector. The collector then aggregates the supplier information and sends the logins up to the FortiGate
device(s).

FortiAuthenticator 6.4 Study Guide 247

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

You enable hierarchical tiering of suppliers and collectors on the General page. You must specify a collector
listening port (the default port is 8003). Suppliers will pass collected information to the configured listening port
while collectors listen to receive information on that port.

FortiAuthenticator 6.4 Study Guide 248

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

You can manage any supplier and collector tier nodes on the Tiered Architecture page.

You must provide a name for the node, a serial number, the role of the tier (supplier or collector), and the IP
address of the node.

FortiAuthenticator 6.4 Study Guide 249

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 250

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Good job! You now understand how to optimize the additional settings for FSSO.

Now, you will learn how to troubleshoot FSSO issues.

FortiAuthenticator 6.4 Study Guide 251

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objective shown on this slide.

By demonstrating competence in troubleshooting FSSO issues, you will be able to diagnose and fix FSSO issues
in your network.

FortiAuthenticator 6.4 Study Guide 252

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

When debugging Windows event log source issues, ensure you verify the domain controller configuration on the
Windows Event Log Source page. Check whether the account is specified in the correct User Principal Name
(UPN) format. Ensure the domain controller wasn’t disabled by accident. Lastly, check with your administrator
whether a secure connection is required.

FortiAuthenticator 6.4 Study Guide 253

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

You can find detailed logs in the FSSO debug log. The example shown on this slide indicates that the wrong
password is being used.

FortiAuthenticator 6.4 Study Guide 254

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

The SSO domain monitoring view displays the status of all configured domain controllers. Color coding is used to
convey the result of the last connection attempt for each listed controller.

A green domain controller indicates that the last connection attempt was successful. A gray controller indicates
there is no recent connection information, and a red controller indicates the last connection attempt failed.

Hovering the mouse pointer over a domain controller displays connection details for that controller.

Clicking a domain controller opens a Recent Queries window, which presents the 100 most recent queries
ordered by timestamp. The response times are also color coded as follows:
• Green: Less than 500 ms
• Orange: Between 500 and 1000 ms
• Red: 1000 ms or greater

Any failed queries will contain error information about the failure in the Error column.

FortiAuthenticator 6.4 Study Guide 255

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

The majority of FSSO issues can be traced back to incorrect permissions when querying LDAP or AD. The table
shown on this slide outlines the feature, where it is located on FortiAuthenticator, and the minimum Windows
permissions required.

FortiAuthenticator 6.4 Study Guide 256

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 257

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 258

 FSSO Deployment and Troubleshooting

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to use FortiAuthenticator as a login event
collector that uses the FSSO communication framework to transparently authenticate users.

FortiAuthenticator 6.4 Study Guide 259

 Portal Services

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about portal services offered by FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 260

 Portal Services

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 261

 Portal Services

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in portal services, you will be able to understand how they fit in your network
services.

FortiAuthenticator 6.4 Study Guide 262

 Portal Services

DO NOT REPRINT
© FORTINET

Portal service allows you to grant remote users access to certain portions of your network, using delegated
authentication. In this scenario, authentication requires the user to associate their device with the guest SSID,
as published by the FortiGate wireless controller.

FortiGate facilitates access control by redirecting the user’s web browser to one of FortiAuthenticator’s captive
or guest portals. Because of this, you have to configure FortiGate (on a per-FortiGate basis) to employ captive
or guest portal on FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 263

 Portal Services

DO NOT REPRINT
© FORTINET

This slide shows the general process flow for the portal service.

A user connects to the wireless or wired network and tries to access the internet. FortiGate intercepts the
traffic and redirects it to the FortiAuthenticator web login page defined in the FortiGate captive portal profile.

The user enters their credentials on the FortiAuthenticator web login page. FortiAuthenticator performs any
required preauthorization checks and displays the login message to the user. If the user does not have
credentials, there may (depending on configuration) be an option to purchase login time. The login message
instructs the user’s browser to submit the user credentials directly to FortiGate as HTTPS POST, for
authentication processing.

When FortiGate receives the client credentials in the HTTPS POST, it sends a RADIUS Access-Request to
the FortiAuthenticator RADIUS server to authenticate the user. FortiAuthenticator validates the Access-
Request message using its user database, which can either be local or remote (LDAP/RADIUS).

Based on the results of the authentication and authorization processing, FortiAuthenticator responds with
either an Access-Accept or Access-Reject message. RADIUS attributes returned by FortiAuthenticator can be
used to define the access granted to the user by FortiGate. Following a successful authentication and initiation
of the user session, the client is redirected to the originally requested URL, which should now be accessible.

Finally, timeout or user logout will end the session.

FortiAuthenticator 6.4 Study Guide 264

 Portal Services

DO NOT REPRINT
© FORTINET

FortiAuthenticator captive portal includes the following three options:

• Credentials authentication: Allows known users (users who already have an account) to authenticate
using their existing credentials (password and/or token code). The goal is to restrict access to a set of
preauthorized users only.
• Social WiFi authentication: Allows FortiAuthenticator to utilize third-party user identity methods (social
sites, valid e-mail address, or phone number) to authenticate users into a wireless guest network. The goal
is to provide some traceability of users, without requiring the heavy overhead of creating guest accounts.
• MAC address authentication: Allows FortiAuthenticator to authenticate the user with minimal interaction
from the user. This is useful in situations where the goal is to provide the most simple experience for the
user as possible (for example, wireless guest networks, retail environments, transient access such as
airports, hotels, and so on).

FortiAuthenticator 6.4 Study Guide 265

 Portal Services

DO NOT REPRINT
© FORTINET

Guest portal offers pre-login and post-login services that you can use with any authentication type.

Pre-login services offer features like account creation and validation, social login options, form-based
information gathering, disclaimer, password reset feature, and so on.

Post-login services offer features to guest profile information, change passwords, register tokens for the user,
and so on.

FortiAuthenticator 6.4 Study Guide 266

 Portal Services

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 267

 Portal Services

DO NOT REPRINT
© FORTINET

Good job! You now understand portal services.

Now, you will learn about authentication types.

FortiAuthenticator 6.4 Study Guide 268

 Portal Services

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating an understanding of authentication types, you will be able to identify their role in your
network.

FortiAuthenticator 6.4 Study Guide 269

 Portal Services

DO NOT REPRINT
© FORTINET

The credentials portal requires known users (users who already have an account) to authenticate using their
credentials (password and/or token code). The goal is to restrict access to a set of preauthorized users only.

For the credentials portal, the administrator must indicate which of the profiles to use for user authentication.
For environments with one FortiWifi that has multiple access points (APs), the administrator can specify a list
of IP addresses for all the APs.

When the user is redirected to the credentials portal login page, they are prompted to enter their username
and password, and (optionally) their FortiToken passcode. Upon successful login, FortiAuthenticator redirects
the user to the webpage they originally requested.

FortiAuthenticator 6.4 Study Guide 270

 Portal Services

DO NOT REPRINT
© FORTINET

Regardless of the supported social channel you choose to configure, all social providers follow a similar
process flow:
• The user requires a social account
• FortiAuthenticator delegates the authentication process to the social provider
• After confirming the identity, FortiAuthenticator creates a temporary account in RADIUS and provides it to
FortiGate
• FortiGate uses the credentials to log in

FortiAuthenticator 6.4 Study Guide 271

 Portal Services

DO NOT REPRINT
© FORTINET

The social WiFi authentication process from the user’s perspective is as follows:

1. The user connects to your Wi-Fi network when trying to access a URL, and the FortiAuthenticator social
WiFi splash page appears.
2. The user selects an authentication method from the social channels offered. If a social channel is not
configured, it appears greyed out (disabled), and the user is unable to select it.
3. FortiAuthenticator prompts the user to enter credentials for the selected social channel.
4. FortiAuthenticator redirects the user to the URL that they originally requested.

FortiAuthenticator 6.4 Study Guide 272

 Portal Services

DO NOT REPRINT
© FORTINET

The purpose of device-only authentication is to identify and authenticate users with minimal user interaction
and some degree of traceability. This authentication method is less disruptive and, therefore provides a better
user experience.

With MAC address authentication enabled, the user attempts to open a web browser, but is intercepted by the
FortiGate wireless controller, and redirected to the FortiAuthenticator portal configured to record the user's
MAC address (without requiring any user interaction). FortiAuthenticator then redirects the user to the
originally requested webpage.

FortiAuthenticator 6.4 Study Guide 273

 Portal Services

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 274

 Portal Services

DO NOT REPRINT
© FORTINET

Good job! You now understand authentication types.

Now, you will learn how to configure FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 275

 Portal Services

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating a competence in configuring portal service on FortiAuthenticator, you will be able to

configure this service in your network.

FortiAuthenticator 6.4 Study Guide 276

 Portal Services

DO NOT REPRINT
© FORTINET

This slide shows the steps needed to deploy the captive portal. Portal pages define the pre-login and post-
login services that the portal provides. Access points identify the point of connection used to access the portal.
The portal policy settings define the content of the portal and the authentication process.

FortiAuthenticator 6.4 Study Guide 277

 Portal Services

DO NOT REPRINT
© FORTINET

Portal creation consists of assigning a name to the portal, and if desired, an SMS gateway for end user
notifications. If you don’t have an SMS gateway, you can use the FortiGuard Messaging Service, if you have
valid licensing for the service.

FortiAuthenticator 6.4 Study Guide 278

 Portal Services

DO NOT REPRINT
© FORTINET

On the Pre-Login Services page, you can enable or disable the following services, based on your
requirements:

• Disclaimer: If you enable the disclaimer page, the end-user will need to accept the disclaimer before they
can proceed to the login page.
• Password Reset: You can enable this service to setup pre-login password reset.
• Account Registration: With this service enabled guest users, during account login, can register by
entering the required information in the fields specified on the Required filed configuration page. All
guest accounts created using the Account Registration feature will be placed in the group specified in the
Place registered users into a group option. FortiAuthenticator can randomly generate a password for the
guest user, or the user can specify their own password. All accounts registered through the guest portal
must be validated through SMS or email, before they are can be used to log in. FortiAuthenticator will send
the guest user an activation code that they can use to activate their account. Administrators do not have to
manually activate each self-registered account request.
• Token Revocation: Select this service to revoke tokens based on specified conditions.
• Usage Extension Notifications: This service sends users a notification if they exceed their allocated data
or time.

FortiAuthenticator 6.4 Study Guide 279

 Portal Services

DO NOT REPRINT
© FORTINET

Enabling post-login services allows you to set features that users can use after they are logged in
successfully. You can select the following services on the Post-login Services page:
• Profile: Select this service to allow authenticated users to view their account information, edit their account
information, or both.
• Password Change: Select this service to allow local users, remote users, or both to change their
password once they are successfully logged in.
• Token Registration: Select this service to enable the self-provisioning feature for FortiToken.
• Smart Connect: You can select and assign a smart connect profile.
• Device Tracking and Management: Select this service to allow users to register their device after they
are logged in. When you enable Device Tracking and Management, you must specify which device
group self-registered devices are put in, and specify the Maximum number of devices per user. The
number is set to 3 by default, but can be set to a maximum of 20.

FortiAuthenticator 6.4 Study Guide 280

 Portal Services

DO NOT REPRINT
© FORTINET

You can configure FortiAuthenticator to provide Windows AD users with the ability to change their Windows
AD passwords remotely. This capability can be provided in the three following ways:

1. Through RADIUS Login, this option requires all of the following configurations:
• FortiAuthenticator has joined the Windows AD domain.
• The RADIUS client is configured to use Windows AD domain authentication
• RADIUS authentication requests use MS-CHAPv2
• The RADIUS client must support MS-CHAPv2 password change
2. Through GUI User Login, this option requires one of the following two criteria:
• FortiAuthenticator is joined to the Windows AD domain
• Secure LDAP (LDAPS) is enabled, and the LDAP admin has sufficient permissions to reset user
passwords
3. Through GUI User Portal, this option requires one of the following two criteria:
• FortiAuthenticator is joined to the Windows AD domain
• LDAPS has been enabled

FortiAuthenticator 6.4 Study Guide 281

 Portal Services

DO NOT REPRINT
© FORTINET

Now, you will explore another benefit of adding FortiAuthenticator to your LAN edge solution.

If FortiGate is configured to authenticate clients using a remote LDAP server, VPN and wireless clients using
CHAP schemes cannot authenticate. This is the case for wireless clients that use PEAP/MSCHAP2 and IPsec
VPN clients with extended authentication (XAuth) and CHAP. The same applies for any other device or
application using CHAP, MSCHAP, or MSCHAP2 to authenticate against a FortiGate device that uses an
LDAP server as the back end.

During CHAP, MSCHAP, and MSCHAP2 authentication, a client sends a one-way hash of the password.
However, the LDAP server, which is on the back end, expects the password itself. FortiGate, which is acting
as the LDAP client, does not have the client passwords, nor can it convert a hashed password to a cleartext
password.

FortiAuthenticator 6.4 Study Guide 282

 Portal Services

DO NOT REPRINT
© FORTINET

Two methods that you can use to solve the CHAP and LDAP problem are:
• PAP: Configure FortiGate to use PAP instead of CHAP when authenticating clients. This approach is not
secure due to the nature of the PAP protocol.
• RADIUS: Change the back-end server from LDAP to RADIUS.

If you are using Windows AD as your LDAP server, an alternative is to use FortiAuthenticator as an
authentication proxy. FortiAuthenticator would be located between FortiGate and the Windows server. You
must also configure FortiAuthenticator to log in to the Windows domain using the credentials of a Windows
administrator. This adds FortiAuthenticator as a trusted device on the Windows AD domain, allowing
FortiAuthenticator to proxy the password hash from the client to the Windows server using NTLM.

FortiAuthenticator 6.4 Study Guide 283

 Portal Services

DO NOT REPRINT
© FORTINET

FortiAuthenticator can store the user database locally. It can also proxy authentication requests from a client
to a back-end authentication server.

Now, you will learn how to configure FortiAuthenticator to proxy authentication requests to a remote LDAP
server, which can be a Windows AD server.

You must configure the following settings: Name, Primary server name/IP, Base distinguished name, Bind
type, and administrator Username and Password for regular bind type. Note that the Base distinguished
name sets the root node where LDAP starts searching for user accounts.

You can select predefined LDAP templates in the Server type section. They include default attribute settings
for well-known LDAP servers, such as Windows AD, OpenLDAP, and Novell eDirectory.

If you want FortiAuthenticator to relay CHAP, MSCHAP, and MSCHAPv2 authentication to a Windows AD
server, you must enable Windows Active Directory Domain Authentication and enter the credentials for a
Windows administrator. FortiAuthenticator logs in to the domain as a trusted device, allowing
FortiAuthenticator to proxy CHAP, MSCHAP, and MSCHAP2 authentication using NTLM.

FortiAuthenticator 6.4 Study Guide 284

 Portal Services

DO NOT REPRINT
© FORTINET

The Smart Connect post-login service gives you the ability to preconfigure necessary network access security
settings, defined in Smart Connect Profiles, for users that authenticate through the FortiAuthenticator portal.
After successful authentication, the users will have a Smart Connect button displayed on the post-login main
page. The button will initiate the downloading of a script or executable file (depending on the end stations OS)
to perform the configurations.

You create a Smart Connect profile from the Smart Connect Profiles page in the following way:
1. In the Name field, type a name for this profile. In the Connection type field, the only available option is
Wireless.
2. Configure the EAP settings.
3. Configure wireless network details, including typing a value in the SSID field, and selecting WPA2
Personal or WPA2 Enterprise in the Auth method field. Note that if you select WPA2 Personal, you will
need to enter a pre-shared key. If you select WPA2 Enterprise, you will need to configure certificate
installation settings.
4. Configure the certificate installations settings.

FortiAuthenticator 6.4 Study Guide 285

 Portal Services

DO NOT REPRINT
© FORTINET

You configure access points (APs) to use as part of the portal selection criteria in a portal policy. The APs
define where an end user is being redirected from, in order to be directed to a specific portal.

FortiAuthenticator 6.4 Study Guide 286

 Portal Services

DO NOT REPRINT
© FORTINET

FortiAuthenticator uses portal policies to determine the appropriate portal and how the user is authenticated.

A multistep policy wizard guides you through the configuration of portal policies. In the initial step, Policy
type, you provide a name and description for the policy, as well as the type of access that FortiAuthenticator
will enforce.

The settings in the Type field allow you to direct users to a designated portal, which you select in the drop-
down list, or you can select Deny captive portal access to deny portal access.

You define the policy match criteria using the configuration options that you set in other policy wizard steps.

FortiAuthenticator 6.4 Study Guide 287

 Portal Services

DO NOT REPRINT
© FORTINET

You must configure a portal policy to present the portal page to the user. User portal access is mapped based
on the incoming POST parameters.

In the Portal Rule Conditions section, you can configure HTTP parameters that need to be matched before
the user is presented with the portal. Select a parameter in the HTTP parameter drop-down list, and then add
a condition by selecting one of the three pre-defined operators (exact_match, substring_match, or
in_range) in the Operator drop-down list.

Use the Value field to manually define the values of a condition.

For example, to present a portal to users who connect from an IP address in the range of 10.0.1.0/24, set
the following conditions:

HTTP parameter: userip

Operator:[ip] in_range
Value: 10.0.1.0/24

FortiAuthenticator 6.4 Study Guide 288

 Portal Services

DO NOT REPRINT
© FORTINET

In addition to the POST parameters, page presentation depends on the point of connection (the AP) and the
source of the RADIUS message. You select the access points and RADIUS clients on the Authorized clients
page by moving existing entries for each type to the Chosen Access Points and Chosen RADIUS Clients
lists.

FortiAuthenticator 6.4 Study Guide 289

 Portal Services

DO NOT REPRINT
© FORTINET

You define the type of authentication that FortiAuthenticator will use on the Authentication type page. The
authentication type options are:
• Password/OTP authentication: You can configure validation using local or remote user records, social
media accounts, or both. You can designate local and remote users by realm and filter them by group.
FortiAuthenticator can automatically add users that authenticate using social media accounts to groups
created on the User Groups page. You do not have to manually add users to the group, because
FortiAuthenticator does it dynamically on a successful authentication. You can only add users that log in
through the social or MAC address portals. You can configure account expiration times for social users.

• MAC Authorization: You can grant or deny access based on MAC address parameters or an authorized
group of MAC addresses.

You can configure FortiAuthenticator to automatically assign social users to a user group and define an
account expiration period.

FortiAuthenticator 6.4 Study Guide 290

 Portal Services

DO NOT REPRINT
© FORTINET

You configure the back-end authentication details on the Identity sources page. If you have enabled social
users as an authentication type, select the social platforms that will be available for user authentication. The
options are Facebook, Google, Twitter, Linkedin, WeChat, Phone number, and Email. For each option,
except for phone number and email, you must configure a remote OAUTH server.

In the Local/Remote Users section, select a username format and realms. You can filter each realm you
select down to the group level.

FortiAuthenticator 6.4 Study Guide 291

 Portal Services

DO NOT REPRINT
© FORTINET

You define authentication requirements, such as mandatory two-factor authentication, password-only

authentication, and so on, on the Authentication factors page. You can select user IP address parameters
for FortiGate or FortiWLC. The Adaptive Authentication option allows you to bypass OTP validation if the
user is on a trusted subnet. FIDO authentication can be used if a token has been registered to the user.
MAC address parameter options are available for CiscoWLC, FortiGate, and FortiWLC.

FortiAuthenticator 6.4 Study Guide 292

 Portal Services

DO NOT REPRINT
© FORTINET

The RADIUS response page provides a summary of the RADIUS response for each authentication result.

FortiAuthenticator 6.4 Study Guide 293

 Portal Services

DO NOT REPRINT
© FORTINET

Just like the customizable replacement messages used for the self-service portal (see the Administering and
Authenticating Users lesson), captive portal messages are also customizable. You can add, modify, or
remove fields. You can enable and disable features. For example, you can include a small eye in the
password field that a user can click on to see their password in plain text.

FortiAuthenticator 6.4 Study Guide 294

 Portal Services

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 295

 Portal Services

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure a FortiAuthenticator captive portal.

Now, you will learn how to configure captive portal settings on FortiGate.

FortiAuthenticator 6.4 Study Guide 296

 Portal Services

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring captive portal services on FortiGate, you will be able to use them
and apply exempt rules in your network.

FortiAuthenticator 6.4 Study Guide 297

 Portal Services

DO NOT REPRINT
© FORTINET

In order to authenticate portal users and allow them to access the FortiGate network, you must configure
FortiAuthenticator as a RADIUS server on FortiGate (RADIUS Servers page).

For social login, this may sound counterintuitive, because authentication takes place on the social network,
but in order to allow FortiGate to authenticate users, FortiAuthenticator creates a temporary user name and
password in RADIUS and provides the credentials to FortiGate. FortiGate then uses these credentials to
authenticate the user through RADIUS.

To configure FortiAuthenticator as a RADIUS server, you must enter the FortiAuthenticator IP and secret.

FortiAuthenticator 6.4 Study Guide 298

 Portal Services

DO NOT REPRINT
© FORTINET

A firewall user group for RADIUS users allows FortiGate to check a user’s credentials against the user group.
The authentication user group is required, because it is used to validate the user credentials as part of the
captive portal login process.

You can create a new group for your social users on the User Groups page. Here, you must set the type to
Firewall and create a new remote group, with the FortiAuthenticator RADIUS server configured in the
previous slide as the remote server.

FortiAuthenticator 6.4 Study Guide 299

 Portal Services

DO NOT REPRINT
© FORTINET

Now, you are ready to enable captive portal as the security mode on FortiGate, and specify the authentication
protocol you are configuring.

On a physical (wired) network interface, you can enable captive portal on the Interfaces page. First, select
Captive Portal as the security mode. Since you are using FortiAuthenticator, your authentication portal will be
external and you must provide the portal address that users will use for access. The portal address for the
guest portal is: URL/portal.

And finally, in the User Groups drop-down list, select your preconfigured firewall group for social users.

For Wi-Fi, a Wi-Fi interface does not exist until you create the Wi-Fi SSID. After you create the Wi-Fi SSID,
you can then enable captive portal by editing the Wi-Fi network interface on the Interfaces page or on the
SSID page.

FortiAuthenticator 6.4 Study Guide 300

 Portal Services

DO NOT REPRINT
© FORTINET

Now, you need to create firewall policies on FortiGate for captive portal. All traffic going through a FortiGate
must be associated with a policy (so it can be controlled and governed). FortiGate analyzes the connection
packet, registers the incoming, and outgoing interfaces, and attempts to locate a security policy that matches
the packet. If the policy matches the parameters, it looks for an action for that policy (accept or deny). If
FortiGate accepts the packet, it looks to see if there are any other instructions for processing the traffic.

To allow clients access to FortiAuthenticator for registration through the captive portal page, you must exempt
the traffic from the captive portal in the FortiGate policy. This option is only visible if the Policy Advance
Options feature is enabled on the Feature Visibility page.

FortiAuthenticator 6.4 Study Guide 301

 Portal Services

DO NOT REPRINT
© FORTINET

To allow users to authenticate to the social network sites before they are allowed to browse to the wider
Internet, some exemptions are required.

FortiAuthenticator 6.4 Study Guide 302

 Portal Services

DO NOT REPRINT
© FORTINET

You also need to create a firewall policy for outbound social network access. This policy allows user access to
specified social networks. You can configure this policy through the CLI or the FortiAuthenticator GUI. You
can create a separate outbound policy for each social network portal, if you prefer.

There is a large list of predefined internet services included in FortiGate. You can create additional services if
one that you need is not included in the predefined list.

FortiAuthenticator 6.4 Study Guide 303

 Portal Services

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 304

 Portal Services

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure FortiGate captive portal settings.

Now, you will learn about user management.

FortiAuthenticator 6.4 Study Guide 305

 Portal Services

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating an understanding of portal management tasks, you will be able to manage portals in your
network.

FortiAuthenticator 6.4 Study Guide 306

 Portal Services

DO NOT REPRINT
© FORTINET

You can monitor and manage portal users from the FortiGate Firewall User Monitor page.

The social portal removes the overhead of registering guests by using existing third-party identity systems to
authenticate and identify users. Although not registering users directly through FortiAuthenticator, you can still
trace some information about the users logged in to your network through the social portal.

You can monitor social logins from the FortiAuthenticator web-based manager on the Social Login Users
page.

FortiAuthenticator 6.4 Study Guide 307

 Portal Services

DO NOT REPRINT
© FORTINET

Although you configure account expiry in the FortiAuthenticator social portal settings, for various reasons, you
may wish to forcefully deauthenticate users prior to the expiry time. You can monitor and deauthenticate
users on FortiGate.

Note that session time outs may still apply.

FortiAuthenticator 6.4 Study Guide 308

 Portal Services

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives covered in this lesson.

FortiAuthenticator 6.4 Study Guide 309

 Portal Services

DO NOT REPRINT
© FORTINET

This slide shows the objectives covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to understand, configure, and monitor
portal services in our network.

FortiAuthenticator 6.4 Study Guide 310

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about private key infrastructure and how to configure FortiAuthenticator as a
certificate authority (CA) that can generate, distribute, and manage digital certificates.

FortiAuthenticator 6.4 Study Guide 311

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 312

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 313

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

PKI uses asymmetric cryptography as a way to secure communications between two entities. Cryptography
achieves four objectives:

• Data privacy (or confidentiality)

• Data integrity
• Authentication
• Non-repudiation

FortiAuthenticator 6.4 Study Guide 314

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

Asymmetric cryptography is the solution to the problem with symmetric cryptography, which relies on the
same secret key for both encryption and decryption. The problem with symmetric cryptography is that the
sender and recipient have to exchange the secret key so the message can be encrypted and decrypted. The
secret key is exchanged over the internet, and is therefore susceptible to being intercepted.

Asymmetric cryptography uses a key pair. There is a public key, which is openly distributed, and a private
key, which is kept secret by the owner. There is no concern about intercepting the public key, because it is
supposed to be public. The key pairs are mathematically linked, so a message encrypted by the public key
can be decrypted only by using the matching private key. Alternatively, a message encrypted by the private
key, can be decrypted only by using the matching public key.

FortiAuthenticator 6.4 Study Guide 315

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

Digital certificates, also known as X.509 certificates, are used to exchange the public key between two
entities. But they are also much more than that. They contain specific information that identifies both the entity
and the certificate issuer.

The certificate issuer is a CA. A CA signs each certificate it issues in order to certify that the digital certificate
and its contents are trusted and valid.

FortiAuthenticator 6.4 Study Guide 316

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

PKI uses the relationship trust model, and the CA is at the root of the hierarchy as the trusted third-party:
everything begins with the CA. A CA issues its own digital certificate—known as the root certificate—in order
to establish this point of ultimate trust. Once the root certificate is established, the CA can generate digital
certificates that are issued and signed by the root certificate. It can also issue a certificate to a subordinate
CA, which issues certificates on its behalf.

When a CA issues and signs a digital certificate, it is essentially proclaiming, “This is the entity who I say it is
and I certify it”. Accordingly, if users trust the CA and can verify the CA’s signature as authentic, then they
must trust that the public key does belong to the entity identified in the digital certificate.

FortiAuthenticator 6.4 Study Guide 317

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

A CA can generate many different types of certificates, each with different functions (and sometimes,
confusingly, with different names). A few common certificate types include:

• CA certificates (also called root or authority certificates): These certificates identify the CA and create the
root of a CA hierarchy. As such, the certificate details have the same input for both the Issuer and Subject
fields. These certificates are self-signed and contain the CA’s public key needed to decrypt signatures in
the signed certificates.
• Web server certificates (also called local service certificates): These certificates identify web servers and
are used to secure communication to and from web servers, such as an SSH server, HTTPS website, web
portals, or EAP 802.1X authentication servers. The certificate details have the DNS name of the server in
the subject field. The public key of the web server is included.
• User certificates (also called client certificates): These certificates identify one person to another, a
person to a device or gateway, or one device to another device. The certificate includes the public key
associated with the identity.

Both user and web server certificates fall under the category of end-entity certificates.

FortiAuthenticator 6.4 Study Guide 318

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 319

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

Good job! You now can describe PKI, digital certificates, and CAs.

Now, you will learn about certificate management on FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 320

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 321

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator can act as a self-signed or local CA for the creation, signing, and revoking of X.509
certificates, such as server certificates for HTTPS and SSH, and client certificates for HTTPS, SSL, and IPsec
VPN. These certificates can be used for VPN authentication, 802.1X authentication, Windows Desktop
authentication, and token-based authentication, to name a few.

As a CA, the administrator can also import other authorities' CA certificates and CRLs.

FortiAuthenticator 6.4 Study Guide 322

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator can also act as a SCEP server for:

• Signing user CSRs
• Distributing CRLs
• Distributing CA certificates

Users can request a user certificate through online SCEP at http://<FortiAuthenticator_IP>/app/cert/scep.

FortiAuthenticator 6.4 Study Guide 323

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

A CSR is a request sent to a CA in order to apply for a digital certificate. The CSR request is usually in the
PKCS#10 format for X.509 certificate requests and includes information the CA requires to issue a certificate.

A CRL is a list that contains revoked certificates (or, more specifically, the serial number of the certificates).
You would revoke a certificate when you no longer want it to be considered trustworthy, for example, if the
private key was compromised or the user who owns the certificate has left the company. A CRL is remotely
accessible, and updated and reposted by the CA periodically, so any entities attempting to validate the
certificate can see that it is revoked based on its presence on the CRL.

A revocation is irreversible. You can reverse only those revocations placed on hold (that is, for a missing
digital certificate).

FortiAuthenticator can sign CSRs as a CA, distribute CRLs, and insert OCSP URLs for client certificate status
queries of intermediate certificates.

FortiAuthenticator 6.4 Study Guide 324

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

OCSP provides a more efficient means for clients to validate certificate status. Instead of downloading and
searching a CRL list of certificate serial numbers OCSP validates as follows:
1. The client requests the servers certificate.
2. The server presents its certificate to the client. The certificate includes the OCSP responder URL to use
for validation.
3. The client validates the status of the certificate with the OCSP responder.
4. The OCSP responder returns the certificate status.

FortiAuthenticator can include the OCSP responder in intermediate certificates.

FortiAuthenticator 6.4 Study Guide 325

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

Acting as an LDAP client, FortiAuthenticator can authenticate users against an external LDAP server. It
verifies the identity of the external LDAP server by using a trusted CA certificate.

FortiAuthenticator 6.4 Study Guide 326

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

EAP is a type of authentication framework often used in wireless networks and point-to-point connections. In
this scenario, if a client is attempting to authenticate over EAP, FortiAuthenticator can check that the client’s
certificate is signed by one of the configured (and authorized) CA certificates. The client certificate must also
match one of the user certificates.

FortiAuthenticator 6.4 Study Guide 327

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator can also integrate with FortiManager to deploy digital certificates to multiple FortiGate
devices in VPN implementations. Site-to-site VPNs are often only secured with a preshared key, which, if
compromised, could give access to the whole network. With FortiAuthenticator, certificate-based
authentication is used to secure access to networks over VPN, which is a more secure authentication method.

First, FortiAuthenticator signs and generates the certificates. Second, FortiManager pushes the SCEP client
configuration to all FortiGate devices. Finally, the FortiGate devices automatically get the certificates from
FortiAuthenticator through SCEP.

FortiAuthenticator 6.4 Study Guide 328

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

For client-based certificate VPNs, certificates can be created and stored in the FortiToken 300 USB smart
card token—which is compatible with FortiClient. These client VPN connections are further secured with
FortiAuthenticator.

Since the FortiToken 300 stores an x.509 certificate, it can also be used to authenticate on web-based
applications as well as sign and encrypt email, PDF documents, Microsoft Office files, and software.

FortiAuthenticator 6.4 Study Guide 329

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 330

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

Good job! You now understand certificate management on FortiAuthenticator.

Now, you will learn how to generate local CA certificates.

FortiAuthenticator 6.4 Study Guide 331

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 332

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

In order for FortiAuthenticator to sign and distribute certificates as the ultimate point of trust in your network,
you need to generate a root certificate—a self-signed CA.

You can create a root certificate on the Local CAs page. You must select Root CA as the certificate type,
and, at a minimum, provide a name (cn), validity period, key size, and hash algorithm.

You also have the option to specify some advanced options for key usages (for example, non repudiation) and
advanced key usages (for example, code signing).

FortiAuthenticator 6.4 Study Guide 333

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

Once the root CA certificate is created, you can use it for generating and signing intermediate certificates. The
procedure is very similar to creating a root CA certificate, but this time you must select Intermediate CA
certificate as the certificate type. You must also select the local root CA that will sign the certificate.

The main reason for using intermediate certificates is for security. If a private key is compromised, all the
certificates signed with that private key are also compromised. In other words, if a CA signs hundreds of
thousands of end-entity certificates using its private key and that private key is compromised, the entire PKI
structure will fail. By using intermediate CAs, the PKI structure becomes segmented into branches. So if the
intermediate CA’s private key is compromised, only one branch in the PKI structure is compromised, and the
rest of the organization remains protected.

Other reasons for having intermediate CAs:

• Reduce overloading the CA
• Ease the administrative burden
o In large organizations, each department might run its own CA, which is certified by the
organization’s root CA

FortiAuthenticator 6.4 Study Guide 334

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator also allows you to create an intermediate certificate signed by a third-party root CA. In this
case, FortiAuthenticator must first generate a CSR and send it to the third-party CA. The third-party CA will
send back the signed certificate, which you then must import into FortiAuthenticator.

Again, the procedure for creating a CSR is very similar to creating a root CA certificate, but this time you must
select Intermediate CA certificate signing request (CSR) as the certificate type and not set a validity
period.

Selecting the Intermediate CA option will create and sign the certificate locally on FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 335

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator can leverage network HSMs for local CA cryptographic key storage. You create the
integration by configuring the HSM server by IP or FQDN, the partition password and client IP. You must also
authorize FortiAuthenticator as a client on the HSM. You then select the server during the creation of a root
CA on the FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 336

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 337

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 338

 PKI and FortiAuthenticator as a CA

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to use FortiAuthenticator as a certificate
authority (CA) that can generate, distribute, and manage digital certificates. You also learned about certificate
revocation lists (CRLs), certificate signing requests (CSRs), and using the Simple Certificate Enrollment
Protocol (SCEP) to import certificates into FortiGate.

FortiAuthenticator 6.4 Study Guide 339

 Certificate Management

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to use FortiAuthenticator to generate client certificates, manage certificate
revocation lists (CRLs), certificate signing requests (CSRs), and using Simple Certificate Enrollment Protocol
(SCEP) to import certificates into FortiGate.

FortiAuthenticator 6.4 Study Guide 340

 Certificate Management

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 341

 Certificate Management

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 342

 Certificate Management

DO NOT REPRINT
© FORTINET

You can manually export and import certificates (local or trusted CAs) on the Certificate Authorities page.

You can import the FortiAuthenticator root CA and intermediate CA signed by the root, once exported as a
file, into another network device, such as FortiGate. Once imported by the other network device, that device
can validate (and trust) any certificates signed by the FortiAuthenticator CA. You will examine importing the
root certificate into FortiGate later in this lesson.

Conversely, FortiAuthenticator can import another network device’s certificates. Once imported into
FortiAuthenticator, it can validate (and trust) any certificates signed by that CA.

FortiAuthenticator 6.4 Study Guide 343

 Certificate Management

DO NOT REPRINT
© FORTINET

As mentioned, other network devices, such as FortiGate, can import the FortiAuthenticator root CA. In the
case of FortiGate, you can do this on the Certificates page. You can import manually if you have the CA
certificate downloaded on your local computer, or you can choose to import through the SCEP protocol. The
URL of the FortiAuthenticator SCEP server is http://<FortiAuthenticator_IP>/app/cert/scep.

FortiAuthenticator 6.4 Study Guide 344

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiAuthenticator uses trusted certificates to validate certificates signed by an external CA. If

FortiAuthenticator needs to validate certificates that are signed by an external CA, you must import the
external CA certificate into the device. You can import trusted CAs on the Trusted CAs page.

By using the Learn Certificate button, a certificate chain can be extracted to show the CA certificates, both
root and intermediate. This can greatly simplify the process of importing root and intermediate certificates
from a designated host. You specify a hostname or IP address with a port number and FortiAuthenticator
gathers the certificate chain and will display it for import. The certificates in the chain can be imported
individually or as a group.

FortiAuthenticator 6.4 Study Guide 345

 Certificate Management

DO NOT REPRINT
© FORTINET

You can use the Import button to individually import trusted CA certificates that have been downloaded
locally.

FortiAuthenticator 6.4 Study Guide 346

 Certificate Management

DO NOT REPRINT
© FORTINET

As mentioned earlier, you can create an intermediate CA signing CSR through FortiAuthenticator. Once
created, the status appears as Pending. In order for the status to become active, you must manually export it
and send the file to a third-party CA for signing. Once signed, the third-party CA sends it back to
FortiAuthenticator where you must import it.

FortiAuthenticator 6.4 Study Guide 347

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiAuthenticator can sign certificate signing requests (CSRs). The .csr file is generated on the endpoint
that the certificate will be installed, and then uploaded to FortiAuthenticator to be signed. For example, a .csr
file could be generated on FortiGate in preparation for SSL deep inspection, and then uploaded to
FortiAuthenticator for signing.

FortiAuthenticator 6.4 Study Guide 348

 Certificate Management

DO NOT REPRINT
© FORTINET

Once the certificate has been signed it can be exported for distribution to the endpoint. For example, a
FortiGate device that had previously generated the .csr file.

FortiAuthenticator 6.4 Study Guide 349

 Certificate Management

DO NOT REPRINT
© FORTINET

Intermediate CA certificates can be exported with keys in a PKCS#12 archive file. You can then import the
certificate and key into an endpoints certificate store. Note that the key can only be exported one time.

FortiAuthenticator 6.4 Study Guide 350

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 351

 Certificate Management

DO NOT REPRINT
© FORTINET

Good job! You now understand exporting and importing certificates and CSRs.

Now, you will learn how to generate client certificates.

FortiAuthenticator 6.4 Study Guide 352

 Certificate Management

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 353

 Certificate Management

DO NOT REPRINT
© FORTINET

You can create a user certificate on the Users page. You must select the CA that will sign this user certificate,
such as a local root CA (which also includes local intermediate CAs) or a third-party CA. Optionally, if you
want to link this certificate to a user locally created on FortiAuthenticator, you can select the user in the drop-
down list. You must select the subject input method, either Fully distinguished name or Field-by-field, and
provide the required information. You must also specify an expiration date or time for the certificate.

You also have the option to configure the certificate further. For example, you can enable the certificate for
smart card logon, and specify some advanced options for key usages (for example, non repudiation) and
advanced key usages (for example, code signing).

FortiAuthenticator 6.4 Study Guide 354

 Certificate Management

DO NOT REPRINT
© FORTINET

Creating a local service certificate is very similar to creating a user certificate. You can create a local service
certificate on the Local Services page. Just as for the user certificate, you must select the CA that will sign
the certificate and the subject input method, as well as specify an expiration date or time for the certificate.

You also have the option to specify some advanced options for key usages for this certificate type as well.

FortiAuthenticator 6.4 Study Guide 355

 Certificate Management

DO NOT REPRINT
© FORTINET

Importing a local service certificate into FortiGate is similar to the process of importing the FortiAuthenticator
root CA certificate into FortiGate. You would import a local service certificate, for example, to provide
FortiGate with HTTPS access to the GUI. Essentially, the certificate becomes available to services and other
processes that run under the local service store.

You can import a local service certificate on the Certificates page on FortiGate. The FortiGate administrator
must have the local service certificate file available to upload.

FortiAuthenticator 6.4 Study Guide 356

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 357

 Certificate Management

DO NOT REPRINT
© FORTINET

Good job! You now understand how to generate client certificates.

Now, you will learn about CRLs and certificate revocation.

FortiAuthenticator 6.4 Study Guide 358

 Certificate Management

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 359

 Certificate Management

DO NOT REPRINT
© FORTINET

You can revoke user certificates on the User Certificates page, or local service certificates on the Local
Services page. Select the certificate and click Revoke. You must select a reason for the revocation from the
reasons listed in the Reason code drop-down list.

Once a certificate is revoked, the operation cannot be undone. The only way you can reinstate a certificate is
if you selected the reason code On Hold. You would place a certificate on hold if, for example, an employee
has misplaced their token with their digital certificate installed on it, but are not ready to concede it is lost, or if
a contractor is temporarily leaving the company, but will return.

By default, revoked or expired certificates do not appear in the certificate list.

FortiAuthenticator 6.4 Study Guide 360

 Certificate Management

DO NOT REPRINT
© FORTINET

The serial numbers of the revoked certificates are automatically placed on the CRL. However, the CRL is
maintained locally, so in order to let other CAs know of a certificate’s revoked status, you must export and
publish (distribute) the CRL.

You can export the CRL on the CRLs page. On FortiAuthenticator, a CRL exists for each local CA. Select the
CRL you want to export and click Export.

You should distribute or publish the CRL periodically, or each time a new certificate has been revoked.

You can also import CRLs from third-party CAs.

It is important to note that if a CA is deleted, their corresponding CRLs are also deleted (along with any user
certificates they signed).

FortiAuthenticator 6.4 Study Guide 361

 Certificate Management

DO NOT REPRINT
© FORTINET

You can import the CRL into FortiGate on the Certificates page.

In addition to static CRLs, FortiAuthenticator supports the Online Certificate Status Protocol (OCSP) as an
alternative method to checking a certificate’s revocation status, though usually CRLs are used. The OCSP
status check is carried out over HTTP or HTTPS with a request-response format. The authority responding
can reply with a status of good, revoked, or unknown. The OCSP responder can be accessed at
http://FortiAuthenticator_fqdn:2560.

FortiAuthenticator 6.4 Study Guide 362

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiGate can also import a CRL from the FortiAuthenticator SCEP client. This is done on the Certificate
page. Select SCEP and enter the FortiAuthenticator SCEP client URL:
http://<FortiAuthenticator_IP>/app/cert/crl.

When leveraging SCEP the service must be enabled on the client facing port.

FortiAuthenticator 6.4 Study Guide 363

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiAuthenticator supports the CRL distribution points (CDP) and Online Certificate Status Protocol (OCSP)
extensions. The CDP extension provides, within the certificate, the CRL server that can be used to check for
certificate revocation. The OCSP extension defines the URL of the OCSP responder, within the authority
information access field of the issued certificate.

FortiAuthenticator 6.4 Study Guide 364

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 365

 Certificate Management

DO NOT REPRINT
© FORTINET

Good job! You now understand CRLs and certificate revocation.

Now, you will learn how to enable and configure SCEP.

FortiAuthenticator 6.4 Study Guide 366

 Certificate Management

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 367

 Certificate Management

DO NOT REPRINT
© FORTINET

You can enable SCEP on the General page. You must enter the default CA and enrollment password. You
must also specify the enrollment method type.

Two SCEP enrollment methods are supported:

• Automatic: With this method, the administrator pre-approves the certificate first and gives the user a
challenge password. By using this password during the CSR submission, the user’s device will
immediately receive the signed certificate from the SCEP server.
• Manual and Automatic: With this method, the user submits a CSR first, the request shows up as pending
on FortiAuthenticator, and then the administrator manually approves or rejects the CSR. You must supply
the password to the administrator approving (or denying) the CSR request. With this option,
FortiAuthenticator can send an email to the administrator each time there is a CSR pending approval.

Note that when leveraging SCEP the service, you must enable HTTP and/or HTTPs administrator access on
the FortiAuthenticator interfaces that face the SCEP clients. This is also true for CRL distribution.

FortiAuthenticator 6.4 Study Guide 368

 Certificate Management

DO NOT REPRINT
© FORTINET

In order to pre-approve a CSR, you must create an automatic enrollment request on FortiAuthenticator. This
allows you to set a challenge password, which you then pass to the user who wants their certificate signed by
the FortiAuthenticator CA. Once the user has this challenge password and enters it into the CSR for
FortiAuthenticator, they will immediately receive the signed certificate from the FortiAuthenticator SCEP
server.

The automatic enrollment request does not have to be specific to a user, but to anyone who includes the
same subject in their CSR as was configured in the automatic enrollment request, along with the challenge
password. This is known as a wildcard request type and is usually not recommended.

You can create an automatic enrollment request on the Enrolment Request page. You must select the
request type (either regular or wildcard), the CA that will sign the CSR, the subject input method required in
the CSR (fully distinguished name or field-by-field), the validity period, the hash algorithm, and the challenge
password.

FortiAuthenticator 6.4 Study Guide 369

 Certificate Management

DO NOT REPRINT
© FORTINET

You can use a challenge password that is randomly generated by FortiAuthenticator or the preconfigured
default enrollment password of the SCEP client.

You can choose to distribute the random challenge password manually, over SMS, or over email. If you
choose to distribute it manually, the random password is displayed at the top of the page once the automatic
enrollment request is created.

After FortiAuthenticator creates the automatic enrollment request, the status is Pending until the user submits
their CSR with the challenge password.

FortiAuthenticator 6.4 Study Guide 370

 Certificate Management

DO NOT REPRINT
© FORTINET

If FortiAuthenticator has automatically pre-approved a CSR for FortiGate, the FortiGate administrator must
submit a CSR with the challenge password to FortiAuthenticator—after which, FortiAuthenticator
automatically approves the CSR.

On FortiGate, you can create the CSR on the Certificate page. In addition to filling out all the certificate
information, you must select Online SCEP as the enrollment method and enter the SCEP URL and password
provided by FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 371

 Certificate Management

DO NOT REPRINT
© FORTINET

Device self-enrollment is a method that local and remote users can use to obtain certificates for their devices.
It is primarily used to enable EAP-TLS for bring your own device (BYOD) configurations or VPN
authentication.

Note that EAP-TLS is a bidirectional certificate authentication method; the client and FortiAuthenticator EAP
need to have matching certificates from the same certification authority (CA).

You can enable device self-enrollment on the Device Self-enrollment page. You must:
• Select a preconfigured SCEP enrollment template
• Set a limit on the maximum number of devices that a user can self-enroll
• Select the key size for self-enrolled certificates (1024, 2048, or 4096 bits)

You also have the option to enable self-enrollment for smart card certificates. This requires you to configure
the device FQDN, because it is used in the CRL distribution points certificate extension.

FortiAuthenticator 6.4 Study Guide 372

 Certificate Management

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 373

 Certificate Management

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 374

 Certificate Management

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned about importing and exporting certificates and
certificate signing requests (CSRs), generating user and local service certificates, certificate revocation lists
(CRLs), and using the Simple Certificate Enrollment Protocol (SCEP) to import certificates into FortiGate.

FortiAuthenticator 6.4 Study Guide 375

 802.1X Authentication

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about wireless and wired 802.1X authentication.

You will learn how to configure FortiAuthenticator, FortiGate, and Windows workstations for a successful
802.1X operation.

FortiAuthenticator 6.4 Study Guide 376

 802.1X Authentication

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 377

 802.1X Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding 802.1X authentication, you will be able to use 802.1X
authentication methods in your network.

FortiAuthenticator 6.4 Study Guide 378

 802.1X Authentication

DO NOT REPRINT
© FORTINET

802.1X is a standard that provides authentication services to network devices that want to join a local wired or
wireless network. The 802.1X standard defines an authentication protocol called EAP. It also defines how
EAP is encapsulated over LAN (the EAPOL protocol) and over RADIUS.

802.1X involves three parties: the client (also commonly known as the supplicant), which is the device that
wants to join the network; the authenticator, which is a network device such as a wireless access point or
switch; and the authentication server, which is a host that supports the RADIUS and EAP protocol, such as
FortiAuthenticator.

The client is not allowed access to the network until the client’s identity has been validated and authorized.
Using 802.1X authentication, the client provides credentials to the authenticator, which the authenticator
forwards to the authentication server for verification. If the authentication server determines that the
credentials are valid, the client device is allowed access to the network.

Note that the authenticator does not need to have a certificate or have any knowledge of the authentication
method (PEAP, TLS, and so on). The authentication is tunnelled from the client to the FortiAuthenticator over
the RADIUS protocol.

FortiAuthenticator 6.4 Study Guide 379

 802.1X Authentication

DO NOT REPRINT
© FORTINET

When a client (device) connects to a LAN switch that requires 802.1X authentication, the credentials
(machine, user, or MAC address) are sent to the authenticator using EAP over LAN (or EAPOL). The
authenticator then forwards the EAP traffic to an EAP over RADIUS server (FortiAuthenticator).

If the client tries to send user data before authenticating, the traffic is blocked by the authenticator. The client
must authenticate first. The authentication process, is a follows:

1. The client sends an EAPOL-Start packet to initiate the EAP authentication.

2. The authenticator replies with an EAP-Request/Identity packet to request identification.
3. The client sends its identity (usually the username).
4. The information is forwarded to the RADIUS server in a RADIUS-Access request packet.
5. The RADIUS replies with an Access Challenge packet requesting the password.
6. The authenticator requests the password from the client.
7. The client replies with a Response/Auth packet, which contains the password.
8. The password is forwarded to the RADIUS server, which then replies with an Access-Accept packet to
grant the access.
9. The authenticator sends an EAP-Success packet to the client with a confirmation that the credentials are
OK.
10. The client can now send the user data.

FortiAuthenticator 6.4 Study Guide 380

 802.1X Authentication

DO NOT REPRINT
© FORTINET

This table summarizes the five EAP options that FortiAuthenticator supports.

• PEAP forms a potentially encrypted and authenticated TLS tunnel between the client and server using a
digital certificate on the server. It is known as the outer authentication method because it creates only the
TLS tunnel, to protect authentication transactions. Once the outer tunnel is formed, FortiAuthenticator uses
an EAP-type tunnel as an inner authentication method, such as MSCHAPv2.

• EAP-TTLS (or tunneled transport layer security) extends the TLS protocol. It uses digital certificates on the
server side only. After the server is securely authenticated to the client, it uses the tunnel (the secure
connection) to authenticate the client.

• EAP-GTC is a type of inner authentication method for PEAP, which provides user or device information. It
carries a text challenge from the authentication server and a reply that a security token generates. It allows
generic authentications to virtually any identity store, including OTP token servers, LDAP, Novell
eDirectory, and more. It uses digital certificates on the server side only.

• EAP-MSCHAPv2 is a means for a client and server to mutually authenticate each other, using MSCHAPv2
packets encapsulated in EAP messages, without the need for a client-side certificate.

• EAP-TLS also uses the TLS protocol and is considered one of the most secure EAP standards available
because it supports certificate-based authentication with public keys on both the server and client sides. It
is also the most commonly used method when supporting bring your own device (BYOD) in the enterprise.

FortiAuthenticator 6.4 Study Guide 381

 802.1X Authentication

DO NOT REPRINT
© FORTINET

The main advantage of using FortiAuthenticator for 802.1X solutions is that it includes all the features that are
required for EAP deployment. FortiAuthenticator is a certificate authority, a SCEP server, and a RADIUS
server all in one device.

You can also use the self-service portal with device certificate self enrollment.

FortiAuthenticator 6.4 Study Guide 382

 802.1X Authentication

DO NOT REPRINT
© FORTINET

When non-802.1X-compliant devices, such as a printer, want to join the network, FortiAuthenticator offers the
option of 802.1X MAC-based authentication. This feature allows you to add a list of MAC addresses to allow
into the network.

FortiAuthenticator also supports machine-based 802.1X authentication. This feature allows a Windows
machine to authenticate to a network using 802. 1X, prior to user authentication.

FortiAuthenticator 6.4 Study Guide 383

 802.1X Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 384

 802.1X Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand the basics of 802.1X.

Now, you will learn how to configure wireless 802.1X:EAP-TLS.

FortiAuthenticator 6.4 Study Guide 385

 802.1X Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring 802.1X: EAP-TLS/TTLS, you will be able to use the wireless
802.1X authentication method in your network.

FortiAuthenticator 6.4 Study Guide 386

 802.1X Authentication

DO NOT REPRINT
© FORTINET

To configure a wireless solution with 802.1X EAP-TLS authentication, you first require the following:

• A root CA:
You can use either an existing external CA to generate certificates and FortiAuthenticator can act as an
intermediate CA, or you can use FortiAuthenticator as a self-signed root CA. Refer to the Certificate
Management lesson for more information about how to configure a root CA.

• RADIUS server:
The RADIUS server allows FortiAuthenticator to authenticate users using RADIUS. Refer to the
Administrating and Authenticating Users lesson for more information about how to configure a RADIUS
server.

• Wireless clients:
For a wireless 802.1X solution, you require a wireless client. A wireless client should already be set up on
your FortiGate. This configuration is out of scope for this training. Refer to the FortiGate Administration
Guide for more information.

FortiAuthenticator 6.4 Study Guide 387

 802.1X Authentication

DO NOT REPRINT
© FORTINET

EAP-TLS uses public keys on both the server and the client side, so you need a root CA. The root CA issues
a local server certificate to FortiAuthenticator. To configure EAP-TLS, you need to do the following:

1. Create a local server certificate for FortiAuthenticator.

FortiAuthenticator acts as the authenticating AAA server and therefore requires a server certificate
(issued by the root CA). Refer to the Certificate Management lesson for more information about how to
create a local server certificate.

FortiAuthenticator 6.4 Study Guide 388

 802.1X Authentication

DO NOT REPRINT
© FORTINET

2. Configure the user account.

This involves binding the user’s certificate to their account (required for EAP-TLS), and enabling RADIUS
authentication on the User Management page. The RADIUS protocol is used to tunnel EAP messages
from the client to FortiAuthenticator. Note that you can enable RADIUS authentication for groups instead.
In this example, RADIUS authentication is enabled per user.

3. Configure the RADIUS server.

This permits the user to authenticate. If the RADIUS client is already preconfigured, you only have to set
the EAP type. You do this on the Authentication type page of the RADIUS policy. In the example shown
on this slide, the EAP type is set to EAP-TTLS. When you configure the RADIUS server, you also must
add the FortiGate wireless controller as an authentication client. This tells FortiGate where to forward the
RADIUS Auth requests from the client. For more information about configuring a RADIUS client, see the
Administering and Authenticating Users lesson.

FortiAuthenticator 6.4 Study Guide 389

 802.1X Authentication

DO NOT REPRINT
© FORTINET

4. Configure RADIUS-EAP settings.

After you generate the certificates, you must associate them with the RADIUS service, so that they are
used during the authentication process. To configure this association, you must select the EAP server
certificate that will be used. This is required for EAP-TLS and EAP-TTLS.

FortiAuthenticator 6.4 Study Guide 390

 802.1X Authentication

DO NOT REPRINT
© FORTINET

5. Configure FortiGate.
This involves:
• Configuring FortiAuthenticator as a RADIUS server on FortiGate. Refer to the Administering and
Authenticating Users lesson for how to configure a RADIUS server.
• Configuring the Wi-Fi controller SSID to use the WPA2 Enterprise security mode. You must also
configure the authentication to use the RADIUS Server.

FortiAuthenticator 6.4 Study Guide 391

 802.1X Authentication

DO NOT REPRINT
© FORTINET

6. Configure the wireless clients.

In the example shown on this slide, the native Windows wireless application is used, which supports various
EAP standards, including EAP-TLS. However, most of the third-party wireless drivers also support EAP, and
their configuration is similar. In most cases, Windows automatically detects the wireless network requirements
and auto-configures the wireless interface properly. In this lesson, you will learn about the manual
configuration for cases where the auto-configuration is unsuccessful.

To manually configure the wireless client, click Wireless Properties associated with your Wi-Fi connection. In
the dialog box that opens, click the Security tab and ensure that WPA2 Enterprise is selected as your
security type. In the Choose a network authentication method drop-down list, select Microsoft Smart
Card or other Certificate (this is the EAP-TLS setting for Microsoft, but other EAP options are available).

If you want to validate the RADIUS server certificate, you can click Settings and enable Verify the server’s
identity by validating the certificate.

FortiAuthenticator 6.4 Study Guide 392

 802.1X Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 393

 802.1X Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure 802.1X:EAP-TLS.

Now, you will learn how configure wired 802.1X authentication.

FortiAuthenticator 6.4 Study Guide 394

 802.1X Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring wired 802.1X authentication, you will be able to use it in your
network.

FortiAuthenticator 6.4 Study Guide 395

 802.1X Authentication

DO NOT REPRINT
© FORTINET

The wired 802.1X authentication process, in general, is very similar to the 802.1X:EAP-TLS authentication
process. The client tries to connect to the network through a LAN switch that supports wired 802.1X (such as
FortiSwitch). The workstation uses EAP over LAN (EAPOL), and the communication between the LAN switch
and the RADIUS server uses EAP over RADIUS.

The EAP configuration on FortiAuthenticator is the same for wired or wireless clients.

FortiAuthenticator 6.4 Study Guide 396

 802.1X Authentication

DO NOT REPRINT
© FORTINET

To configure a switch to use 802.1X authentication, you must enable 802.1X, enter the FortiAuthenticator IP
address as the RADIUS server IP, and provide the RADIUS secret key.

FortiAuthenticator 6.4 Study Guide 397

 802.1X Authentication

DO NOT REPRINT
© FORTINET

To enable 802.1X in Windows, open the Windows Component Services application (search for
services.msc). Open the properties for the Wired AutoConfig service and change the startup type to
Automatic. Now, the service will automatically start each time the computer is started. You must reboot your
computer for the changes to take effect.

FortiAuthenticator 6.4 Study Guide 398

 802.1X Authentication

DO NOT REPRINT
© FORTINET

After you restart your computer, and the Wired AutoConfig service is running, the LAN connection properties
displays a new tab called Authentication. On that tab, select the Enable IEEE 802.1X authentication
checkbox, and select the Microsoft Smart Card or other certificate authentication method (this is EAP-
TLS). Note that other EAP methods are also available.

Optionally, you can click Setting to enable the validation of the RADIUS local server certificate. If enabled,
you must install the root CA certificate of the CA that signed that RADIUS local certificate.

FortiAuthenticator 6.4 Study Guide 399

 802.1X Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 400

 802.1X Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure wired 802.1X authentication.

Now, you will learn how configure MAC-based authentication.

FortiAuthenticator 6.4 Study Guide 401

 802.1X Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objective shown on this slide.

By demonstrating competence in configuring MAC-based authentication, you will be able to use it in your
network.

FortiAuthenticator 6.4 Study Guide 402

 802.1X Authentication

DO NOT REPRINT
© FORTINET

The MAC-based authentication feature is a list of MAC addresses that are allowed access to the network. A
non-802.1X-compliant device will be accepted into the network only if its MAC address is on the list.

The RADIUS client, which is usually a LAN switch, must support 802.1X MAC-based authentication. That
means that the RADIUS Service-Type attribute must be set to Call Check, and the Calling-Station-ID must
contain the MAC address.

FortiAuthenticator 6.4 Study Guide 403

 802.1X Authentication

DO NOT REPRINT
© FORTINET

After you enable MAC-based authentication, you must create a list of allowed MAC addresses on the MAC
Devices page. The clients that do not support 802.1X, and whose MAC address is not in this list, will not be
able to connect to the network.

You can add MAC addresses one at a time, or you can import in bulk from a CSV file. The first column
contains the device names and the second column contains the corresponding MAC address.

FortiAuthenticator 6.4 Study Guide 404

 802.1X Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 405

 802.1X Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure MAC-based authentication.

Now, you will learn how to configure machine-based 802.1X authentication.

FortiAuthenticator 6.4 Study Guide 406

 802.1X Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in configuring machine-based authentication, you will be able to use it in your
network.

FortiAuthenticator 6.4 Study Guide 407

 802.1X Authentication

DO NOT REPRINT
© FORTINET

Machine authentication is performed by the computer, which sends its computer object credentials before the
Windows logon screen appears. Machine authentication commonly occurs when the computer starts up or the
user logs out. FortiAuthenticator caches authenticated devices based on their MAC addresses for a
configurable period of time.

You can limit access to the network based on the machine credentials provided during authentication. For
example, you can grant access to only the Active Directory server, to enable user authentication.

After the machine is authenticated, user authentication can take place to authenticate that the user is also
valid. You can then grant further access to the network based on the user credentials.

FortiAuthenticator 6.4 Study Guide 408

 802.1X Authentication

DO NOT REPRINT
© FORTINET

Windows AD machine authentication uses MSCHAPv2 for encryption. PEAP/MSCHAPv2 are only supported
when the Windows Active Directory Domain Authentication option is enabled on the Remote Auth.
Server settings page. For this reason, you must enable Windows Active Directory Domain Authentication
for access to the Windows AD computer authentication option in RADIUS policies.

FortiAuthenticator 6.4 Study Guide 409

 802.1X Authentication

DO NOT REPRINT
© FORTINET

You can configure machine authentication for your RADIUS clients on the Identity source and
Authentication factors pages in the RADIUS policy.

Without the override groups configured, the user will be authenticated and added to the group specified in the
RADIUS client configuration.

When the override group membership is set, the group membership is overwritten based on the logic
configured. For example, if the user is the only user authenticated (this is an employee but on an
unapproved personal device), they will be put into a “personal_device” group. Using the override groups, they
can then be added to a predefined VLAN (by using RADIUS attributes assigned to the group).

You must enable Use Windows AD Domain Authentication on the Identity source page in order to have
the Windows AD computer authentication option on the Authentication factors page. Recall that
Windows Active Directory Domain Authentication option must be enabled on the LDAP settings page for
access to these settings.

FortiAuthenticator 6.4 Study Guide 410

 802.1X Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 411

 802.1X Authentication

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 412

 802.1X Authentication

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned about 802.1X authentication and how to
configure it.

FortiAuthenticator 6.4 Study Guide 413

 SAML

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the security assertion markup language (SAML), and how to configure and
troubleshoot SAML using FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 414

 SAML

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 415

 SAML

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding SAML, you will be able to describe the process, identify the
different roles, and describe SAML SSO types.

FortiAuthenticator 6.4 Study Guide 416

 SAML

DO NOT REPRINT
© FORTINET

Security Assertion Markup Language (SAML) defines a framework for exchanging security assertions
between SAML entities. It uses an XML-based framework and browser cookies to exchange security
assertions between entities to achieve SSO. One of the main SAML use cases is multiple-domain web SSO.
Online business partners can exchange SAML assertions, to provide user access to multiple web services,
without asking the user to log in to each domain.

FortiAuthenticator 6.4 Study Guide 417

 SAML

DO NOT REPRINT
© FORTINET

At a minimum, you need the following SAML entities to perform SSO:

• Principal: requests access to a service that usually requires authentication and authorization using the
SAML model. A principal can be a user, group, or machine.
• IdP: responsible for creating, maintaining, and managing identity information for principals. It is responsible
for responding to requests for SAML assertions within a federation.
• SPs: provides a service to a principal. It relies on an IdP for authentication and authorization information
that it can use to provide access a principal.

FortiAuthenticator 6.4 Study Guide 418

 SAML

DO NOT REPRINT
© FORTINET

SAML uses security assertions to transfer user identity information between its entities, using the principal (for
example, a web browser). For SAML to work correctly, all SPs participating in SSO must trust the IdP. Once a
user is pointed to an IdP by an SP, the IdP is responsible for authenticating the principal, and asserting
relevant SAML assertions in the browser cookie. The principal will not have to re-authenticate when accessing
partner web services, as long as it is using and trusting the same IdP.

There are three main types of SAML assertions used in the SSO configuration:
• Authentication assertions: contain authentication information about the principal and time.
• Attribute assertions: contain attribute information related to the principal.
• Authorization assertions: contain information about the principal's access privileges.

FortiAuthenticator 6.4 Study Guide 419

 SAML

DO NOT REPRINT
© FORTINET

There are two types of SSO in SAML: IdP initiated and SP initiated.

A user can perform an IdP-initiated login by directly accessing the IdP login page from a browser and
generating a login event. On a web page, the user can then access all the applications that would have
required them to log in. This can simplify the configuration, and administrators do not need to implement
SAML functionality on web servers.

A user can perform an SP-initiated login by visiting a SAML SP-compliant page that would then redirect the
user to IdP for authentication. It will transparently redirect the users before providing access to secure content.
The SP will need authorization assertions from the IdP before allowing users to access resources.

FortiAuthenticator 6.4 Study Guide 420

 SAML

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 421

 SAML

DO NOT REPRINT
© FORTINET

Good job! You now have an understanding of SAML.

Now, you will learn about the SAML process flow.

FortiAuthenticator 6.4 Study Guide 422

 SAML

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding the SAML flow and the advantages of SAML, you will be able
to make deployment decisions for your environment.

FortiAuthenticator 6.4 Study Guide 423

 SAML

DO NOT REPRINT
© FORTINET

Now, you will learn about the SAML packet flow for a non-authenticated principal that is trying to access
resources.

1. The principal tries to access resources on SP1.

2. SP1 requests SAML assertion.
3. The principal replies that it does not have SAML assertion for SP1.
4. SP1 instructs the principal to redirect to the SAML IdP for authentication.
5. The principal contacts the IdP and requests SAML assertion for SP1.
6. The IdP asks the principal whether it has SAML authentication assertion for the contacted IdP.
7. The principal replies that it does not have an authentication assertion for the IdP.
8. The IdP then presents the principal with a login portal
9. The principal logs in with their credentials.
10. The IdP validates the credentials and updates its database with the login event.
11. Once the principal is successfully authenticated, the IdP provides it with SAML authentication assertion
and attributes the assertion for SP1.
12. The principal is redirected to the SP1 resources that it originally requested.
13. SP1 receives the SAML assertion for SP1, and authorizes the principal to access the resources.

The principal can continue to access resources on SP1, without having to log in again, until the SAML
authentication cookie expires, or the user closes the web session, or the user triggers a log out.

FortiAuthenticator 6.4 Study Guide 424

 SAML

DO NOT REPRINT
© FORTINET

Now, you will learn about the SAML packet flow for an authenticated principal that is trying to access
resources on another SP in the federation.

1. The principal tries to access resources on SP2.

2. SP2 requests SAML assertion.
3. The principal replies that it does not have SAML assertion for SP2.
4. SP2 instructs the principal to redirect for authentication to the SAML IdP.
5. The principal contacts IdP and requests SAML assertion for SP2.
6. The IdP requests SAML authentication assertion for itself.
7. The principal provides SAML authentication assertions to the IdP.
8. Once the IdP validates the SAML authentication assertion, it provides the principal with the SAML
attributes assertion for SP2.
9. The principal gets redirected to the SP2 resources that it originally requested.
10. SP2 receives the SAML assertion from the principal and authorizes the principal to access the resources
that it requested.

The principal can now access resources on SP2 until the SAML assertion expires, or the user closes the web
session, or the user triggers a logout.

FortiAuthenticator 6.4 Study Guide 425

 SAML

DO NOT REPRINT
© FORTINET

When using SAML for web SSO, SPs never need to directly communicate with the IdP for SSO to work. All
communication between the IdP and SPs happens through the principal that is trying to request the resources.
Another advantage of using SAML is that as long as the principal and IdP are located behind the same
firewall, user credentials will never leave the network. Third-party SPs will redirect unauthenticated users back
to the IdP for authentication, and users will enter credentials only after they is prompted by the IdP. Multiple
domains can use the same IdP for SSO when using SAML. SAML SSO relies on SAML assertions that are
created by the IdP, for a principal. SPs will use these assertions to grant access to the principal.

FortiAuthenticator 6.4 Study Guide 426

 SAML

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 427

 SAML

DO NOT REPRINT
© FORTINET

Good job! You now understand SAML SSO flow and advantages.

Now, you will learn how to configure FortiAuthenticator as a SAML identity provider.

FortiAuthenticator 6.4 Study Guide 428

 SAML

DO NOT REPRINT
© FORTINET

After completing this section, you will be able to achieve the objective shown on this slide.

By demonstrating a competent understanding of FortiAuthenticator IdP configuration, you will be able to

configure FortiAuthenticator IdP.

FortiAuthenticator 6.4 Study Guide 429

 SAML

DO NOT REPRINT
© FORTINET

You can configure FortiAuthenticator as a SAML IdP or an SP. When you configure FortiAuthenticator as an
IdP, it uses the self-serve login web portal to prompt the user for authentication. FortiAuthenticator can use
the local user database or remote authentication server to validate authentication requests. You must add all
SPs to FortiAuthenticator to establish a trust relationship between the SPs and FortiAuthenticator. Once an
SP is added to FortiAuthenticator, it can create SAML authorization assertions for the SP.

You can also configure FortiAuthenticator as an SP, to request assertions from a third-party IdP such as Okta.
When you configure FortiAuthenticator in the SAML SP role, it can use SAML attributes assertion to generate
an FSSO session and distribute the information to FortiGate devices within a network. This works in a similar
way to RADIUS SSO, where you use the attributes provided by the server to generate FSSO sessions for an
internal network.

Note that FortiAuthenticator can convert a SAML web SSO to an FSSO session.

FortiAuthenticator 6.4 Study Guide 430

 SAML

DO NOT REPRINT
© FORTINET

The following is the an overview of the configuration you must complete to enable FortiAuthenticator to
perform the IdP role in SAML.
• Create a realm for the remote authentication server.
• This is required only if you are using remote authentication server.
• Create or import local server certification to use in SAML configuration.
• Certificates will be used to sign SAML assertions.
• Enable and configure IdP settings.
• Select the authentication realm to use for user authentication.
• You can narrow down the scope to a specific group using group filter option.
• Add SP configuration.
• You must add all SPs separately.

FortiAuthenticator 6.4 Study Guide 431

 SAML

DO NOT REPRINT
© FORTINET

You must enable FortiAuthenticator to support SAML in the IdP role. The server address is used when
metadata information is generated. If you have multiple IPs on FortiAuthenticator, FortiAuthenticator will
define which interface will be used to listen for authentication requests. On the FortiAuthenticator IdP
configuration page, you can also modify the SAML SSO assertion timeout value. You can also select a default
realm that will be used for user authentication. You can specify to override remote users, if an account also
exists in the FortiAuthenticator user database. Furthermore, you can narrow down the scope of user lookup to
a specific group using the group filter option. You need to select an IdP certificate, which is a local service
certificate that you can generate or import in the certificate manager section of FortiAuthenticator. Enabling
the Get nested groups for user option allows the IdP to perform a nested group lookup for Windows AD.
Identity and access management (IAM) user accounts, created in the IAM view under Authentication > User
Management, can be used for SAML IdP logins.

FortiAuthenticator 6.4 Study Guide 432

 SAML

DO NOT REPRINT
© FORTINET

The next step is to define SPs on FortiAuthenticator. You must give a unique name and IdP prefix to each SP
that you add to the FortiAuthenticator configuration. You can choose to generate a 16-digit prefix to use in the
IdP entity ID, IdP sign-on, and logout URL. This prefix uniquely identifies the IdP to the SP. You must copy
this configuration to the SP configuration. SAML allows you to use XML metadata files to export these
parameters accurately.

You can click Import SP metadata to load a metadata file to assist in the configuration of a SAML service
provider. The metadata files are xml files that contain details about the service provider, such as, entity
descriptors, URLs, certificates, and so on. The SP metadata file provides the IdP with all the information it
needs to trust and accept redirection from an SP.

You can download all of the IdP-related configurations from this page by clicking Download IdP metadata at
the bottom of the view. The metadata file provides the information required for the SP to use and trust
FortiAuthenticator as an IdP.

FortiAuthenticator 6.4 Study Guide 433

 SAML

DO NOT REPRINT
© FORTINET

You can enable support for IdP-initiated assertion response in situations where it is necessary for the IdP
server to generate and send a SAML assertion to the SP, without a prior request from the SP. In this
configuration, the user accesses the IdP login portal and, if the user’s browser is already authenticated, the
user will be presented with a portal landing page that includes a list of SPs that participate in IdP-initiated
login. The end user can then select the SP to access, and the IdP will generate the SAML assertion and send
it to the SP.

The Relay state setting allows the SP to redirect the user after a successful assertion response.

When you enable the Participate in single logout option, logging out of the SP will automatically log you out
of all single-logout-configured SPs.

FortiAuthenticator 6.4 Study Guide 434

 SAML

DO NOT REPRINT
© FORTINET

Within the SP configuration, you can enforce further options. You can also enforce two-factor, or FIDO
authentication on users that log in through SAML. Depending on the options you select, users will be
prompted to enter a token with their credentials when they are prompted for authentication.

Assertion Attributes are used to pass information to an SP from the IdP. You can configure the assertion the
IdP will provide, after a user is successfully authenticated. For example, you can configure the Subject Name
ID attribute (usually used to send the username back to the SP) to send the email, User DN, or objectGUID
instead.

FortiAuthenticator 6.4 Study Guide 435

 SAML

DO NOT REPRINT
© FORTINET

SAML attributes assertions are used to return more than just authentication and authorization information
about a principal. SAML assertions can provide details about a principal that can then be used by SP to
extend the functionally of the service they offer. For example, an SP can use SAML attributes assertions to
exchange information such as principal membership level among multiple online partners that use the same
IdP for web SSO. You can create and assign more then one SAML attribute to a principal and send the
assertions only to SPs that you want to.

FortiAuthenticator 6.4 Study Guide 436

 SAML

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 437

 SAML

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure FortiAuthenticator as a SAML IdP.

Now, you will learn how to configure FortiAuthenticator as a SAML service provider.

FortiAuthenticator 6.4 Study Guide 438

 SAML

DO NOT REPRINT
© FORTINET

After completing this section, you will bea ble to achieve the objective shown on this slide.

By demonstrating a competent understanding of FortiAuthenticator SP configuration, you will be able to

configure FortiAuthenticator SP.

FortiAuthenticator 6.4 Study Guide 439

 SAML

DO NOT REPRINT
© FORTINET

When configuring FortiAuthenticator as a SAML SP, you do not need to host the user database locally. User
authentication will be performed by a third-party IdP, and FortiAuthenticator will direct principals to the IdP
portal for authentication. After the authentication is successful, FortiAuthenticator can then use SAML
assertions to generate FSSO sessions for the SAML principals. Then, FortiAuthenticator will share this
information with the FortiGate devices within the network to allow the principals to access the internet or
resources hosted locally.

FortiAuthenticator 6.4 Study Guide 440

 SAML

DO NOT REPRINT
© FORTINET

When using the FortiAuthenticator as a SAML SP, the communication sequence will look like this:
1. The client tries to connect to a web server on the internet.
2. FortiGate redirects the client to the captive portal (http://<FortiAuthenticator
IP>/login/saml-auth).
3. If the user doesn't already have a valid (non-expired) SAML login ticket, FortiAuthenticator redirects the
client to the SAML IdP.
4. The client authenticates on the SAML IdP portal and gets a SAML login ticket.
5. SAML IdP redirects the client to FortiAuthenticator.
6. The client gives the SAML login ticket to FortiAuthenticator.
7. The FortiAuthenticator adds the client to the list of logged-in SSO users, and the new list of logged-in SSO
users is sent from FortiAuthenticator, to FortiGate. At this point the FortiAuthenticator converts the SSO
users to FSSO, this allows you to leverage FSSO groups and firewall policies.
8. FortiAuthenticator redirects the client to the web server.

Note that you must configure captive portal exemptions for the client to FortiAuthenticator and the client to
SAML IdP.

FortiAuthenticator 6.4 Study Guide 441

 SAML

DO NOT REPRINT
© FORTINET

You must enable SAML portal services to configure FortiAuthenticator to act as an SP. Enable the SAML
portal by clicking Fortinet SSO Methods > SSO > Portal Services and enabling the Enable SAML portal
option.

FortiAuthenticator 6.4 Study Guide 442

 SAML

DO NOT REPRINT
© FORTINET

Create a remote SAML authentication server from Authentication > Remote Auth. Servers > SAML.
FortiAuthenticator will generate the SAML URLs and entity ID automatically. The Portal URL is where
unauthenticated users are directed for authentication. Requests on the portal authentication URL will be
redirected to IdP to perform user authentication. Importing the metadata file will configure the IdP settings.

Once the authentication is successful, the IdP will attach an assertion that FortiAuthenticator can then use to
generate an FSSO session for the principal. You can also configure FortiAuthenticator to perform LDAP
lookup for group membership of the principal, as long as the IdP and FortiAuthenticator use the same LDAP
server. You can also specify whether the username of the principal is pulled in from Boolean assertions or
test-based attributes.

Finally, the FAC must be configured as an SP in the IdP server.

FortiAuthenticator 6.4 Study Guide 443

 SAML

DO NOT REPRINT
© FORTINET

Furthermore, you can implicitly assign all SAML users to a specific SSO group that you can configure locally
on FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 444

 SAML

DO NOT REPRINT
© FORTINET

You can then configure FortiAuthenticator to use the remote SAML server as an IdP, by selecting it in the
Remote SAML server drop-down list.

FortiAuthenticator 6.4 Study Guide 445

 SAML

DO NOT REPRINT
© FORTINET

SAML assertions for a FortiAuthenticator SP will be used to generate FSSO sessions. You can view logs to
get more information about FSSO sessions, usernames, SAML authentications, and so on. You can view
successful SAML FSSO sessions on FortiAuthenticator on the SSO sessions tab. Note that SAML users are
categorized as external users and added to an SSO group called SAML FSSO that you created locally on
FortiAuthenticator. The FSSO sessions of all SAML users will be forwarded to the FortiGate devices with the
information you provided on the SSO Sessions page on FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 446

 SAML

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 447

 SAML

DO NOT REPRINT
© FORTINET

Good job! You now understand how to configure FortiAuthenticator as a SAML service provider.

Now, you will learn how to troubleshoot SAML configurations with FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 448

 SAML

DO NOT REPRINT
© FORTINET

After completing this section, you will be able to achieve the objective shown on this slide.

By demonstrating competence in SAML troubleshooting tools, you will be able to resolve SAML deployment
issues.

FortiAuthenticator 6.4 Study Guide 449

 SAML

DO NOT REPRINT
© FORTINET

When FortiAuthenticator is configured in the IdP role, you must identify whether the issue is caused by an
authentication error, or related to SAML assertions. In the IdP role, FortiAuthenticator needs to perform
authentication for the user, so you need to ensure that the portal is configured properly. Review the
FortiAuthenticator logs to identify what is causing the issue.

To troubleshoot SAML-related issues, you can use tools such as the SAML tracer add-on that will track all the
redirects and display SAML assertions. You can keep track of which SP initiated the SAML SSO, which IdP
the principal is redirected to, and what assertions were inserted in the browser. Verify the entire configuration
on both the IdP and the SP to ensure you used the correct URLs and entity IDs.

To troubleshoot debug errors on FortiAuthenticator, you can use the GUI logs to identify what is causing the
issues.

FortiAuthenticator 6.4 Study Guide 450

 SAML

DO NOT REPRINT
© FORTINET

If FortiAuthenticator is configured in a SAML SP role, FortiGate devices in the network must have
FortiAuthenticator configured as an external captive portal to forward unauthenticated user requests.
FortiGate must have an exempt policy in place to forward authentication requests that FortiAuthenticator will
be forwarding to the third-party IdP. If users are having issues accessing the login page, make sure that the
exempt policy is allowing all traffic to the IdP URL(s). Check the configuration on FortiAuthenticator to make
sure the IdP URLs and entity IDs are correct.

If the authentication is successful and you are receiving SAML assertions, verify that FSSO sessions are
created on FortiAuthenticator. Use a SAML tracer to view SAML exchanges and assertions, and refer to the
FortiAuthenticator logs to view errors. If you see FSSO sessions but users are still not able to access
resources, check the FSSO information on FortiGate to verify that users are populating properly.

FortiAuthenticator 6.4 Study Guide 451

 SAML

DO NOT REPRINT
© FORTINET

You can view SAML-related logs on FortiAuthenticator, in the log section.

FortiAuthenticator 6.4 Study Guide 452

 SAML

DO NOT REPRINT
© FORTINET

SAML session information can be found in the logs view. User information is displayed along with the
authentication time, the authentication expiration (shown as Valid Until), and the IdP session ID

FortiAuthenticator 6.4 Study Guide 453

 SAML

DO NOT REPRINT
© FORTINET

You can view SAML assertions and exchanges using the SAML tracer add-on in a Firefox web browser. This
add-on allows you to keep track of all redirections, and SAML assertions and attributes that are exchanged
during the authentication.

The example on this slide shows a SAML authentication request that is sent to an IdP. It includes SAML
protocol and assertion information, the IdP login portal address that the authentication request will be
forwarded to, and information about the SAML SP that is requesting the authentication. The request also
contains the assertion consumer service URL, which is where the response from the IdP will be returned.

FortiAuthenticator 6.4 Study Guide 454

 SAML

DO NOT REPRINT
© FORTINET

This slide shows an example of an authentication response sent from the IdP. The SAML authentication
response includes basic SAML protocol information. The authentication response also includes authentication
information such as the SAML NameID attribute value, time of authentication, authentication conditions
(validity period), and the response recipient (which is usually the SP).

FortiAuthenticator 6.4 Study Guide 455

 SAML

DO NOT REPRINT
© FORTINET

The authentication response assertion returned also includes authentication attributes by the IdP. The
attribute assertion contains additional information about a principal that can be used by an SP to provide
additional features and services to the authenticated user. The example shown on this slide includes two
attributes, username and user DN that are asserted by the IdP for this SP. SAML attributes can add extra
value because exchanging this information is completely transparent to the user.

FortiAuthenticator 6.4 Study Guide 456

 SAML

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 457

 SAML

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 458

 SAML

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you now understand SAML, and how to configure and
troubleshoot SAML using FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 459

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about fast ID online 2 (FIDO2) authentication. Specifically, an overview of how it
works, its advantages, and how to leverage it with FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 460

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiAuthenticator 6.4 Study Guide 461

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding fast ID online 2 (FIDO2), you will be able to describe the
processes and security advantages of FIDO2.

FortiAuthenticator 6.4 Study Guide 462

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

The FIDO2 set of specifications includes the World Wide Consortium’s (W3C) Web Authentication
(WebAuthn) and the FIDO Alliance’s Client to Authenticator protocol (CTAP).

FIDO2 leverages standard public key cryptography to provide a simpler and more secure authentication
option. A FIDO2-compliant device creates a public and private key pair for each online service using FIDO2
authentication and associates those with a user account. The public key is passed to the online service for
association with the user account on the service end. The private key is locally stored and never leaves the
device, so it cannot be compromised by phishing attacks or server-side data breaches, making it more secure
than a password-based solution. For the end user, authentication becomes far more convenient, requiring the
device to be unlocked with a simple PIN or non-memory-based option, like biometric (fingerprint, voice
recognition), or physical interaction (touch sensor or push button), replacing the need to remember
passwords. Security is further enhanced by the need for the FIDO2 device to be physically present with the
end user during authentication.

FortiAuthenticator 6.4 Study Guide 463

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

FIDO2 authentication leverages three key components:

1. The authenticator: This is most often a physical key, such as a FortiToken 400, Titan, or Yubiko, but could
also be an Android device or Windows Hello. The purpose of the authenticator is to generate and store
private and public key pairs to be associated with an online account or service. The authenticator requires
an interaction with the end user, such as scanning a fingerprint, entering a pin or pushing a physical
button, to perform authentication.
2. The client: This component interacts with the online service to perform the authentication and prompt the
user for authenticator activation. This is most often a web browser but could be another form of client,
such as FortiClient.
3. The server: This component is the service provider, such as Google or Facebook, or a identity provider,
such as FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 464

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

The packet flow for FIDO2 authentication occurs between the three FIDO2 components, and proceeds as
follows:
1. The user (with the authenticator) attempts to access the service using the client.
2. The client issues an authentication request to the server or IdP.
3. The server or IdP issues a challenge.
4. The client prompts the user to unlock their FIDO2 authenticator.
5. The authenticator uses the private key to sign the challenge and send it to the server or IdP.
6. The server or IdP validates the private key that signed the challenge matches the public key associated
with the user account, and if so, validates authentication.

FortiAuthenticator 6.4 Study Guide 465

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 466

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

Good job! You now have a brief understanding of FIDO registration and login processes.

Now, you will learn how to configure FIDO settings on FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 467

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

FortiAuthenticator 6.4 Study Guide 468

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

You can enable FIDO2 authentication for local and remote user accounts in the user records stored on
FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 469

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

To take advantage of FIDO2 authentication on FortiAuthenticator portals, both captive and self-service, you
must enable the FIDO authentication option on the corresponding portal policy. You can require both a
password validation as well as a FIDO2 token, or just the FIDO2 token. The FIDO authentication is applied
only to users who have a registered token.

FortiAuthenticator 6.4 Study Guide 470

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

When you enable the options on the self-service portal, users can register and manage their FIDO keys. To
add a key to their account, the user clicks the Add FIDO key button and enters a name for the key. The user
then must insert and unlock the key.

Once a key is added, it can be revoked if it becomes compromised or lost.

FortiAuthenticator 6.4 Study Guide 471

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

An administrative user can manage FIDO2 keys on the user properties page on FortiAuthenticator. A user can
revoke their own keys by selecting the Lost my FIDO token option on the login screen.

FortiAuthenticator 6.4 Study Guide 472

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

This slide shows an example packet flow with FortiAuthenticator acting as an IdP with FIDO2 authentication.
The steps to complete the authentication are as follows:

1. The user attempts to connect to the online service using the client.
2. The online service redirects the user agent to the FIDO2 enabled FortiAuthenticator using SAML.
3. The client issues a SAML request to FortiAuthenticator.
4. FortiAuthenticator issues a FIDO2 challenge.
5. The user unlocks the FIDO2 authenticator for the client.
6. The client responds to the FortiAuthenticator challenge.
7. FortiAuthenticator validates the response.
8. FortiAuthenticator issues the SAML assertion to the client.

The client is now able to access the online service.

FortiAuthenticator 6.4 Study Guide 473

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

You define when FIDO2 authentication is necessary in the Authentication section of a service provider
configuration. In the Authentication method option list, selecting FIDO-only requires that authentication is
based on the username and the FIDO2 key response. Selecting Password and FIDO requires both a valid
password for the user account, as well as a successful response from a FIDO2 key. FIDO2 authentication is
optional for any of the other selections, if it has been configured on the service provider.

FortiAuthenticator 6.4 Study Guide 474

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

The example shown on this slide shows a user logging in to a FortiGate device that has been configured as a
service provider on FortiAuthenticator. The service provider has the Authentication method set to FIDO-
only. The process proceeds as follows:
1. The user accesses the FortiGate login page and selects Sign in with Security Fabric. The user is
redirected to the authentication page on FortiAuthenticator.
2. The user enters their username, and then clicks Next.
3. The client instructs the user that they must enter the PIN for their security key.
4. The FortiAuthenticator challenges the client. The client signs the challenge with the private key.
FortiAuthenticator authenticates the user.
5. The client is redirected and logged in to the service (FortiGate).

FortiAuthenticator 6.4 Study Guide 475

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator logs the authentication process. In the example shown on this slide, the administrator login
in-session events can be seen as the lower four events in the log, and the logout events are the top three. You
can click any event in the event log to display log details.

FortiAuthenticator 6.4 Study Guide 476

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

FortiAuthenticator 6.4 Study Guide 477

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiAuthenticator 6.4 Study Guide 478

 FIDO2 Authentication

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you now understand FIDO, and how to configure FIDO
using FortiAuthenticator.

FortiAuthenticator 6.4 Study Guide 479

DO NOT REPRINT
© FORTINET

No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2022 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.