Fortinet FortiAuthenticator Study Guide for FortiAuthenticator 6.4
937 210 43MB
English Pages [480]
01 Introduction and Initial Configuration
02 Administrative Users and High Availability
03 Administering and Authenticating Users
04 Managing Users and Troubleshooting Authentication
05 Two-Factor Authentication
06 FSSO Process and Methods
07 FSSO Deployment and Troubleshooting
08 Portal Services
09 PKI and FortiAuthenticator as a CA
10 Certificate Management
11 802.1X Authentication
12 SAML
13 FIDO2 Authentication
Recommend Papers
File loading please wait...
Citation preview
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 02 Administrative Users and High Availability 03 Administering and Authenticating Users 04 Managing Users and Troubleshooting Authentication 05 Two-Factor Authentication 06 FSSO Process and Methods 07 FSSO Deployment and Troubleshooting 08 Portal Services 09 PKI and FortiAuthenticator as a CA 10 Certificate Management 11 802.1X Authentication 12 SAML 13 FIDO2 Authentication
4 39 73 112 149 196 230 260 311 340 376 414 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 webbased 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 hardwareinfo 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 loadbalancer 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. Selfregistration 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 minutes, every hours, or every 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 lockedout 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 selfservice 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 selfregister. 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 postlogin 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:///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:///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 twofactor 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. 2. 3. 4.
Obtain token data which consists of the serial number and seed. Register or add the tokens on the validation server. Assign tokens to users. 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 secondfactor).
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 deauthenticated 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 selfservice 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 AccessRequest 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. 2. 3. 4.
The user connects to your Wi-Fi network when trying to access a URL, and the FortiAuthenticator social WiFi splash page appears. 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. FortiAuthenticator prompts the user to enter credentials for the selected social channel. 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 postlogin 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 dropdown 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:///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:///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 dropdown 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:///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. 2. 3. 4. 5. 6. 7. 8.
The client sends an EAPOL-Start packet to initiate the EAP authentication. The authenticator replies with an EAP-Request/Identity packet to request identification. The client sends its identity (usually the username). The information is forwarded to the RADIUS server in a RADIUS-Access request packet. The RADIUS replies with an Access Challenge packet requesting the password. The authenticator requests the password from the client. The client replies with a Response/Auth packet, which contains the password. 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 EAPTLS). 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
The principal tries to access resources on SP1. SP1 requests SAML assertion. The principal replies that it does not have SAML assertion for SP1. SP1 instructs the principal to redirect to the SAML IdP for authentication. The principal contacts the IdP and requests SAML assertion for SP1. The IdP asks the principal whether it has SAML authentication assertion for the contacted IdP. The principal replies that it does not have an authentication assertion for the IdP. The IdP then presents the principal with a login portal The principal logs in with their credentials. The IdP validates the credentials and updates its database with the login event. 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. 2. 3. 4. 5. 6. 7. 8.
The principal tries to access resources on SP2. SP2 requests SAML assertion. The principal replies that it does not have SAML assertion for SP2. SP2 instructs the principal to redirect for authentication to the SAML IdP. The principal contacts IdP and requests SAML assertion for SP2. The IdP requests SAML authentication assertion for itself. The principal provides SAML authentication assertions to the IdP. 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:///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. 2. 3. 4. 5. 6. 7. 8.
The user attempts to connect to the online service using the client. The online service redirects the user agent to the FIDO2 enabled FortiAuthenticator using SAML. The client issues a SAML request to FortiAuthenticator. FortiAuthenticator issues a FIDO2 challenge. The user unlocks the FIDO2 authenticator for the client. The client responds to the FortiAuthenticator challenge. FortiAuthenticator validates the response. 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 FIDOonly. 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.