FortiAuthenticator Student Guide-Online
FortiAuthenticator Student Guide-Online
FortiAuthenticator Student Guide-Online
FORTINET
FortiAuthenticator
Student Guide
for FortiAuthenticator 4.0
DO NOT REPRINT
FORTINET
FortiAuthenticator Student Guide
for FortiAuthenticator 4.0
Last Updated: 27 November 2015
We would like to acknowledge the following major contributors: Carl Windsor and Kash Valji.
Fortinet , FortiGate , and FortiGuard are registered trademarks of Fortinet, Inc. in the U.S. and other
jurisdictions, and other Fortinet names herein may also be trademarks, registered or otherwise, of
Fortinet. All other product or company names may be trademarks of their respective owners. Copyright
2002 - 2015 Fortinet, Inc. All rights reserved. Contents and terms are subject to change by Fortinet
without prior notice. 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.
DO NOT REPRINT
FORTINET
Table of Contents
Logging In ...............................................................................................................................10
Disconnections/Timeouts .............................................................................................................................15
Screen Resolution...................................................................................................................16
Objectives ...............................................................................................................................20
Time to Complete....................................................................................................................20
Objectives ...............................................................................................................................23
Time to Complete....................................................................................................................23
Objectives ...............................................................................................................................32
Time to Complete....................................................................................................................32
Performing a self-registration..................................................................................................37
Testing.....................................................................................................................................47
DO NOT REPRINT
FORTINET
LAB 4: CAPTIVE PORTAL ..............................................................................50
Objectives ...............................................................................................................................50
Time to Complete....................................................................................................................50
Prerequisites ...........................................................................................................................50
Objectives ...............................................................................................................................62
Time to Complete....................................................................................................................62
Prerequisites ...........................................................................................................................62
Objectives ...............................................................................................................................74
Time to Complete....................................................................................................................74
Prerequisites ...........................................................................................................................74
Objectives ...............................................................................................................................92
Time to Complete....................................................................................................................92
Prerequisites ...........................................................................................................................93
Adding the FortiAuthenticator SSO group to the FortiGate FSSO Agent ..............................97
Exercise 4: DC polling.............................................................................................................107
Testing DC polling...................................................................................................................108
DO NOT REPRINT
FORTINET
LAB 9: TROUBLESHOOTING ..........................................................................109
Objectives ...............................................................................................................................109
Time to Complete....................................................................................................................109
Prerequisites ...........................................................................................................................109
FORTINET
Virtual Lab Basics
In this class, you will use a virtual lab for hands-on exercises. This section explains how to connect to
the lab and its virtual machines. It also shows the topology of the virtual machines in the lab.
Note: If your trainer asks you to use a different lab, such as devices physically located in
your classroom, please ignore this section. This applies only to the virtual lab accessed
through the Internet. If you do not know which lab to use, please ask your trainer.
FORTINET
Network Topology
Logging In
1. Run the System Checker. This will fully verify both:
compatibility with the virtual lab environment's software, and
that your computer can connect
It can also diagnose problems with your Java Virtual Machine, firewall, or web proxy.
Use the URL for your location.
North America/South America:
https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-West
Europe/Middle East/Africa:
https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe
Asia/Pacific:
https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC
If a security confirmation dialog appears, click Run.
FORTINET
If your computer successfully connects to the virtual lab, the result messages for the browser and
network checks will each display a check mark icon. Continue to the next step.
If a browser test fails, this will affect your ability to access the virtual lab environment. If a network
test fails, this will affect the usability of the virtual lab environment. For solutions, either click the
Support Knowledge Base link or ask your trainer.
2. With the user name and password from your trainer, log into the URL for the virtual lab. Either:
https://remotelabs.training.fortinet.com/
FORTINET
https://virtual.mclabs.com/
3. If prompted, select the time zone for your location, then click Update.
This ensures that your class schedule is accurate.
4. Click Enter Lab.
A list of virtual machines that exist in your virtual lab should appear.
From this page, you can access the console of any of your virtual devices by either:
clicking on the devices square, or
selecting System > Open.
FORTINET
FORTINET
5. Click K2-Win-Student to open a connection to that server.
A new window should open within a few seconds. (Depending on your accounts preferences, the
window may be a Java applet. If this fails, you may need change browser settings to allow Java to
run on this web site. You also may need to review and accept an SSL certificate.)
Depending on the virtual machine, the applet provides access to either the GUI or a text-based
CLI. Connections to Windows machines will use a Remote Desktop-like GUI. The applet
FORTINET
should automatically log in, then display the Windows desktop. For most lab exercises, you will
connect to this VM.
Disconnections/Timeouts
If your computers connection with the virtual machine times out or if you are accidentally
disconnected, to regain access, return to the initial window/tab that contains your sessions list of VMs
and open the VM again.
If your session frequently times out or does not connect, ask your instructor.
FORTINET
When connecting to a VM, your browser should then open a display in a new window or tab.
Screen Resolution
Some Fortinet devices' user interfaces require a minimum screen size.
In the Java client, to configure the screen resolution, click the arrow at the top of the window.
In the HTML 5 client, to configure screen resolution, open the System menu.
International Keyboards
FORTINET
If characters in your language dont display correctly, keyboard mappings may not be correct.
To solve this in the HTML 5 client, open the Keyboard menu at the top of the window. Choose to either
display an on-screen keyboard, or send text from your computer to the VM's clipboard.
To solve this in the Java client, copy and paste between your computer and the Java applet. This
sends special characters or combinations using the keyboard icon at the top of the applet window.
Troubleshooting Tips
If you can't connect to a VM, on the VM's icon, click System > Power Cycle. This fixes most
problems by forcing VM startup and connection initiation. If that does not solve the problem, try
System > Power Cycle and revert to initial state.
Note: Reverting to the VM's initial snapshot will undo all of your work. Try other solutions first.
FORTINET
If the HTML 5 client does not work, try the Java client instead. Remembering this preference
requires that your browser allow cookies.
Do not connect to the virtual lab environment through a low-bandwidth or high-latency connection,
including VPN tunnels or wireless such as 3G or Wi-Fi. For best performance, use a stable
broadband connection such as a LAN.
Do not disable or block Java applets if you want to use the Java client. In late 2015, Google
Chrome removed Java compatibility, so it cannot be used with the Java client. On Mac OS X since
early 2014, to improve security, Java has been disabled by default. In your browser, you must
allow Java for this web site. On Windows, if the Java applet is allowed and successfully
downloads, but does not appear to launch, you can open the Java console while troubleshooting.
To do this, open the Control Panel, click Java, and change the Java console setting to be Show
console.
Network firewalls can also block Java executables.
Note: JavaScript is not the same as Java.
FORTINET
exec update-now
FORTINET
Lab 1: Introduction to
FortiAuthenticator
While there is no lab associated with the Introduction to FortiAuthenticator lesson, this lab will provide
instruction on how to log into the devices you will be using with the other labs, such as the
FortiAuthenticator and FortiGate.
When instructed to log into any of these devices, this lab can be used as a reference.
Important information
All lab exercises are performed from Win-Student VM.
You can practice logging in to FortiAuthenticator and FortiGate now, or start at Lab 2:
Objectives
Exercise 1: Access the FortiAuthenticator Web-based manager
Exercise 2: Access the FortiGate Web-based manager
Time to Complete
Estimated: 5 minutes
FORTINET
Exercise 1: Accessing the FortiAuthenticator Web-based
manager
In this exercise, you will log in to the FortiAuthenticator Web-based manager. For the remainder of this
guide, any time you are instructed to log in to the FortiAuthenticator Web-based manager as admin,
you can reference this procedure.
Note: Accept the self-signed certificate or security exemption if a security alert appears.
HTTPS is the recommended protocol for administrative access to FortiAuthenticator. Other
available protocols include SSH, ping, SNMP, HTTP, and Telnet (if they have been
enabled).
3. At the login screen, enter the user name admin, leave the password blank, and click Login.
Note: This is the factory default user login for all FortiAuthenticator devices.
FORTINET
Exercise 2: Accessing the FortiGate Web-based
manager
In this exercise, you will log in to the FortiGate Web-based manager. For the remainder of this guide,
any time you are instructed to log in to the FortiGate Web-based manager as admin, you can
reference this procedure.
Note: Accept the self-signed certificate or security exemption if a security alert appears.
HTTPS is the recommended protocol for administrative access to FortiGate. Other
available protocols include SSH, ping, SNMP, and HTTP (if they have been enabled).
2. At the login screen, enter the user name admin, leave the password blank, and click Login.
Note: This is the factory default user login for all FortiGate devices.
FORTINET
Lab 2: Basic configuration
While the initial configuration of FortiAuthenticator is already done for you, including the IP address
and netmask, DNS servers, static routing (including the default gateway), and system time, there are
some basic configurations that are still required. These configurations are most typically performed by
customers and will also be used in future labs.
In this lab you will create an administrative profile and administrative user, and configure a default mail
server.
Objectives
Exercise 1: Create an administrator profile and user
Exercise 2: Configure the mail server
Time to Complete
Estimated: 15 minutes
FORTINET
Exercise 1: Creating an administrator profile and user
In this exercise, you will create an administrator profile and user, and assign the administrator profile
to the user. As mentioned in the training, administrator profiles are useful for dividing responsibilities
as well as controlling administrative access.
This exercise includes the following:
Creating an administrator profile
Creating an administrator user
Testing your administrator user permissions
FORTINET
Note that you can add or remove individual permissions for any permission set by moving
permissions between the Available user permissions upper box and Selected user
permissions lower box using the up and down arrows respectively.
For the purposes of this exercise, we will keep the default settings.
4. Go back to System > Administration > Admin Profiles and from the main pane, click Create
New.
5. From the Create New Admin Profile page, complete the following:
A. In the Name field, type Users-and-Devices.
B. Select the Read & Write option for Users and Devices. Leave all other permission sets set to
None.
A green rectangle with RW appears to the left of the Users and Devices permission set to indicate
read and write permission is enabled for that permission set.
C. Click OK.
FORTINET
FORTINET
2. From the Create New Local User page, complete the following:
Username admin2
Password fortinet
Password fortinet
confirmation
Role Administrator
Admin profiles Click the field and select the admin profile you
created: Users-and-Devices
Ensure Full permission is deselected. If selected, it would give read/write access to all
FortiAuthenticator permissions (i.e. the same permissions as the default admin user), and for the
purposes of this exercise we want to limit access.
4. Click OK.
You successfully created an administrative user and assigned an admin profile.
As you can see, once the user is created, more user account configuration options become
available:
5. Click User Information to expand the section and in the Email address field, type
admin2@fortinet.lab.
FORTINET
6. Click OK.
You successfully created an administrative user, assigned an admin profile, and configured an
email address.
7. Click Logout from the top right of the screen.
Username admin2
Password fortinet
Note that the Web-based manager menu items are restricted to those associated with the
assigned admin profile (User and Devices permission set).
FORTINET
FORTINET
Exercise 2: Configuring the mail server
In this exercise, you will configure FortiAuthenticator to use FortiMail as the new default Simple Mail
Transfer Protocol (SMTP) server. FortiAuthenticator sends email for several purposes, such as
password reset requests, new user approvals, user self-registration, and two-factor authentication.
This exercise includes the following:
Configuring the mail server
Setting email services to the FortiMail SMTP server
Name FortiMail
Port 25
Sender IT@yourcompany.com
4. From the Connection Security and Authentication section, deselect Enable authentication.
5. Click OK.
FORTINET
You successfully created a new mail server. However, note that the local mail server
(localhost:25) is still set as the default server.
6. To switch your new FortiMail mail server to the default server, select the FortiMail server and click
Set as Default.
3. Click Save.
You successfully specified that FortiAuthenticator use the FortiMail mail server for both
administrators and users.
FORTINET
Lab 3: Authenticating users
In this lab, you will configure and test the self-service portal and configure FortiGate as a RADIUS
client to FortiAuthenticator.
Objectives
Exercise 1: Configure and test the self-service portal
Exercise 2: Configure FortiGate as a RADIUS client to FortiAuthenticator
Time to Complete
Estimated: 35 minutes
FORTINET
Exercise 1: Configuring and testing the self-service
portal
In this exercise, you will configure and test the self-service portal. As mentioned in the training, you
can configure the self-service portal to ease the administrative burden from the administrator,
specifically in terms of adding new end users to FortiAuthenticator.
This exercise includes the following:
Setting the name for the self-service portal
Enabling self-registration
Modifying the replacement message
Performing a self-registration (as end user)
Approving the registration request
Completing the self-registration (as end user)
4. Click OK.
You successfully set a name for your self-service portal.
Enabling self-registration
In this procedure, you will enable and configure captive portal on FortiAuthenticator so users can
self-register.
FORTINET
To enable self-registration
1. Still on FortiAuthenticator, go to Authentication > Self-service Portal > Self-registration.
2. From the Edit Self-registration Settings page, enable the Enable checkbox.
The page expands with more configuration options.
3. Select Require administrator approval and select Enable email to administrator accounts.
4. From the Available administrators box (left), select admin2 and use the forward arrow to move
the administrator into the Chosen administrators box (right).
Note that if you expand the Required Field Configuration segment, First name, Last name, and
Email address are the required inputs from users during the self-registration process. You have
the option to collect more user information by selecting the available fields. If you want to collect
information not represented in the available fields, you can use one of the custom fields. You must
first create the custom field through Authentication > User Account Policies > Custom User
Fields.
For the purposes of this exercise, the default settings are satisfactory.
7. Click OK.
The success message at the top of the page indicates that you must edit the default User
Registration Page replacement message, as it contains a field requesting a password from
the user. Since you set the password to randomly generate during self-registration, the
password field is not required. You will modify this in the next procedure.
FORTINET
Modifying the replacement message
Based on your self-registration configuration, you must modify the default automatic message that is
sent to users. The default message requires users to enter a password during self-registration.
However, you set passwords to be randomly generated during the self-registration configuration in the
previous exercise, so you must remove the password field in the replacement message.
3. From the bottom right pane that includes HTML text for the default User Registration Page
replacement message, delete the code that is associated with the Password and Confirm
password fields. You can see these fields exist in the table located in the bottom left pane.
Code to remove:
<div class="form-row">
<span class="error">{{:password1_errors}}</span>
</div>
<div class="form-row">
<span class="error">{{:password2_errors}}</span>
</div>
FORTINET
Once the code is removed, the password fields no longer appear in the table in the lower left
pane.
4. Click Save from the top left corner of the lower left pane.
5. Click the Logout icon to log out of FortiAuthenticator.
The login screen should reappear with a Register link that is now activated for self-registration.
This link is what users will use to self-register.
FORTINET
Performing a self-registration
Now that the self-service portal is configured, you can test it by registering as an end-user.
2. From the registration page that appears, enter the following information and click Submit once
finished.
Username student
Since you specified earlier that admin2 must approve self-registrations, you now must check
the admin2 email address and approve the self-registration.
FORTINET
Name admin2
Password fortinet
C. Click Login.
2. Open the email from IT@yourcompany.com.
username admin2
password fortinet
FORTINET
Name student
Password fortinet
C. Click Login.
2. Open the email from IT@yourcompany.com.
FORTINET
5. From the left menu, click Change Password and complete the following:
FORTINET
Exercise 2: Configuring FortiGate as a RADIUS client to
FortiAuthenticator
In this exercise, you will set up the FortiGate as a RADIUS client to the FortiAuthenticator and also set
up Active Directory authentication on FortiAuthenticator. After the configuration is complete, you will
test it.
The use case is an administrator account logging on to the FortiGate using RADIUS and AD/LDAP
authentication.
Name FortiAuth-RADIUS
4. Leave all other parameters at their default values and click OK to create the RADIUS server.
FORTINET
To create a firewall user group for remote administrators
1. Still in FortiGate, go to User & Device > User > User Group and click Create New.
2. From the New User Group page, complete the following:
Name Remote-AD-admins
Type Firewall
3. From the Remote groups section, click Create New and complete the following:
Groups Remote-AD-admins
4. Click OK.
5. Click OK.
Administrator *
Type Remote
Wildcard <enabled>
FORTINET
Configuring a remote AD/LDAP server on
FortiAuthenticator
In this environment, an LDAP server with Active Directory has already been pre-configured for you. As
a result, FortiAuthenticator can connect to it for remote authentication, much like FortiOS remote
authentication.
In this procedure, you will configure FortiAuthenticator to connect to the LDAP server.
Name ADserver
Username cn=ADadmin,cn=users,dc=trainingAD,dc=training,dc=lab
We are using the credentials of an Active Directory user
called ADadmin to authenticate to Active Directory.
ADadmin is located in the Users organizational unit (ou).
Password Training!
This is the password pre-configured for the ADadmin user.
You must use it to be able to bind.
4. Click OK.
FORTINET
authentication server on which the user resides. FortiAuthenticator uses the specified realm to identify
the back-end RADIUS or LDAP authentication server or servers that are used to authenticate the user.
In this procedure, you will create an authentication realm for the Active Directory server.
Name Realm-ADserver
3. Click OK.
3. Click Go.
4. From the Import Remote LDAP Users dialog box, select the two Active Directory users:
cn=ADuser1 and cn=ADuser2.
These users were pre-configured in Active Directory for the purposes of this lab.
5. Click OK.
FORTINET
group.
3. From the LDAP users section, select aduser1 from the Available LDAP users box (left) and
move to the Selected LDAP users box (right) using the forward arrow.
4. Click OK.
FORTINET
To link RADIUS attributes to a group
1. Still in FortiAuthenticator, double-click the Firewall Admin group you just created in the previous
procedure and from the RADIUS Attributes section, click Add Attribute.
2. From the Create New User Group RADIUS Attribute dialog box, complete the following:
Vendor Fortinet
Attribute ID Fortinet-Group-Name
The attribute has to exactly match what has been specified on the
FortiGate Group.
Value Remote-AD-admins
3. Click OK.
4. Click OK.
Name FortiGate
Secret fortinet
FORTINET
Enabling the RADIUS service
The RADIUS service must be enabled on FortiAuthenticator in order to authenticate using the RADIUS
database. While this is enabled by default, it is a good idea to double-check.
Testing
To test the lab configuration, you only need to log into the FortiGate administrator interface as
aduser1. On the FortiGate, you should be able to see the current administrator on the status page
as being one of the Active Directory users and a successful log entry on FortiAuthenticator.
If you try the other AD user (aduser2), you should not be able to log in as they do not belong to the
Firewall Admin group.
Username aduser1
FORTINET
Password Training!
2. Go to System > Dashboard > Status and locate the System Information widget.
3. From the Current Administrator field, click Details.
You should see that the currently logged in administrator (aduser1) is an Active Directory user
(from 10.0.1.10, the Win-Student machine).
4. Go back to the FortiAuthenticator Web-based manager which you are logged into as admin.
5. Click Logging > Log Access > Logs and look for a successful authentication from a remote
LDAP user.
6. Go back to your tab with the FortiGate Web-based manager, log out and log back in as aduser2.
This user was not added to the Firewall Admin group and therefore should not be allowed to
authenticate.
Username aduser2
Password Training!
7. Go back to your tab with the FortiAuthenticator Web-based manager and refresh the Logs page.
You should see several authentication failed messages.
8. Optionally, you can see the Group RADIUS Attribute being added and sent back from the
FortiAuthenticator through the CLI:
A. Open PuTTY on Win-Student and connect to the FORTIGATE saved session (connect over
SSH).
B. Log in as admin.
C. Type the following command:
FORTINET
diagnose test authserver radius <RADIUS server name> pap <ad admin
user> <password>
Where:
<RADIUS server name> is FortiAuth-RADIUS
<ad admin user> is aduser1
<password> is Training!
FORTINET
Lab 4: Captive portal
In this lab, you will configure Facebook social Wi-Fi authentication on FortiAuthenticator and FortiGate
and attempt to authenticate through the social portal. With this authentication method, guests can
access your network without the need to register (avoiding the heavy overhead for administrators), but
still provide administrators with some traceability of users.
Due to limitations of the network topology in this lab, the AD server on the Win-Student VM will be
used as the captive portal client. Accordingly, once Facebook social authentication is configured, any
Web access through the browser will be subject to the captive portal settings. It is what any guest
would see when attempting to connect to your network wirelessly.
For this lab, the Facebook configuration through the Facebook Developers site as described in the
training has already been performed for you. You will be supplied with an app ID and app secret that
you can use for your FortiAuthenticator configuration.
In order to configure social Wi-Fi authentication, you must configure both FortiGate and
FortiAuthenticator.
Objectives
Exercise 1: Configure FortiGate for social authentication
Exercise 2: Configure FortiAuthenticator for social authentication
Exercise 3: Test social authentication
Time to Complete
Estimated: 30 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to FortiAuthenticator and FortiGate.
FORTINET
2. Go to System > Dashboard > Status and from the System Information widget, click
Backup/Restore.
3. Under Restore, click Browse and browse to Desktop > Resources > FortiAuthenticator > Lab4
and select FortiAuthenticator-config-to-start-LAB4.
4. Click Restore.
5. Click OK.
3. From your local PC (Win-Student) browse to Desktop > Resources > FortiAuthenticator > Lab4
and select FortiGate-config-to-start-LAB4.
4. Click Restore
FORTINET
Exercise 1: Configuring FortiGate for social
authentication
When configuring social authentication, you must configure both FortiGate and FortiAuthenticator. This
exercise includes the FortiGate configuration only.
It includes:
Creating a user group for social users
Enabling captive portal on FortiGate
Configuring exempt rules for Facebook
Adding address group and exemption rules to group
Creating a firewall policy for FortiAuthenticator
Creating a firewall policy for social network access
Note: All procedures in this exercise are done from the FortiGate.
Name Social_Users
Type Firewall
4. From the Remote groups section, click Create New and complete the following:
5. Click OK.
6. Click OK.
FORTINET
Enabling captive portal on FortiGate
Now you are ready to enable captive portal as the security mode on FortiGate.
Since this lab uses a physical (wired) network interface, you can enable captive portal through the
network interface port 1.
You must configure the authentication protocol as external, and specify the Social_Users user group
you created in the previous procedure.
3. Click OK.
FORTINET
yet authenticated, you need to configure the FortiAuthenticator address group to use as an exemption
rule in the firewall policy.
FORTINET
4. Click OK.
5. Right-click the policy from the list and select Enable.
6. Enter the following commands in your FortiGate PuTTY session:
FORTINET
4. Click OK.
5. Right-click the policy from the list and select Enable.
The two firewall policies you added should look like this:
The last rule in the list is where captive portal unauthenticated client is caught
6. Enter the following commands in your FortiGate PuTTY session:
FORTINET
Exercise 2: Configuring FortiAuthenticator for social
authentication
When configuring social authentication, you must configure both FortiGate and FortiAuthenticator.
Now that you have configured FortiGate, you need to configure FortiAuthenticator.
FortiAuthenticator configuration includes:
Creating a user group for social users
Configuring the RADIUS client for the social portal
Note: All procedures in this exercise are done from the FortiAuthenticator.
Name Social_Users
Type Local
FORTINET
7. Click Save.
8. Click OK.
FORTINET
Place registered users into a group <enable>
Social_Users
4. Click OK.
This completes the access control settings for the captive portal. You can confirm this by going to
Authentication > Captive Portal > Access Control. Your settings should be similar to the
screenshot below:
FORTINET
Exercise 3: Testing authentication through the social
portal
In order to test the social portal, you will be required to authenticate with your personal Facebook
account.
2. Click Facebook.
3. When prompted to log in (you should be redirected to Facebook), enter your personal Facebook
account login credentials.
If you are not redirected to Facebook, make sure both FortiAuthenticator and FortiGate can ping
www.facebook.com.
If you see this warning, click Continue.
FORTINET
Upon a successful login, you will be redirected back to the originally requested page
(www.google.com) and the login and session details will be passed to FortiAuthenticator, which
will relay the information to FortiGate.
4. Through the FortiAuthenticator Web-based manager, go to Authentication > User Management
> Social Login Users to see the Facebook user details.
5. To see the authenticated social user added dynamically to the Social_Users group, go to
Authentication > User Management > User Groups.
6. Finally, through the FortiGate Web-based manager, go to User & Device > Monitor > Firewall
and view the user details there.
If you want to walk through the testing process again with the same Facebook login credentials,
you have to de-authenticate yourself (otherwise, you will remain authenticated for 1 hour, as
configured):
On FortiGate, go to User & Device > Monitor > Firewall, select your entry, and click
De-authenticate.
On FortiAuthenticator, go to Authentication > User Management > Social Login
Users, select your entry, and click Delete.
FORTINET
Lab 5: Two-factor authentication
In this lab, you will log into FortiAuthenticator with two-factor authentication. Two different methods for
authenticating with a second factor are provided and you are asked to configure one only.
See the table below for the two methods:
FortiToken Mobile With this option, you must use your own personal mobile device to
download the FortiToken Mobile app (the app is free from your iOS or
Android app store and instructions are provided in this lab). You will
then assign the student user the FortiToken Mobile token. You can
delete the app off your mobile device once complete.
Email OTP With this option, you will assign an email OTP to the student user.
This is an alternative method if you do not have a mobile device or do
not wish to use your personal mobile device.
Note: This lab provides both methods, so ensure you follow instructions for either the FortiToken
Mobile or email OTPnot both!
Objectives
Exercise 1: Configure FortiToken Mobile -OR- Email OTP
Exercise 2: Test two-factor authentication
Time to Complete
Estimated: 15-20 minutes
Prerequisites
Before beginning this lab, you must restore configuration files to both FortiGate and FortiAuthenticator.
The captive portal/social authentication configuration from the previous lab must be removed.
The configuration files you need to restore have already been created for you.
FORTINET
3. From your local PC (Win-Student) browse to Desktop > Resources > FortiAuthenticator > Lab5
and select FortiGate-config-to-start-LAB5.
4. Click Restore.
3. Under Restore, click Browse and browse to Desktop > Resources > FortiAuthenticator > Lab5
and select FortiAuthenticator-config-to-start-LAB5.
4. Click Restore.
5. Click OK.
FORTINET
Exercise 1: Configuring FortiToken Mobile or email OTP
Based on the second-factor method you want to use, complete one of the following:
Method Procedure
FORTINET
Exercise 1A: Creating an assigning a FortiToken Mobile
Complete this exercise only if you are using FortiToken Mobile as your two-factor authentication
method. If you want to use the email OTP method instead, go to Exercise 1B: Creating and assigning
an email OTP.
This exercise includes the following:
Obtaining the two free FortiToken Mobile tokens
Assigning a token to a user
Activating the FortiToken Mobile token
FORTINET
6. Optionally, you can add a comment to the token by selecting the token and clicking Edit. For
example, you can select the token you are going to assign later to the student user and add a
comment such as "For student user".
If you do want to assign a specific token to the student user, you should take note of the serial
number of the token (the last 3 digits will suffice) now.
FORTINET
To activate the FortiToken Mobile token
1. Log in to FortiMail Webmail as student:
A. Click FortiMail Webmail from the bookmark toolbar or go to https://10.0.1.100/mail.
B. At the login prompt, type:
Name student
Password fortinet
C. Click Login.
2. Open the new email from IT@yourcompany.com.
3. Start the FortiToken Mobile application by touching the icon on your device's screen.
4. If there is no PIN set (for example, if you are already using your own personal FortiToken
Mobile token issued your own employer and thus already have a PIN set), you will be
prompted to create a 4-digit PIN. Enter 1111 as your PIN.
FORTINET
5. Add your token by using the activation code provided in the activation email. You can either:
Scan the QR code included in the activation email to automatically input the activation
code
Enter the activation code included in the activation email automatically
NOTE: If you are already using your own personal FortiToken Mobile token issued your
own employer, click Edit and then click the + icon to add an additional account. Then follow
one of the methods below. You will be able to delete this account after, so it will not affect
your personal token.
Follow the instructions based on your selection below
Scan barcode, if your device supports it. 1. Return to your activation email and click the QR
(preferred method) code attached to the bottom of the email.
FORTINET
2. Select Fortinet from the token list.
FORTINET
Exercise 1B: Creating and assigning an email OTP
Complete this exercise only if you are using the email OTP method as your two-factor authentication
method. If you want to use the email FortiToken Mobile method instead, go to Exercise 1A: Creating
and assigning a FortiToken Mobile.
This exercise includes the following:
Increasing the token and email time out
Assigning an OTP to a user
Obtaining the OTP passcode
FORTINET
4. Click OK.
You successfully assigned an email OTP to a user for two-factor authentication.
Name student
Password fortinet
C. Click Login.
2. Open the new email from IT@yourcompany.com.
3. Record the OTP passcode.
4. Continue to Exercise 2: Testing two-factor authentication.
FORTINET
Exercise 2: Testing two-factor authentication
In this exercise, we will test logging in with your step-up authentication mechanism as the student
user.
Username student
Password fortinet
The second factor login appears and prompts you to enter your token code.
2. In the Token Code field, complete one of the following based on the method you selected to test
two-factor authentication:
Method Procedure
FortiToken Mobile 1. Open your FortiToken Mobile app on your mobile device
and log in with your PIN (1111).
2. Ensure the FortiToken Mobile app for the student user is
displayed.
3. Enter the FortiToken Mobile code in the Token Code field
for your second-factor authentication.
Email OTP 1. Enter the OTP passcode you recorded from the activation
email in the Token Code field for your second-factor
authentication.
3. Click Verify.
You successfully logged in with two-factor authentication.
FORTINET
Deleting the FortiToken Mobile app
If you elected to complete Exercise 1A: Creating and assigning a FortiToken Mobile, you no longer
require the FortiToken Mobile App on your personal device. Token authentication will not be used
again.
If you already had the FortiToken Mobile app 1. Log into the FortiToken Mobile on your
installed on your personal device with your personal device.
personal soft token
2. Click Edit.
3. Swipe left on the token assigned to the student
user and delete.
This preserves your own personal soft token.
If you installed the app specifically for this lab and 1. Delete the app off your personal device.
the student user's token is the only one
installed
FORTINET
Lab 6: Certificate management
In this lab, you will add certificate authentication to an SSL VPN.
In order to add certificate authentication, FortiAuthenticator must act as a certificate authority. For the
purposes of this lab, FortiAuthenticator is already configured with a root certificate that will be used as
the ultimate point of trust.
You will use the pre-configured FortiAuthenticator root certificate to create a user certificate. You will
then use the user certificate to authenticate to SSL VPN.
You will also need to install the FortiClient SSL VPN for this lab.
Objectives
Exercise 1: Configuring SSL VPN user groups
Exercise 2: Creating the user certificate
Exercise 3: Importing the root CA certificate over SCEP
Exercise 4: Installing and configuring the SSL VPN
Exercise 5: Testing certificate authentication over VPN
Exercise 6: Revoking a user certificate
Time to Complete
Estimated: 30 minutes
Prerequisites
Before beginning this lab, you must restore configuration files to both FortiGate and
FortiAuthenticator. The FortiAuthenticator configuration file includes the root CA certificate that will
be used as your ultimate point of trust.
FORTINET
To restore the FortiGate configuration file
1. Open a browser and log in to the FortiGate Web-based manager. For more information, see To
log in to the FortiGate Web-based manager.
2. Go to System > Dashboard > Status and from the System Information widget, click Restore.
3. From your local PC (Win-Student) browse to Desktop > Resources > FortiAuthenticator > Lab6
and select FortiGate-config-to-start-LAB6.
4. Click Restore.
Since this lab includes authenticating with a second factor method through VPN, it is necessary
that the VPN settings are configured on FortiGate. Since installing and configuring VPN is out of
scope for this lab, the configuration file includes the required VPN settings.
SSL VPN firewall policy for SSL VPN users (Policy & Objects > Policy > IPv4)
FORTINET
To restore the FortiAuthenticator configuration file
1. Open a browser and log in to the FortiAuthenticator Web-based manager. For more information,
see To log in to the FortiAuthenticator Web-based manager.
2. Go to System > Dashboard > Status and from the System Information widget, click
Backup/Restore.
3. Under Restore, click Browse and browse to Desktop > Resources > FortiAuthenticator > Lab6
and select FortiAuthenticator-config-to-start-LAB6.
4. Click Restore.
5. Click OK.
FORTINET
Exercise 1: Configuring SSL VPN user groups
In this exercise, you will create a user group for SSL VPN users and add the group to the RADIUS
client policy.
This exercise includes:
Creating a user group for SSL VPN users
Adding SSL VPN group to RADIUS client policy
Name SSL_VPN_Users
4. Select aduser1 from the Available LDAP users box to the left and move to the Selected LDAP
users box to the right.
5. Click OK.
6. Select the newly created SSL_VPN_Users group and click Edit.
7. From the RADIUS Attributes section, click Add Attribute and complete the following:
Vendor Fortinet
Attribute ID Fortinet-Group-Name
Value SSL_VPN_Users
8. Click OK.
9. Click OK.
FORTINET
Adding SSL VPN group to RADIUS client policy
In this procedure, you need to add the SSL VPN group you created to the existing FortiGate RADIUS
policy (you created this in Lab 3).
4. Click OK.
5. Click Save.
6. Click OK.
FORTINET
Exercise 2: Creating the user certificate
In this exercise, you will create a user certificate for aduser1. The user certificate will be signed by the
pre-configured FortiAuthenticator root CA certificate, called FortiAuthCA. The CA is the ultimate point
of trust in your PKI environment.
Once you create the user certificate, you will export it to a PKCS#12 file so it can be installed in the
personal certificate store of aduser1.
This exercise includes:
Creating the user certificate
Exporting the user certificate
Importing the user certificate into the VPN user's certificate store
Certificate ID aduser1
Issuer Local CA
4. Click OK.
FORTINET
To export the user certificate
1. Still in FortiAuthenticator, from Certificate Management > End Entities > Users, select the
aduser1 client certificate and click Export PKCS#12.
Note: Do not confuse this with the Export Certificate.
2. You should then be prompted to give the PKCS#12 file a passphrase. Type the following and click
OK:
Passphrase fortinet
FORTINET
6. Click Next.
7. Click Finish.
8. Click OK.
The certificate should be in the client personal certificate store (Certificates - Current User >
Personal). It is essential that it is, otherwise it will not be used for the VPN. You can check the
MMC Certificate Snap-In (on your Win-Student desktop) to ensure that the client certificate is in
the right place:
A. Open the MMC-Certificate-Snap-In on your Win-Student desktop.
B. From the left column, expand Certificates - Current User > Personal > Certificates. You
should see the aduser1 certificate in that location. If it is not there, you must move it to that
location.
FORTINET
Exercise 3: Importing the root CA certificate over SCEP
In order for FortiGate to be able to confirm the authenticity of aduser1 when they authenticate to VPN
using their certificate, FortiGate needs the FortiAuthCA root certificate. Remember, it is the root CA
that signed aduser1's certificate and is the ultimate point of trust.
There are a few different ways that FortiGate can import the certificate, but for the purposes of this lab,
we will use SCEP.
This exercise includes:
Enabling SCEP on FortiAuthenticator
Enabling the HTTP service for SCEP
Importing the root certificate into FortiAuthenticator
4. Click OK.
Note the warning about enabling HTTP access on the network interface that will serve SCEP
clients.
FORTINET
FORTINET
FORTINET
Exercise 4: Installing and configuring the SSL VPN
In this exercise, you will install the SSL VPN to the Win-Student VM so that your student user can
authenticate to it using two-factor authentication.
3. Click Apply.
4. Close the application.
FORTINET
Exercise 5: Testing certificate authentication over VPN
Now you are ready to authenticate to VPN with your user certificate as your second factor
authentication mechanism.
2. Ensure LAB VPN is selected as your VPN connection and complete the following:
aduser1
Training!
aduser1/FortiAuthCA
3. Click Connect.
4. Click Yes to the Security Alert warning.
The VPN connects with aduser1's user name, password, and certificate.
FORTINET
5. Click Disconnect to disconnect your VPN session (if FortiClient has minimized to your toolbar,
click it to maximize it first).
6. Close the application.
FORTINET
Exercise 6: Revoking a user certificate
In this exercise, you will revoke a user certificate. Once revoked, the certificate is placed on the
certificate revocation list (CRL).
A certificate revocation list is a list that contains revoked certificates (or more specifically, the serial
number of the certificates). As mentioned in the training, it is possible for a private key to become
compromised. For example, if it is lost or revealed or the CA no longer considers the certificate holder
trustworthy.
You will then import the CRL from FortiGate over SCEP, after which the certificate can no longer be
used to authenticate.
This exercise consists of:
Backing up your FortiAuthenticator configuration
Revoking a user certificate
Importing the CRL in FortiGate over SCEP
Testing certificate revocation
3. Under Backup, click Download backup file and then OK. The file saves to your Downloads
folder.
4. Rename the file to my-config-pre-cert-revocation.conf.
FORTINET
Revoking a user certificate
In this exercise, you will revoke the user certificate you created for aduser1.
http://10.0.0.50/cert/scep
4. Click OK.
FortiGate imports the CRL from FortiAuthenticator.
FORTINET
You many need to refresh the page a few times to see the status of CRL_1 as OK. Ensure it says
OK before moving on to the next procedure.
To test CRL
1. From Win-Student, double-click the FortiClient VPN on your desktop.
2. Ensure LAB VPN is selected as your VPN connection and complete the following:
aduser1
Training!
aduser1/FortiAuthCA
3. Click Connect.
4. Click Yes to the Security Alert warning.
FORTINET
This time, you will see a warning indicating that permission is denied. This is because the user
must authenticate with a valid certificate. Since it is revoked and FortiGate has the most current
CRL, the VPN can no longer trust the certificate or the user.
FORTINET
Lab 7: FSSO
In this lab, you will work through three FSSO methods:
RADIUS accounting
Manual portal authentication
DC Polling
Objectives
Exercise 1: Prepare the FortiGate and FortiAuthenticator for FSSO
Exercise 2: RADIUS accounting
Exercise 3: Manual portal authentication
Exercise 4: DC Polling
Time to Complete
Estimated: 30 minutes
FORTINET
Prerequisites
Before beginning this lab, you must restore configuration files to both FortiGate and FortiAuthenticator.
3. From your local PC (Win-Student) browse to Desktop > Resources > FortiAuthenticator > Lab7
and select FortiGate-config-to-start-LAB7.
4. Click Restore.
Since this lab includes authenticating with a second factor method through SSL VPN, it is
necessary that the VPN settings are configured on FortiGate. Since configuring VPN is out of
scope for this lab, the configuration file includes the required VPN settings.
1. Open a browser and log in to the FortiAuthenticator Web-based manager. For more information,
see To log in to the FortiAuthenticator Web-based manager.
2. Go to System > Dashboard > Status and from the System Information widget, click
Backup/Restore.
FORTINET
3. Under Restore, click Browse and browse to where you saved your backup called my-config-pre-
cert-revocation.
4. Click Restore.
5. Click OK.
FORTINET
Exercise 1: Preparing FortiGate and FortiAuthenticator
for FSSO
Before we start on each of the FSSO methods, it is a good idea to enable some FSSO features on
FortiGate and FortiAuthenticator. This includes:
Creating a Fortinet Single-Sign-On Agent (FortiGate)
Creating an FSSO user group (FortiGate)
Enabling FortiGate SSO authentication (FortiAuthenticator)
Configuring a FortiGate filter (FortiAuthenticator)
Adding the FortiAuthenticator SSO group to the FSSO Agent (FortiGate)
Name FortiAuth-SSO
FORTINET
security 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.
In this procedure you will create the FSSO user group. Later in this exercise, you will add members to
the group.
Name FortiAuth-FSSO-Group
3. Click OK.
Name FortiGate-filter
FORTINET
FortiGate name/IP 10.0.1.254 (This is the FortiGate IP)
3. Click OK.
A success message appears at the top of the screen and allows you to make further edits.
4. From the Fortinet Single Sign-On (FSSO) section, enable Forward FSSO information for
users from the following subset of users/groups/containers only.
5. Click Import.
6. From the Import Remote LDAP Objects dialog box, complete the following:
A. From the Remote LDAP server drop-down list, select ADserver (10.0.1.10) and click Apply.
B. Expand DC=trainingAD,DC=training,DC=lab.
C. Expand OU=Training.
D. Select CN = AD-users.
E. Click OK.
This configuration means that only this AD group will be pushed down to FortiGate as part of the
FSSO information feed.
7. Click OK.
FORTINET
imported into the group) to the FSSO Agent you created on FortiGate at the beginning of this exercise.
This allows FortiGate to receive a list of user groups from FortiAuthenticator (in this case, it is the
FortiAuthenticator SSO group). When you open the server, you can see the configured group and, as
all configured groups, it can be used in firewall policies.
4. Click OK. The Single Sign-On server settings should be as below (you need to hover over the blue
circle in the User/Groups column).
FORTINET
Exercise 2: RADIUS accounting
In this exercise, you will configure SSO to be based on RADIUS accounting records.
FortiAuthenticator will receive RADIUS accounting packets from the RADIUS server (which you have
already configured), collect additional group information, and then insert it into FSSO to be used by
FortiGate for firewall policies.
Once complete, you will test the configuration by logging into SSL-VPN as aduser1. The SSL VPN you
already configured sends a RADIUS Accounting Packet from FortiGate to FortiAuthenticator every
time a user successfully authenticates. The RADIUS accounting and VPN are just for generating
FSSO logging events.
Name FortiGate
Secret fortinet
4. From the RADIUS attributes section, change the Client IP attribute to Framed-IP-Address.
A. Click Browse next to Client IP attribute.
B. From the Vendor drop-down list, select Default.
C. From the Attribute ID drop-down list, select Framed-IP-Address.
D. Click OK.
The reason for this is that the firewall policy should be enabled for the User Tunnel IP and not
the public IP. When the SSL user starts the tunnel, FortiGate sends a RADIUS Accounting
Interim update that will contain the Tunnel IP in the Framed-IP-Address, as shown in the
packet capture below:
FORTINET
5. Click OK.
3. Click OK.
edit "FortiAuth-RADIUS"
FORTINET
set secret fortinet
config accounting-server
edit 1
next
end
next
end
3. Close the session.
2. Ensure LAB VPN is selected as your VPN connection and complete the following:
aduser1
Training!
aduser1/FortiAuthCA
FORTINET
3. Click Connect.
4. Click Yes if the Security Alert warning appears.
The VPN connects with aduser1's user name, password, and certificate.
Upon a successful login and tunnel start, a RADIUS Accounting packet is sent to
FortiAuthenticator. You can confirm this by running tcpdump on FortiAuthenticator (tcpdump port
1813 nnvvXS).
5. On FortiAuthenticator, go to Monitor > SSO > SSO Sessions.
You should see the SSL-VPN user, as below. The entry has both the public and the Tunnel IP,
however the public IP can be filtered out before being pushed down to FortiGate.
6. Log in to the FortiGate Web-based manager and go to User & Device > Monitor > Firewall.
FORTINET
7. From the top right corner of the page, enable Show all FSSO Logons to view the FSSO user
information.
You might see a double FSSO entry, but this can be filtered out using a rule on FortiAuthenticator
(we are not doing that as well need the subnet for the other labs).
Any FortiGate firewall policy using the FSSO User group will have this information automatically
linked with the policy.
Even though FortiAuthenticator is feeding the user information back to the same FortiGate the
SSL-VPN user connected to, imagine if this FortiGate was your customers perimeter FortiGate
and they had multiple FortiGates across their network estate. Using FortiAuthenticator and FSSO
the user information can seamlessly be populated across all FortiGates across the network with
no directory disruption whatsoever.
Remember, the RADIUS accounting packet does not just have to come from a FortiGate. In
wireless environments, the accounting packet could be from any third-party access point.
8. Open the FortiClient application and click Disconnect to disconnect your VPN session (if
FortiClient has minimized to your toolbar, click it to maximize it first).
9. Close the FortiClient application.
FORTINET
Exercise 3: Manual portal authentication
The basic premise of the login portal is that some form of re-direct will land the user on the
FortiAuthenticator login page. When used in conjunction with the FortiGate and FortiWifi solutions; an
unauthenticated user can be re-directed to authenticate on FortiAuthenticator.
The SSO portal supports multiple authentication methods including manual authentication,
embeddable widgets, and Kerberos authentication.
In this exercise, we will look at manual authentication.
FORTINET
3. In the Realms section, enable the realm-adserver default realm.
4. Click OK.
3. When the Google Chrome browser opens, log in to the FortiAuthenticator Web-based manager as
the following AD user:
Password Training!
4. Go back to the Firefox browser where you are logged in to FortiAuthenticator as admin and go
to Monitor > SSO > SSO Sessions to see the new user information.
FORTINET
FORTINET
Exercise 4: DC polling
Enabling DC polling
In this procedure, you will enable DC polling so it is available to use as a FSSO method.
To configure DC polling
1. Open a browser and log in to the FortiAuthenticator Web-based manager. For more information,
see To log in to the FortiAuthenticator Web-based manager.
2. Go to Fortinet SSO Methods > SSO > General.
3. From the Fortinet Single Sign-On (FSSO) section, enable the following options:
4. Click OK.
FORTINET
NetBIOS name TRAININGAD
This is the NetBIOS name of your domain controller.
You must use this name.
Account Administrator
This is a pre-configured user created for these labs
that can authenticate to Active Directory.
Password password
3. Click OK.
Ignore the warning prompt about DNS. It is already configured for this particular environment.
Testing DC polling
Although this environment does not include a domain client PC to test logins and logoffs, you can
experiment with the Administrator account by logging out and in of Win-Student.
To test DC polling
1. Log out of Win-Student and log back in.
2. Once logged back in, open a browser and log into the FortiAuthenticator Web-based manager. For
more information, see To log in to the FortiAuthenticator Web-based manager.
3. Go to Monitor > SSO > SSO Sessions.
You should see the Administrator account that shows DC Polling as the source.
Note: As the Win-Student server has two interfaces (one with IP address 10.0.1.10 and the other
one with 10.0.1.254) it is expected to see two entries for Administrator. Also because
FortiAuthenticator is configured to connect to the AD using LDAP through user ADadmin, it
generates a login event that is recorded by FortiAuthenticator. This is due to the lab environment.
FORTINET
Lab 9: Troubleshooting
In this lab, you will apply the RADIUS troubleshooting tips learned in the Troubleshooting lesson to
debug two RADIUS issues.
Objectives
Exercise 1: Remote users cannot authenticate
Time to Complete
Estimated: 10 minutes
Prerequisites
Before beginning this lab, you must restore the FortiAuthenticator configuration file. This configuration
will have a faulty setup and you must locate the source of the problem.
3. Under Restore, click Browse and browse to Desktop > Resources > FortiAuthenticator >
Lab9 and select FortiAuthenticator-config-troubleshooting.
4. Click Restore.
5. Click OK.
FORTINET
Exercise 1: Remote users cannot authenticate
Password Training!
Password Training!
FORTINET
Viewing the logs
Logs are generally the first thing you should check when troubleshooting a specific issue, such as
failed authentications.
Look through your logs to see if they provide any indication as to why aduser1 and aduser2 cannot
successfully authenticate.
Logs for aduser2 indicate several factors, but the first log generated indicates that the user is not
filtered by groups.
Note that you can click any log to view more details. For example:
FORTINET
Viewing the user configuration
Logs for both aduser1 and aduser2 indicate issues with the user configuration.
Look at how each user is configured, specifically use the knowledge you obtained from the logs to
pinpoint the area.
It appears aduser1 has been disabled. A disabled account would cause an authentication failure.
3. Enable the user and click OK.
FORTINET
Everything appears OK. The user is enabled, RADIUS authentication is enabled, the role is set to
User (not Administrator), and token-based authentication is not enabled.
The first log generated for aduser2 indicated "user not filtered by groups". Look at the RADIUS
client configuration to see what groups are being filtered.
3. Go Authentication > RADIUS Service > Clients. What do you see for the FortiGate client?
The default realm (realm-adserver) for the RADIUS client is set to filter on the group Firewall
Admin.
4. Go to Authentication > User Management > User Groups and check the Firewall Admin user
group configuration. What do you see?
FORTINET
It appears aduser2 is not included in the Firewall Admins group, on which the RADIUS client is
filtering. Depending on how aduser2 fits in your organization, you can add aduser2 to the Firewall
Admins group or, alternatively, create a different remote LDAP user group, add aduser2 to it, and
include that group in the RADIUS client group filter.
5. For the purposes of this lab, add aduser2 to the Firewall Admins group and click OK.
Testing authentication
Now you can try testing whether aduser1 and aduser2 can successfully authenticate.
To test authentication
1. Test to see whether aduser1 can successfully authenticate:
A. Open PuTTY on Win-Student and connect to the FORTIGATE saved session (connect over
SSH).
B. Log in as admin.
C. Type the following command:
diagnose test authserver radius <RADIUS server name> pap <ad admin
user> <password>
FORTINET
Where:
<RADIUS server name> is FortiAuth-RADIUS
<ad admin user> is aduser1
<password> is Training!
FORTINET
Appendix A: Additional Resources
Forums https://forum.fortinet.com/
FORTINET
Appendix B: Presentation Slides
FORTINET
In this lesson, we will provide an overview of FortiAuthenticator, the central device for any authentication
infrastructure.
FORTINET
After completing this lesson, you should have these practical skills that you can use to employ a
FortiAuthenticator in your network to provide secure, but controlled, network access. This includes:
Understanding authentication and the role of FortiAuthenticator
Describing the key features of FortiAuthenticator, including two-factor authentication, wireless and
wired authentication through the 802.1X standard, certificate management, captive portal guest
management, and Fortinet Single Sign-On (FSSO)
Understanding the different FortiAuthenticator models, VM licensing, product integration and support,
and firmware (version and upgrades)
Positioning FortiAuthenticator in your network, and finally
Describing the differences between FortiGate and FortiAuthenticator.
FORTINET
In the first section, we will briefly examine the concept of authentication and the role of FortiAuthenticator
in your network.
FORTINET
Authentication is the actor processof verifying the validity of a claimed identity. Confirmation of identity
is necessary in the digital world, as granting access to a resource, approving a transaction request,
trusting the validity of a document, and so on, prior to determining 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), and/or something the user has (for example, a digital
certificate or token).
FORTINET
FortiAuthenticator is a device that provides standards-based secure authentication to the entire network
infrastructure. This is to say it verifies the validity of a claimed identity. FortiAuthenticator accepts many
different user identification methods (token, digital certificate, etc.) and though different access points
(local, remote, wireless, guest, etc.).
FortiAuthenticator also centralizes the management and storage of user identity information, thereby
increasing the efficiency of administration and increasing the control over who accesses the network.
FORTINET
In this next section, we will examine some of the key features of FortiAuthenticator.
FORTINET
FortiAuthenticator is a user authentication and identity management appliance. Some of the key features
include:
Two-factor authentication
Wired/Wireless authentication using the 802. 1X standard
Certificate management
Captive portal guest management
Fortinet Single Sign-On
FORTINET
Two-factor authentication, also known as 2FA or two-step verification, 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. This reduces the possibility of data leaks while
helping companies meet audit requirements associated with government and business privacy regulations.
FortiAuthenticator supports a wide range of tokens to satisfy the requirements of two-factor authentication,
including:
OATH-compatible time-based tokens (such as the FortiToken-200)
USB certificate-based tokens (such as the FortiToken-300)
FortiToken Mobile for Android, iOS, and Windows Mobile, and
SMS and email tokens
FORTINET
FortiAuthenticator supports wired and wireless networking with the IEEE 802.1X standard. 802.1X
authentication provides an additional security barrier for your intranet. It can prevent guest, rogue, or
unmanaged computers from connecting. 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 prior to being able to send traffic over its switch port. Simply stated, 802.1X methods require
interactive entry of user credentials to prove a users identity before allowing access to the network.
FortiAuthenticator supports several 802.1X Extensible Authentication Protocol (EAP) methods, which
includes those most commonly used in WiFi networks.
Non-compliant 802.1X devices can also authenticate through MAC Authentication Bypass. In this case, the
MAC address is used as authentication.
We will explore this type of authentication further in the Wireless and wired 802.1X authentication lesson.
FORTINET
FortiAuthenticator can act as a Certificate Authority FortiAuthenticator can create, sign, and revoke
X.509 certificates.
FortiAuthenticator can act as a SCEP server FortiAuthenticator can sign user certificate signing
requests (CSRs) and distribute certificate revocation lists (CRLs) and CA certificates.
FortiAuthenticator can authenticate users against an external LDAP server FortiAuthenticator verifies
the identity of the external LDAP server by using a trusted CA certificate.
FortiAuthenticator can authenticate using Extensible Authentication Protocol FortiAuthenticator can
check that the clients certificate is signed by one of the configured (and authorized) CA certificates.
The client certificate must also match one of the user certificates.
FORTINET
FortiAuthenticator has expanded the capabilities of captive portal from credential authentication to include
social WiFi authentication and MAC address authentication.
Credential authentication allows FortiAuthenticator to authenticate known (existing) users through their
credentials.
Social WiFi authentication allows FortiAuthenticator to utilize third-party user identity methods to
authenticate users into a wireless guest network. Supported authentication methods include:
Google+, Facebook, LinkedIn, Twitter
Form-based authentication (similar to the existing self-registration feature), which include SMS- and
email-based authentication
MAC address authentication allows users to authenticate with minimal interaction from the user, but still
provides some traceability of users. The feature is useful in situations when only the identity of the user is
important. For example, wireless guest networks, retail environments, and transient access (airports,
hotels, etc.).
FORTINET
Fortinet Single Sign-on (FSSO) enables FortiAuthenticator to leverage your networks existing
authentication system for firewall authentication. Once a user logs in, they can access other network
resources without having to authenticate againauthentication is transparent.
FSSO is typically used with directory service networks such as Windows Active Directory (AD) or Novell
eDirectory. But it can also be implemented in other network environments.
FortiAuthenticator builds on the foundations of FSSO by adding more authentication methods (the
authentication methods are listed in the diagram above) and can utilize these methods in combination.
FSSO can also be used with third-party LDAP or Active Directory systems to apply group or role data to
the user and communicate with FortiGate for use in firewall policies.
FORTINET
Now that you understand what FortiAuthenticator does, lets take a look at the different types of
FortiAuthenticator models available and how the device fits into your network topology.
FORTINET
You can deploy FortiAuthenticator with either a physical hardware appliance or a virtual machine (VM).
Depending on the hardware model, the physical size, shape, and layout of the device is different.
FORTINET
On the hardware side, there are four different models of FortiAuthenticator available. Each have different
capabilities designed with flexibility and versatility in mind.
Small networks might choose the 200D. From a hardware perspective, it includes 4 gigabit Ethernet ports
(RJ-45) for connection to your network and the internet, and one 1 TB hard disk drive for local storage. It
does not include any small form-factor (SFP) interfaces.
Large organizations with multi-tenant environments, on the other hand, would require something more
robust, like the 3000D. It also includes 4 gigabit Ethernet ports (RJ-45) for connection to your network and
the internet, but it has more local storage at two 2 TB hard disk drives, as well as 2 SFP interfaces.
Its important to note the different system performance capabilities of the different hardware appliances as
well, such as the maximum number of local and remote users, FortiTokens, RADIUS clients, user groups,
Certificate Authority (CA) certificates, and user certificates.
FORTINET
Virtual machines (VMs) are different from hardware appliances in that they do not have different models,
but different images or packaged bundles. Once you have determined the appropriate VM package
each available for both 32-bit and 64-bit environments you can log into support.fortinet.com and
download it.
FORTINET
Usage limitations on your VM are imposed on the license you purchase. Different licenses allow for
different device quotas and sessions per day.
FortiAuthenticator VM licenses are stackable based on user license (i.e. user count). This stackable
licensing model allows your solution to grow as your organization grows.
FORTINET
It is important to always check the FortiAuthenticator Release Notes for specific details regarding product
integration and support information.
Each version of the FortiAuthenticator firmware supports specific Fortinet agents and firmware revisions.
Not every patch supports every Fortinet firmware version. As such, ensure you read the release notes,
available from either the Fortinet Document Library website (https://docs.fortinet.com) or on the Customer
Service & Support website (https://support.fortinet.com) in the firmware download folder, as new products
are released.
FORTINET
Periodically, Fortinet issues firmware upgrades that fix known issues, add new features and functionality,
and generally improve your FortiAuthenticator experience. As such, you should ensure your
FortiAuthenticator is running the latest firmware version. You can find the procedure in the version-specific
FortiAuthenticator Administration Guide, which is available through the Fortinet Document Library website
(https://docs.fortinet.com). There may also be important information concerning the upgrade (and possible
downgrade) in the FortiAuthenticator Release Notes.
Note that while no data loss should occur if the upgrade procedures are correctly followed, it is
recommended you perform a full backup before proceeding.
Firmware images and firmware checksums are available exclusively from the Fortinet Customer Service &
Support website (https://support.fortinet.com). Firmware checksums verify the integrity of the firmware file.
The checksum tool computes the firmware files MD5 checksum and compares it with the checksum
provided by Fortinet. If they match, the firmware image file is intact.
FORTINET
If you need to check the current firmware version that a device is using, you can do so from both the
FortiAuthenticator Web-based manager and the CLI.
On the Web-based manager, go to the Status page. The firmware version is located in the System
Information widget.
From the CLI, enter the command status to view the firmware version.
FORTINET
As far as the network topology is concerned, FortiAuthenticator can be positioned out in the cloud, on a
management LAN and/or in either an active-passive or active-active geographic load-balanced high
availability network.
Multiple FortiGate devices can use a single FortiAuthenticator for remote authentication and FortiToken
device management.
Network requirements for FortiAuthenticator configuration is discussed in further detail in the Deploying
and configuring FortiAuthenticator lesson.
FORTINET
In this section, we will examine the key differences between FortiGate and FortiAuthenticator.
FORTINET
This list contains some of the key differences between FortiGate and FortiAuthenticator in terms of
RADIUS; scale and two-factor authentication; FSSO; Active Directory; WiFi/hotspot; and Guest
management/BYOD.
FORTINET
While FortiGate does support some authentication methods, FortiAuthenticator extends those capabilities,
provides additional support, and reduces the need for administrator intervention by allowing the user to
perform their own registration and resolve their own password issues.
FORTINET
FortiAuthenticator also builds on the foundations of Fortinet Single Sign-On (FSSO), as supported by
FortiGate, by adding a greater range of user authentication methods and greater scalability.
FORTINET
We examined:
FORTINET
In this lesson, we will show you how to deploy and configure FortiAuthenticator.
FORTINET
After completing this lesson, you should have these practical skills that you can use to deploy and
configure FortiAuthenticator. This includes:
FORTINET
Before FortiAuthenticator can start authenticating users and devices, it has to be properly deployed in your
network. This involves identifying your deployment requirements, placing your FortiAuthenticator correctly
within your network, connecting the appliance, and selecting a configuration tool to manage and administer
the FortiAuthenticator.
FORTINET
As discussed in the last lesson, FortiAuthenticator has a range of different models to meet the different
authentication requirements of enterprises big and small. So when selecting your FortiAuthenticator
appliance, you need to consider your current needs and projected network growth. What sorts of things
should you consider?
In general, the FortiAuthenticator model should match the FortiGate model(s) and account for projected
growth. Remember, multiple FortiGate devices can use a single FortiAuthenticator for remote
authentication and FortiToken device management.
FORTINET
You can position FortiAuthenticator just about anywhere that you position a server or other end point
device. Administrative access operates like a FortiGate, in that you can manage FortiAuthenticator within
the local network or over the Internet (remotely). However, in the case of an emergency you need to be
able to connect to port 1, or the port labeled MGMT. As such, it is best practice to have a management
computer physically connected to FortiAuthenticator. This diagram shows a management computer
connected to FortiAuthenticator by way of a hub or switch.
FORTINET
Once youve figured out where to place your FortiAuthenticator, lets look at how to physically connect the
device.
This illustration depicts the FortiAuthenticator 1000D model, but all FortiAuthenticators include the
following basic connections:
One or more power cable connections. This 100-240V AC, 5-3A, 50-60Hz power cable connects your
device to a power outlet, or if more than one, also to a redundant swappable power supply.
Management port (serial port). This RJ-45 cable connects to the management computer and provides
access to the command line interface.
One or more Ethernet ports. This RJ-45 cable connects you to the network. This is normally connected
to a switch, but it can also be connected to another device on your network. Ethernet Port 1, or the
port labeled MGMT, is used to physically connect your management computer to FortiAuthenticator
for access to the Web-based manager. While you can access the Web-based manager remotely, it is
best practice to have a management computer directly connected in case of an emergency.
FORTINET
Once your FortiAuthenticator is connected, your need to begin with the initial configuration. There are two
tools you can use to configure the FortiAuthenticator for initial configuration: the Web-based manager
(which provides access to a graphical user interface accessed through a configured IP address) and the
CLI (which provides access to a command line interface through various connection methods).
Both tools allow you to initially configure FortiAuthenticator. However configuring DNS server addresses
can only be performed through the Web-based manager.
FORTINET
In order to log into FortiAuthenticator, you need to know the factory default settings. You can find the
default settings in your model-specific QuickStart Guide. Important to know for login is the default user
name and password as well as the port 1 IP address, netmask, and default supported management
access protocols so you can connect your management computer. Different FortiAuthenticator models
have different numbers of ports, but port 1 is the management port and will always have this default IP.
FORTINET
The Web-based manager is the graphical user interface (GUI) configuration tool for FortiAuthenticator and
is accessible both locally, by connecting directly to the FortiAuthenticator device, and remotely, based on
your configured settings (you can deny or permit access to the Web-based manager based on IP address).
The privileges an administrator has is dependant upon the administrator user role configuration, but by
default, the admin administrator has full access, which includes all permissions.
Any configuration changes made using the Web-based manager take effect immediately without resetting
the FortiAuthenticator system or interrupting service.
FORTINET
The command line interface (CLI) is the other configuration tool for FortiAuthenticator and is accessible
both locally and remotely, just like the Web-based manager. You can execute CLI commands through a
terminal emulation application onlyit is not available as a console on the dashboard of the Web-based
manager. A separate Telnet, SSH, or local console connection is required for access through a terminal
emulation application. Note that SSH is the only protocol enabled by default for CLI connections.
Again, just like the Web-based manager, the commands available to execute are based on the
administrator profile of the logged in user.
Unlike many other Fortinet products, the CLI for FortiAuthenticator is limited to initial configuration, factory
resets, and debugging. It does not have any other function outside these parameters.
FORTINET
Once connected, you are ready to configure the FortiAuthenticator network settings, which includes the IP
address and netmask, DNS servers, static routing (including the default gateway), and system time. You
should also back up your system configuration once complete and change the default administrator
password.
FORTINET
Before going over the configuration settings, it is important to discuss some recommendations for security.
Your FortiAuthenticator verifies the validity of end entities, such as users and devices, so it is important to
properly protect your data.
Deploy your FortiAuthenticator within a protected and trusted private network. It should never be
deployed directly on the outside.
Always use secure connection methods in order to do administration: HTTPS for Web-based
management or SSH for the CLI. Unsecure methods (like HTTP or telnet) are plain text, so an attacker
can use packet sniffing tools to obtain information that can then be used to breach your network.
Use trusted hosts on your users and only allow logins from specific locations. If you do need to open
outside access to the device so that remote FortiGates can connect, only open the ports necessary for
this. Additional open ports increases your security risk. If you need to open direct login access from the
outside, be sure to set up special user accounts for this and only open protocols that are secure.
Use secure passwords, as they are important if you start transmitting traffic over connections where
anyone could be listening (i.e. the Internet).
FORTINET
If using the Web-based manager to configure FortiAuthenticator, you need to connect an Ethernet cable
between FortiAuthenticator and the management computer on port 1. You also must configure the
management computer to be on the same subnet as the FortiAuthenticator port 1 interface.
To log in, open a supported browser and enter the default IP preceded by https://. At the login screen, use
the factory default administrator password to log in, which is admin in all lower case, and a blank
password.
FORTINET
If using the CLI configuration tool to configure FortiAuthenticator, use a terminal emulation application,
such as PuTTy. Due to the limited functionality of the CLI, there is no CLI Console widget in the Web-
based manager as in other Fortinet products.
From the terminal emulation application, enter the default FortiAuthenticator port 1 IP address and select a
supported management access protocol. SSH is the only protocol enabled by default.
To log into FortiAuthenticator, use the factory default for the administrator account (user name admin,
blank password).
FORTINET
Once logged in, you must configure the interface, the primary and secondary DNS server IP addresses,
static routing (which includes the default gateway), and system time. The Web-based manager will be
used in this lesson for the sake of simplicity.
All initial configuration tasks are performed from the same area of the Web-based manager: System >
Network.
There are some requirements for your network during configuration. At minimum, you must ensure specific
ports are open in the security policies between the RADIUS authentication clients and FortiAuthenticator.
FORTINET
You can configure the interface network settings from the Interfaces page. This includes setting an IP
address and netmask, as well as supported administrative access and system protocols.
You must edit the default IP and netmask associated with the port 1/MGMT interface based on your own
network. This provides more security than using the default 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.
Administrative 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 Web-based manager
access, or SSH for CLI access. HTTPS and SSH are enabled on FortiAuthenticator by default.
Finally, you must select the services you want to allow. These are tied to the functionally you want to
employ and several are already enabled by default. Many of these services will be discussed throughout
the training.
FORTINET
DNS, or Domain Name System, ensures human-friendly hostnames are translated into IP addressesit
resolves hostnames. Certain FortiAuthenticator functionalities rely on the use of DNS. For example, any
feature that requires sending notification emails to users or administrators. As such, FortiAuthenticator
must have a reliable and stable connection to a DNS server.
You an configure DNS from 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 to something else.
Note that in an Active Directory (AD) environment and using AD authentication, the DNS servers should be
the Domain DNS Servers.
FORTINET
You can configure the default gateway associated with the interface from 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 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 and mask, the gateway, and the interface
(port).
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 a NTP (Network Time Protocol) server.
NTP is a standard protocol for clock synchronization. Synchronization with a NTP server is highly
recommended, as 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 from the System Information widget. Click Change in the System Time
field, select NTP enabled, and enter the address of the NTP server. By default, the Fortinet NTP servers
are used (ntp1.fortinet.net).
FORTINET
Once you complete your FortiAuthenticator deployment, you should back it up to your management
computer as a best practice. You can perform a backup directly within the Web-based manager through
the System Information widget.
The backup includes both the CLI and Web-based manager device configurations. It also includes
information on users, user groups, FortiToken device list, authentication client list, LDAP directory tree,
FSSO settings, remote LDAP, and certificates.The backup file is encrypted to prevent tampering. Multiple
backups can exist from different points in time. Make sure you choose an appropriate file name to indicate
the point in time of the backup.
If changes are made to the FortiAuthenticator device that end up negatively affecting your network, you
can also restore the configuration from any of the backups you performed.
Note that you can only restore to the same build version.
FORTINET
One of the first administration tasks you should perform is changing the default administrator password.
Password complexity is enabled by default, so your new password must be 8 characters in length. Ensure
you select a secure password.
Note that you can also change the way you authenticate to FortiAuthenticator from the users account
page. For example, instead of password-based authentication, you can use token-based or RADIUS
authentication. But unless you have already configured FortiAuthenticator for these authentication
methods, the most important step is to just change the default blank password initially for security
purposes. We will discuss configuring these authentication methods and changing the way a user
authenticates in the Administrating and authenticating users lesson.
FORTINET
Finally, this is just a helpful diagram that shows all the FortiAuthenticator ports. It is a useful reference as
you configure your FortiAuthenticator.
FORTINET
In order to efficiently manage your networks authentication requirements through FortiAuthenticator, you
can create administrative usersassigning each one to manage one or more tasks. To divide
responsibilities, FortiAuthenticator employs the concept of administration profiles. Essentially these profiles
say which actions are allowed and not allowed on each administrative account.
FORTINET
Unlike FortiGate, FortiAuthenticator includes no administrator profiles by default. However, the ingredients
to create administrative profilesthe permission sets and individual permissionsdo exist.
An administrator profile is comprised of one of more permission sets. A permission set, in turn, is
comprised of individual permissions. For example, the Certificate Management permission set in the
screenshot includes the individual permissions within the Selected user permissions box (lower box).
Note that the default permission sets are fully customizableyou can add or remove individual
permissions associated with all permission sets.
Administrative profiles are useful for dividing responsibilities and controlling administrative access. For
example, an administrative user who has only been granted the Certificate Management permission set
will not be able to add or delete local users, as 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.
FORTINET
You can create administrator profiles from 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, or
should have read and write access to that permission set, by selecting Read & Write next to the
permission set.
FORTINET
Once you click Manage, the full list of built-in permission sets appears.
Permission sets are not static. You can add or remove individual permissions from any permission set.
Over the next few slides, well look at how to modify a built-in permission set and create a new, custom
one.
FORTINET
To modify an existing permission set, click the permission set you want to modify. You are then presented
with a page that shows you what permissions are currently associated with that permission set (these are
located in the Selected user permissions lower box), and what permissions are available to use (these
are located in the Available user permissions upper box). You can add or remove permissions between
these two boxes with the arrow buttons.
FORTINET
If you would rather create a new permission set than modify an exist one, click Create New. Provide your
new permission set with a name and then add individual permissions from the Available user
permissions box (upper box) to the Selected user permissions box (lower box).
You can continue to add or remove permissions at any time. Just ensure the name or description aptly
identifies the permission set after modification.
FORTINET
Once you have some administrator profiles, you can create administrative user accounts and assign a
profile. You can create an administrative user account through the Local users page by clicking Create
New. You must set a user name and a password.
There are three ways to handle the password. You can specify a password and communicate it to the
administrative user, have FortiAuthenticator create a random password and automatically email it to the
administrative user (you must assign an email to the user), or specify token-based authentication rather
than password-based authentication. With the last option, the account is added, but is disabled until you
associate a FortiToken to the user account. We will examine FortiTokens further in the Two-factor
authentication lesson.
FORTINET
Under the Role section of the same page, select Administrator to make the user an administrative user.
As you can see, administrative accounts on FortiAuthenticator are standard user accounts (local or remote
users) flagged as administrators. We will discuss creating end users in the next 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 pre-configured
administrator profile from the Admin profiles field.
FORTINET
Once you add the administrator user account, you are presented with additional account settings that you
can configure, such as:
Web service access, which allows administrators to access the web services via a REST API or a client
application.
Restrict admin login from trusted management subnets only, which allows you to restrict
administrator access to the Web-based manager 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 ten trusted hosts.
You can also expand each of the sections illustrated in the above screenshot 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 pre-arranged security question. The
user must then set a new password.
FORTINET
Now that you have deployed and configured the most fundamental areas of FortiAuthenticator, you can
begin to configure the administration settings. While this section does not cover all settings available, it
aims to identify those most typically configured. This includes:
Modifying the Web-based manager idle time-out setting
Enabling a high availability cluster
Configuring automatic backups
Configuring FTP servers
Configuring SNMP
FORTINET
By default, the idle-time out setting for the Web-based manager is 5 minutes. This is for safety purposes,
as short idle timeout periods lower potential security breaches. However, during configuration, you may
wish to increase the idle time-out period to avoid re-authenticating every 5 minutes. You can change the
default through the GUI Access page. The configurable range is between 1 and 480 minutes.
FORTINET
If your deployment has more than one FortiAuthenticator device, you can choose to operate the
FortiAuthenticator devices as a high availability (HA) cluster to provide even higher reliability. Both devices
must run the same firmware version.
active/passive mode (Cluster member in the Web-based manager). With this mode, everything is
synced and is failover only.
active/active mode (Geo-HA). Geo load balanced HA (Standalone master/load balancing slave in the
Web-based manager) is a configuration sync only method and syncs just the user authentication
configuration (such as users, groups, tokens, etc.). It does not sync FSSO and certificates.
FORTINET
You can enable high availability (HA) through 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. If the
active device fails, the standby becomes active. The cluster is configured as a single authentication
server on the FortiGate. Authentication requests made during a failover from one device to another are
lost, but subsequent requests complete normally. The failover process takes approximately 10
seconds.
Standalone master (primary member): The standalone master is the primary system where users,
groups, and tokens are configured. The load-balancing slave is synchronized to the master. To improve
the resilience of the primary system, an active-passive cluster with up to two load-balancing slave
devices can be configured.
Load-balancing slave (secondary member): The load-balancing HA method enables active-active HA
across geographically separated locations and layer 3 networks.
FORTINET
Previously in this lesson, we discussed manually backing up your system after configuration changes.
However, FortiAuthenticator also provides the ability to schedule automatic system backups. You can
enable auto-backups from the Config Auto-backup page.
From this page, you can select a frequencyhourly, daily, weekly, or monthlyin which you want
FortiAuthenticator to back up your system, as well as the backup time for that frequency. You can also
specify the FTP directory and select the FTP server (both primary and secondary) in which to store the
backup configuration file. Note that the FTP server(s) must first be pre-configured.
FORTINET
File Transfer Protocol (FTP) is a standard network protocol used to transfer files from one computer to
another over a TCP-based network, such as the Internet.
You can configure your FTP server(s) through the FTP Servers page by clicking Create New. Aside from
assigning a name and providing the IP and port of the FTP server, you can elect to use a secure FTP
(SFTP) connection. The default port to SFTP is 22.
You can also configure your FTP server to allow anonymous access to FTP resources by selecting
Anonymous. This means all requests for that resource are accepted without prompting the user for a user
name or password.
If you are not allowing anonymous access, you must provide a user name and password to your FTP
server.
FORTINET
Simple Network Management Protocol (SNMP) enables 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 out SNMP queries to the SNMP agents.
By 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 will not
receive any traps from that device, or be able to query that device.
Note that the FortiAuthenticator SNMP implementation is read-only. SNMP v1, v2c, and v3 compliant
SNMP managers have read-only access to system information through queries and can receive trap
messages from FortiAuthenticator.
FORTINET
You can configure SNMP through 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:
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 Management Information Base (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 from the
SNMP page in the Web-based manager or from the Customer Service & Support portal at
https://support.fortinet.com. They are located in the Firmware Images folder for the FortiAuthenticator
product.
FORTINET
In this section, we will examine the FortiAuthenticator messaging settings. FortiAuthenticator sends email
for several purposes, such as password reset requests, new user approvals, user self-registration, and
two-factor authentication.
FORTINET
By default, FortiAuthenticator uses the built-in Simple Mail Transfer Protocol (SMTP) server. This is
provided for convenience, but is not necessarily optimal for production environments. Anti-spam methods
can cause mail to be blocked, so it is highly recommended that email is relayed through an official,
external mail server for your domain.
To configure a new SMTP server, you require a name, server IP, 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 servers certificate for STARTTLS to work.
We will examine CA certificates in the Certificate management lesson.
Lastly, if the email server requires that you authenticate when sending mail, you can enable authentication
and set the account user name and password.
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 from the drop-down
list.
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.
FORTINET
It is important to monitor your FortiAuthenticator device. This can be done through the Web-based
manager dashboard.
FORTINET
In order to better manage your network through FortiAuthenticator and get a centralized summary of your
system information and snapshot of your system resources, use the Dashboard in the Web-based
manager.
You can find the dashboard under the Status page. The dashboard is comprised of various widgets, such
as:
System information
License information
HA status
Disk monitor
System resources
User inventory
Authentication activity
Top user lockouts
FORTINET
Just like FortiGate, you can disable any widgets you find unnecessary for your particular management
requirements, enable any previously disabled widgets, rearrange the position of the widgets on the page
by dragging and dropping individual widgets, and adjust the internal parameters of specific widgets.
FORTINET
If HA is configured, you can view the status through the HA Status page. This provides the current status,
including the node type (for example, Cluster member, Standalone master, or Load-balancing Slave), the
priority (high or low), the serial number, and the status.
FORTINET
After this lesson, you should be able to deploy and initially configure FortiAuthenticator as well as
configure the system based on your networking requirements.
FORTINET
In this lesson, we will examine 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.
FORTINET
After completing this lesson, you should have these practical skills that you can use to administer and
authenticate users, including:
Configuring user account policies, such as lockout policy settings, password policy settings, and
custom user fields
Configuring user management settings, such as user groups and organizations
Configuring LDAP and RADIUS service, and
Configuring remote authentication servers (LDAP and RADIUS)
FORTINET
It also includes:
FORTINET
Prior to creating users, you may want to pre-configure some of the user account policies. While it is not
necessary to configure the policies prior to creating user accounts, it does make the process of creating
user accounts more seamless. These settings apply to both users and administrative users.
FORTINET
Under the General page, you can configure some user account settings. You can:
Automatically purge disabled user accounts at a scheduled time (for example, weekly at 2am) and
purge users that were disabled for any of the following reasons: they were manually disabled, they
were inactive, or their account expired.
Restrict Web service access to a specific interface
Discard stale RADIUS authentication requests
FORTINET
FortiAuthenticator allows you to lock a users account after repeated unsuccessful attempts to log in, as it
may indicate an attempt at unauthorized access. You can configure the lockout policy settings from the
Lockouts page by selecting the 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. Attempts between 3 and 5 are
generally 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 (i.e. users are locked out for 60 seconds after 3 failed login attempts), but you can set it to
between 60 and 86,400 seconds. If you disable this setting, locked out users are permanently disabled
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 days a user account can be inactive before being locked
out. The inactive user lockout period must be between 1 and 1825 days.
FORTINET
You can monitor your top locked out users from the dashboard, via the Top User Lockouts widget.
You can view currently locked out users through the Locked-out Users page.
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 from the Passwords page.
FORTINET
FortiAuthenticator allows you to create custom fields that can be used to gather user information not
represented by the default fields.
You can configure the custom fields from the Custom User Fields page. Click Edit associated with the
custom field and enter your custom field in the text box that appears.
FORTINET
Lets briefly examine some of the user management settings on FortiAuthenticator, which allow you to
better manage your users. These include user groups and organizations.
FORTINET
FortiAuthenticator allows administrators to assign users to groups. Generally, groups are used to more
effectively manage individuals that have some kind of shared relationship. You might want to group
employees by business area, such as Finance or HR, or by employee type, such as contractors or guests.
You can add both local and remote users to a group. Note that if you select a remote user, the remote
server must first be configured.
As for the order of operations, you can create a user and assign them to a pre-existing group or you can
create a group and assign it to a pre-existing user.
FORTINET
FortiAuthenticator allows administrators to create an organization and associate that organization with both
local and remote users. An organization consists of a name and logo. You can configure organizations
from the Organization page.
This is useful when a user provisions FortiToken Mobile on their device, as the organization name and
logo you assign to the users account is automatically pushed to the device, thereby allowing you to
rebrand the FortiToken mobile app user interface.
FORTINET
If you already have LDAP or RADIUS servers configured on your network, FortiAuthenticator can connect
to them for remote authentication, much like FortiOS remote authentication.
In this section, we will examine how to configure both an LDAP and RADIUS remote authentication server.
FORTINET
You can configure FortiAuthenticator to connect to a remote LDAP server through 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 as well.
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 users password, which is sent to the server in plaintext without a search, or
Regular, to bind using the users dn and password and then perform a search. Regular bind is required
if searching for a user across multiple domains.
If you want to have a secure connection between FortiAuthenticator and the remote LDAP server, enable
the Secure Connection option and include the LDAP server protocol (LDAPS or STARTTLS) as well as
the CA certificate that verifies the server certificate.
If you want to authenticate users in an Active Directory environment, enable the Windows Active
Directory Domain Authentication option 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 particular groups that you select. We
will talk about RADIUS clients in the next section.
FORTINET
You can configure FortiAuthenticator to connect to a remote RADIUS server from the RADIUS page. This
feature can also be used to migrate away from third-party two-factor authentication platforms.
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 as well.
If you want to record and learn what users are authenticating against this RADIUS server, enable the
Enable learning mode option from the User Migration section. You should enable this option if you need
to migrate users from the server to FortiAuthenticator.
FORTINET
In this section, we will examine FortiAuthenticators RADIUS service, which includes clients and realms.
Each local user account on FortiAuthenticator has an option to authenticate using the RADIUS database.
Note that if using the RADIUS service, the network interface must have the RADIUS service(s) enabled
(System > Network > Interfaces).
FORTINET
Before getting into the specifics about the RADIUS service on FortiAuthenticator, lets quickly review what
RADIUS is. RADIUS is a standard protocol that provides authentication, authorization, and accounting
(AAA) services.
When a user is authenticating, the client (eg. FortiGate) sends an Access-Request packet to the RADIUS
server (eg. FortiAuthenticator). The reply from the server will be one of the following:
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 through the Clients page. FortiAuthenticator sends answers only to the
RADIUS clients in 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.
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) authentication server on 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.
FORTINET
The connection between RADIUS servers, clients, and realms can be difficult to wrap your head around.
This diagram attempts to visually represent the relationship. It illustrates that the RADIUS client points to
FortiAuthenticator and FortiAuthenticator authenticates externally.
FORTINET
In this section, we will examine FortiAuthenticators LDAP service. FortiAuthenticator includes its own built-
in LDAP server in which you can add local and remote LDAP and RADIUS users.
Note that if using the LDAP service, the network interface must have the LDAP service enabled (System >
Network > Interfaces).
FORTINET
When you configure the LDAP service on FortiAuthenticator, you must specify the LDAP server certificate
settings through the General page. This includes configuring:
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=example,dc=com, and there can only be
one. Everything else in your directory branches off the root dn. Choose a dn that makes sense for your
organization.
Subordinate objects are placed 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 this example, 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.
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.
The FortiGate device (acting as an LDAP client) requesting authentication must be configured to address
its request to the right part of the hierarchy where user records exist. This is the Distinguished Name (dn).
In this example, the dn is ou=people,dc=example,dc=com.
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), as 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-quotes. For example: cn=John Smith.
FORTINET
You must add user entries at the appropriate place in the LDAP tree. Using our previous example, this
would be under ou=people. Select the Class as Local User (uid) and move the users that appear in the
Available Users box (left) to the Chosen Users box (right). The users must already be defined in the
FortiAuthenticator user database.
FORTINET
Once you have defined the LDAP tree, you can configure FortiGate to access FortiAuthenticator as an
LDAP server and authenticate users.
On your FortiGate device, go to User & Device > Authentication > LDAP Server and create a new LDAP
server with the FortiAuthenticator LDAP server information.
FORTINET
Once you have configured user account options, user management settings, the LDAP and/or RADIUS
service, and are connected to any existing remote authentication servers, you can more readily create
user accounts.
FortiAuthenticator includes two different types of users: local users and remote LDAP/RADIUS users.
FORTINET
There are two ways you can add local users to FortiAuthenticator:
Import users from a comma-separated value (CSV) file or FortiGate configuration file
Manually add users
Note that FortiAuthenticator does include a self-service portal whereby users can register themselves.
Self-registration is covered later in this lesson.
FORTINET
You can import local user accounts from a CSV file or a FortiGate configuration file from the Local Users
page.
If importing from a CSV file, the file must contain only one record per line in the accepted format (format is
available in the FortiAuthenticator Administration Guide). If you do not include the optional password in the
record, the user is emailed temporary login credentials and requested to configure a new password.
If importing from a FortiGate configuration file, you are presented with the following options:
Import users only
Import users and only their associated FortiToken 200
Import all users and FortiToken 200 (this option imports unassigned FortiTokens as well)
You must also enter the password associated with the FortiGate configuration file when importing, if one is
assigned.
FORTINET
The other way you can add local users is by manually creating them. This is done through the same Local
Users page by clicking Create New.
First, you must set a user name (253 characters or less and can only include letters, digits, and select
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. With 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. With this option, the account is added, but is disabled until you associate a
FortiToken to the user account. We will examine FortiTokens further in the Two-factor authentication
lesson.
Allow RADIUS authentication: Allows a locally created user to authenticate through RADIUS.
FORTINET
Once the user name and password is set, you must assign a user role. You can select Administrator to
create an administrator account or User to create a user account. Since we discussed creating
administrative users in the last lesson, this section will focus on creating end users. To create an end user,
select User as the role.
Once you select the user role, you are presented with the option of enabling 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.
FORTINET
Once you add the local user account, you are presented with additional account settings that you can
configure.
Similar to administrative 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.
Allow LDAP browsing. This allows viewing of directory contents (i.e. 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. We will talk about RADIUS attributes in more detail in the next slide.
Certificate Bindings. This allows you bind a local certificate to a users account.
FORTINET
As mentioned, some RADIUS clients can receive information about the users through vendor-specific
RADIUS attributes. When a RADIUS user successfully authenticates, FortiAuthenticator sends the users
RADIUS attributes and values to the RADIUS client.
For example, there is a Fortinet proprietary attribute called Fortinet-Client-IP-Address. It specifies the
virtual IP address assigned to that specific user when establishing a SSL VPN tunnel. So, we can
configure FortiAuthenticator and FortiGate to always assign the same static IP address to a user. The IP
addresses are stored in FortiAuthenticator as part of the user account information and are sent to
FortiGate when the user has successfully authenticated.
You can configure RADIUS attributes through the Remote Users page.
FORTINET
RADIUS attributes can also be configured per user group through the User Groups page.
FORTINET
Now that weve looked at creating local users, lets look at the other type of user you can add in
FortiAuthenticator: remote users. Remote users include both remote LDAP and RADIUS users.
FORTINET
Remote LDAP and remote RADIUS users are added to FortiAuthenticator differently.
For remote LDAP users, you must import users into the FortiAuthenticator user database from their remote
LDAP servers.
For remote RADIUS users, you can create them based on a remote RADIUS server. Remote RADIUS
users can be migrated to LDAP users, edited, and deleted. They can also be flagged with the user role or
administrator role.
FORTINET
You can import remote LDAP users through the Remote Users page. Ensure LDAP users is selected in
the top right corner and click Import.
You need to select a pre-configured remote LDAP server and then either import users or import users by
group membership.
Once FortiAuthenticator connects to your pre-configured LDAP server, you can see your remote users
based on the default LDAP filter (&(objectClass=user)(objectCategory=person)). The default configuration
imports the attributes commonly associated with Microsoft Active Directory LDAP implementations. You
can 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.
FORTINET
FortiAuthenticator also allows you to create synchronization rules to control how and when remote LDAP
users are synchronized. You can do this from the Remote User Sync Rules page.
select the pre-configured remote LDAP server from where users will be synced
specify how often the sync should be performed (for example, every <x> minutes, every <x> hours or
every <x> days).
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 or local users.
FORTINET
You can create remote RADIUS users through the Remote Users page. Ensure RADIUS users is
selected in the top right corner and click Create New.
You need to select a pre-configured remote RADIUS server and create a user name for the remote
RADIUS user. You can specify the type of authentication and select the user role to assign to the account,
either administrator or user.
Once created, you have the option to perform the following functions to one or more accounts
simultaneously:
Re-enable user accounts in the event they are disabled.
Migrate RADIUS users to LDAP users.
Set whether token-based authentication should be enforced (if configured) or whether it should be
bypassed.
You also have the option to edit or delete any remote RADIUS user account.
FORTINET
To migrate RADIUS users to LDAP users, select the user and click Migrate. You must specify the LDAP
server (pre-configured) and then configure the LDAP user mapping by specifying a distinguished name.
RADIUS users are removed once they are successfully migrated to LDAP users.
FORTINET
If you want to ease the administrative burden from the administrator, specifically in terms of adding new
end users to FortiAuthenticator, you can configure the self-service portal. This allows users to self-register.
This section examines configuring the self-service portal and provides an example of the user self-
registration process.
FORTINET
In order to allow users to self-register, you first need to configure the self-service portal. The portal is what
users must access in order to complete various self-service tasks. You can configure the general settings
of the portal from the General page. This includes:
Default portal language: This is the language used in the portal. There are several languages
included by default, which you can select from the drop-down list. However, a translation pack can be
obtained from Fortinet support if you need to translate to your local language.
Site name: This is the name that will be used when referring to your portal. If left blank, the default
name will be the DNS domain name or IP address of the site.
Email signature: This is the signature that will be appended to the end of outgoing email messages.
For example, the email that goes to users when they self-register.
FORTINET
From the Access Control page, you can configure what users or groups can access the network. You
must specify:
FORTINET
To enable users to request registration through the FortiAuthenticator login page, you must enable self-
registration through the Self-registration page.
Once enabled, you are presented with various 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 users mobile number as their user name
Place users into 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). If administrator approval is not
required, you have the option to display the account information on the browser page.
Set the SMS gateway
From 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, email address). This can include
any custom user fields you created as well.
FORTINET
Replacement messages are customized messages sent to users upon self-registration. You can view and
customize the default messages through the Replacement Messages page. This may be required based
on your self-service configuration. For example, on the previous slide we discussed that administrators can
specify which information-gathering fields they want to display to the user when they self-register. The
default self-registration message may include fields asking for information you didnt 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
back to the default message if required.
From this page, you can also manage any images you want to include in the message. For example, your
company logo or images containing links to your companys social media pages.
FORTINET
Device self-enrollment is a method for local and remote users 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 from the Device Self-enrollment page. You must:
Select a pre-configured SCEP enrollment template (this will be discussed further in the Certificate
Management lesson)
Set a limit on the maximum number of devices that a user can self-enroll, and
Select the key size for self-enrolled certificates (1024, 2048, or 4096 bits). Note that iOS only supports
1024 and 2048.
You also have the option to enable self-enrollment for smart card certificates. This requires the device
FQDN to be configured, as it is used in the CRL Distribution Points certificate extension.
FORTINET
Step 1: A user must connect HTTP or HTTPS to the FortiAuthenticator Web-based manager. 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, and email to name a few. 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: Once 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, via the browser page. If FortiAuthenticator has
been configured to use randomly generated passwords, the email/SMS confirmation will contain the user
password.
FORTINET
FORTINET
In this lesson, we will examine how to use the guest management feature through captive portal, with a
focus on social WiFi as an authentication method (new feature for FortiAuthenticator 4.0). This lesson
explains how to configure your FortiGate and FortiAuthenticator for each supported social portal and how
a guest user can access your WiFi network without the need to register.
FORTINET
After completing this lesson, you should have these practical skills that you can use to configure guest
management through captive portal, specifically, social WiFi authentication.
This includes:
Understanding the guest management feature, including the three authentication options available
Configuring the supported social channels, including Facebook, Google+, LinkedIn, and Twitter
Configuring FortiAuthenticator captive portal settings
Configuring FortiGate captive portal settings, and
Managing users, such as how to monitor users who authenticate through the social portal and how to
manually de-authenticate users should you no longer wish to grant them access to your network
FORTINET
In this section, we will examine what captive portal is, under what circumstances your organization may
want to employ it, and what portals are available to configure.
FORTINET
Captive portal 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 users web browser to one of FortiAuthenticators
captive portals. As such, you have to configure FortiGate (on a per-FortiGate basis) to employ captive
portal on FortiAuthenticator.
FORTINET
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
pre-authorized 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 goal is to provide the most simple
experience for the user as possible (i.e. wireless guest networks, retail environments, transient access
such as airports, hotels, etc.).
FORTINET
FortiAuthenticator allows you to authenticate users through social networks, such as Facebook, Google+,
Twitter, and LinkedIn. In this way, when the user connects to your WiFi network, the user is redirected to a
splash page where they can select the social channel in which they would like to authenticate.
For social WiFi, each authentication method requires the administrator to sign up to the social media
website as a developer. Once signed up and logged in, you must configure the social network to allow
communication with FortiAuthenticator.
In this section, we will examine the configurations for Facebook, Google+, LinkedIn, and Twitter.
FORTINET
Whatever supported social channel you choose to configure, all social providers follow a similar process
flow:
FORTINET
To use Facebook as a social WiFi authentication method, you must configure Facebook. This involves the
following:
FORTINET
5. Go to the Facebook Developer Settings page for your app and obtain your App ID and App Secret.
These are required for the FortiAuthenticator configuration.
6. Go to the Status & Review page and activate your app. This will make all the features live and available
to all users (note that you must provide a contact email before you can activate).
There are many other advanced configurations offered by Facebook under the Advanced tab for your app,
but these are outside the scope of this training, and are not essential to configuring Facebook
authentication for FortiAuthenticator.
FORTINET
To use Google+ as a social WiFi authentication method, you must configure Google+. This involves the
following:
1. Log in to your Google+ account and navigate to the Google developer site.
2. Create a new project and give it a name.
3. Add the OAuth 2.0 client ID as your API and authentication credential.
FORTINET
4. Configure the consent screen. The consent screen is shown to users whenever you request access to
their private data using your OAuth client ID. At minimum, you must set a product name, but you can also
add your company logo, your privacy policy URL, terms of service URL, and more.
5. Create the client ID. This includes setting the Application type to Web application, entering the
FortiAuthenticator FQDN as the Authorized JavaScript origins, and entering the Authorized redirect
URL (https://<FAC_FQDN>/social/complete/google-oauth2/) .
FORTINET
7. Enable the API (APIs & auth > APIs. From Social APIs, click Google+ API and then Enable API).
FORTINET
To use LinkedIn as a social WiFi authentication method, you must configure LinkedIn. This involves the
following:
1. Log in to your LinkedIn account and navigate to the LinkedIn developer site.
2. Select Create Application.
3. Enter a name, description, and website for the application.
4. Enter the new application's information, including an appropriate application logo URL to be displayed
on the LinkedIn user login screen.
FORTINET
FORTINET
And finally, to use Twitter as a social WiFi authentication method, you must configure Twitter. This involves
the following:
3. Enter a name, description, and Website for the application. In Callback URL, enter:
https://<FAC_FQDN>/social/complete/twitter/
FORTINET
4. Accept the developer agreement and click Create your Twitter Application.
5. Go to Keys and Access Tokens to view your consumer key and consumer secret.
FORTINET
The social WiFi authentication process from the users perspective is as follows:
1. User connects to your WiFi network when trying to access a URL and is presented with the
FortiAuthenticator Social WiFi splash page.
2. User selects an authentication method from the social channels offered. If a social channel is not
configured, it appears greyed out (disabled) and the user is unable to select it.
3. User is prompted to enter credentials for the social channel selected.
4. User is redirected to URL they originally requested.
Note that the splash page shows an option called Form. As mentioned earlier, the social portal allows
users to authenticate through social channels or by email/SMS (if configured). This is known as form-
based authentication and is configured through FortiAuthenticator. We will discuss this in the next section.
FORTINET
Once the social developer accounts you plan to use are configured, you need to enable and configure the
FortiAuthenticator captive portal settings. In this section, we will examine the configurations required for
FortiAuthenticator.
FORTINET
While not required, you may wish to create a user group for social logon users. This way, any users that
log into any of the social portals can be placed into this group. You can create a group from the User
Groups page. There is no need to select users to add to the group, as this is done dynamically on a
successful authentication.
You can only add users into groups that log in through the social or MAC address portals.
FORTINET
Before you can enable captive portal, you must create a RADIUS client. This is done through the Clients
page and was discussed in the previous lesson. The RADIUS client is necessary so that FortiAuthenticator
can accept RADIUS authentication requests from FortiGate (FortiGate becomes registered as an
authentication client).
Once you have a RADIUS client, you can enable a portal by selecting Credentials portal, Social portal,
and/or MAC address portal. You must also create an authentication profile. For example, for the social
portal, you would set Authentication method to Password-only authentication (excludes users
without a password) and Realms to local | Local users.
While it may not be immediately intuitive to set Realm to local for social WiFi users, this is because a
temporary user is created in the local database following successful social authentication.
FORTINET
Once the RADIUS client is configured and (optionally) a user group, you are ready to configure captive
portal on FortiAuthenticator.
When you have enabled captive portal, you have the flexibility to configure each captive portal type
(credentials, social, and MAC address) separately. Once enabled, the portal provides additional
configuration options. This is where you would add your social portal user group (social and MAC portal
only).
FORTINET
Here is an example of the credentials portal configuration on the General page. Because those who
authenticate through this portal are only known users with pre-existing login credentials such as a
password or token, there is not much involved with the configuration. To configure, enable the credentials
portal, and optionally the disclaimer. The disclaimer page is fully customizable and will be discussed later.
Note that the required URL for this portal is provided on this page: <URL>/caplogin/
When the user connects to your WiFi network, the user is prompted to enter their credentials, such as a
password or token. Once authenticated, the user is granted access to the Web site they were originally
trying to access.
FORTINET
Here is an example of the social portal configuration on the General page. As you can see, the social
portal is enabled, accounts expire after 1 hour, users that authenticate through the social portal are placed
into a pre-configured group called Social_Users, and the Facebook login is enabled. As mentioned, the
Facebook key and Facebook secret are needed. These are provided to you when you configure the
Website app from your Facebook developers account. If you enable Google, Twitter, or LinkedIn, you
would need the key and secret for each as well. You can also enable the disclaimer page, which is fully
customizable.
FortiAuthenticator also allows you to configure SMS and email configuration within the social portal. This is
known as form-based authentication. To enable, select Enable SMS self-registration and/or Enable e-
mail self-registration.
When the user connects to your WiFi network, the user is redirected to the splash page where they can
select one of the configured social logins, such as Facebook or Google+, or Form, for form-based
authentication. With form-based authentication, the user is presented with a form where they must enter
their first and last name, and the verification method (SMS and/or email, depending on what you
configured). The user is then presented with a verification code through their chosen verification method.
Once authenticated either through the social login or form, the user is granted access to the Web site they
were originally trying to access.
Note that the required URL for this portal is provided on this page: <URL>/social_login/
FORTINET
Here is an example of the MAC address configuration on the General page. As you can see, you can
enable a disclaimer page (customizable), set the account to expire after a set period of time, and place the
registered users into a pre-configured group.
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). The user is then redirected to the webpage
originally requested.
FORTINET
Just like the customizable replacement messages used for the self-service portal (see the Administering
and authenticating users lesson), captive portal employs the use of customizable replacement messages
as well. An example is the disclaimer page that you can enable on all three social portal authentication
methods.
FORTINET
An easy way to view which captive portal is associated with which RADIUS client is through the Access
Control page. This page provides a consolidated view of your current setup and allows you to configure
the control settings.
FORTINET
In order to allow redirection to an external captive portal as well as the identifying information about the
requesting IP, some FortiGate configuration is required. FortiGate configuration is done on a per-device
basis.
This section examines how to configure FortiGate for the social portal.
FORTINET
In order to authenticate social users onto the FortiGate network, you must configure FortiAuthenticator as
a RADIUS server on FortiGate (RADIUS Servers page). This may sound counter-intuitive, as the
authentication takes place with 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 via RADIUS.
To configure FortiAuthenticator as a RADIUS server, you must enter the FortiAuthenticator IP and secret.
FORTINET
A firewall user group for RADIUS users allows FortiGate to check a users credentials against the user
group. The authentication user group is required, as it used to validate the user credentials as part of the
captive portal login process.
You can create a new group for your social users through 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.
FORTINET
In order to activate the social portal for those accessing your network wirelessly, you need to configure the
WiFi security mode for captive portal on FortiGate.
You can configure WiFi security mode through the SSID page on FortiGate. Select Captive Portal as the
security mode, Authentication as the portal type, External as the authentication portal, and add the
address for captive portal login (URL/social_login).
Additionally, set User Groups to your social group as discussed on the previous slide.
FORTINET
Now you are ready to enable captive portal as the security mode on FortiGate as well as specify the
authentication protocol you are configuring.
On a physical (wired) network interface, you can enable captive portal from 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 each captive portal are as follows:
And finally, from the User Groups drop-down, select your pre-configured firewall group for social users.
For WiFi, a WiFi interface does not exist until you create the WiFi SSID. Once created, you can then
enable captive portal by editing the WiFi network interface in System > Network > Interfaces or as
discussed on the previous slide, through WiFi Controller > WiFi Network > SSID.
FORTINET
To allow the user to authenticate to the social network sites before they are allowed to browse to the wider
Internet, some exemptions are required.
The recommendation is to add the exemptions over the CLI. As you can see in any of the attachments, the
exemptions are numerous, so it is a time consuming process to configure over the Web-based manager.
FORTINET
To allow traffic to flow to the FortiAuthenticator portal to enable authentication when the user is not yet
authenticated, you need to configure the FortiAuthenticator address group to use as an exemption rule in
the firewall policy.
This group may also include any servers used to host images referenced on the FortiAuthenticator portal.
In this case, set an IP range during configuration instead of a single IP address.
To create a FortiAuthenticator address group, you can use the CLI command noted in this slide, or use the
Web-based manager (Policy & Objects > Objects > Addresses). Once the group is created, you can
add the exempt rules that appear in the attachments on this slide to the address group.
Note that the address group will need to consist of the Facebook, Google, LinkedIn, and/or Twitter servers
used in the authentication process (depends on what social channels you are configuring).
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/outgoing interface, 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 (i.e. accept or deny). If
accept, it looks to see if there are any other instructions on how to process the traffic.
For social authentication, you need to create an exemption to allow access to the FortiAuthenticator. You
can configure this policy through the CLI or Web-based manager.
The only thing you cannot enable through the Web-based manager is set captive-portal-exempt enable.
This command is imperative in this policy and can only be set through the CLI.
FORTINET
You also need to create a firewall policy for outbound social network access. This policy allows access to
specified social networks. You can configure this policy through the CLI or Web-based manager. You can
create a separate outbound policy for each social network portal if you prefer.
The only thing you cannot enable through the Web-based manager is set captive-portal-exempt enable.
This command is imperative in this policy and can only be set through the CLI.
FORTINET
In this section, we will examine some of the ways you can manage users authentication through the social
portal. Specifically, how you can monitor social logins and how you can manually de-authenticate users.
FORTINET
As mentioned, 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 into your network through
the social portal.
You can monitor social logins from the FortiAuthenticator Web-based manager under the Social Login
Users page.
FORTINET
Although you configure account expiry in the FortiAuthenticator social portal settings, for various reasons
you may wish to forcefully de-authenticate users prior to the expiry time. These steps involve both the
FortiGate and FortiAuthenticator, and demonstrate how to forcefully de-authenticate users.
FORTINET
After this lesson, you should understand FortiAuthenticators captive portal guest management features as
well as be able to describe the available authentication options, configure social channels, configure
captive portal on both the FortiAuthenticator side and FortiGate side, and monitor and de-authenticate
users.
FORTINET
In this lesson, we will examine two-factor authentication and FortiTokens. Specifically, how you can
provision, create, and administer FortiTokens for use as your step-up authentication solution.
FORTINET
After completing this lesson, you should have these practical skills that you can use to create, assign,
administer, and manage tokens for use with two-factor authentication.
This includes demonstrating knowledge of one-time password (OTP) tokens, distinguishing between
time-based and event-based OTP tokens, distinguishing between FortiGate and FortiAuthenticator as
validation servers, identifying ways to acquire OTPs, and explaining hardware and software tokens. You
will learn how to provision tokens, identify methods of obtaining token data, and register, assign, and
activate tokens.
FORTINET
You will also learn how to configure users for two-factor authentication using tokens. Finally, you will
learn how to manage FortiTokens.
FORTINET
In this section, we will explore one-time password (OTP) tokens, which is the something you have or
second step of two-factor authentication. FortiAuthenticator supports one-time password tokens (both
hardware and software-based).
FORTINET
Typically, a one-time password (OTP) token is not used as a standalone solution, but as an additional
authentication mechanism on top of a user name and static passwordthe something you have in two-
factor authentication.
OTP tokens generate passwords that can only be used once. They are more secure than static passwords
because they are not vulnerable to replay attacks. For example, even if an attacker obtains a OTP, the
password invalidates after a short interval (usually 60 seconds).
Since 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. This is a physical device, such as the FortiToken 200.
Software tokens. This is a software application on a smart phone, such as FortiToken Mobile
Tokenless (email or SMS)
FORTINET
There are two main standards governed by OATH to generate one-time password tokens: time-based and
event-based.
Time-based one-time passwords, or TOTP, 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 FortiAuthenticators system clock
accurately adjusted. Therefore, it is highly recommended to use a NTP server for system time
synchronization.
Hash-based one-time passwords, or HOTP, 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 different each timebut 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).
FORTINET
Lets take a closer look at 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 only valid for 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 user name and static password (first factor), and then the one-time
passcode provided by the token (second factor).
3. A validation server receives the user name 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 one in the token. By using the same algorithm it 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 recommend).
FORTINET
RADIUS authentication is a method for a RADIUS client delegating authentication (and sometimes
authorization) to a third-party user database i.e. 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.
The method of implementing two-factor authentication using RADIUS depends on the support of the
RADIUS challenge message by the RADIUS client.
In most cases, the RADIUS client will support RADIUS challenge-response. This is the preferred
mechanism for two-factor authentication, as it is most natural for the end user.
If the RADIUS client supports the use of the RADIUS challenge packet, the remote user authenticates as
normal by entering the user name and password first, which is then forwarded by the RADIUS client to the
RADIUS server. This is 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.
As we will see later, the token passcode can be sent by email or SMS to the user. In those cases, the
RADIUS client must support the RADIUS challenge. This is because a trigger is required for
FORTINET
FortiAuthenticator to send the email or SMS. This trigger is the RADIUS Access Challenge.
Authentication flow:
Username: usera
Password: pa$$word
OTP: 385740
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.
Authentication flow:
Username: usera
Password: pa$$word385740
Note that the OTP Passcode Appended method can be used on a system that supports challenge-
response.
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 and/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.
FORTINET
In this section, we will examine Fortinets one-time password tokens, which users in your network can use
for two-factor authentication: FortiToken 200a hardware-based token, and FortiToken Mobile, a
software-based token (or soft-token).
Fortinet does have a USB smart card token that can be used for two-factor authentication as well.
However, since the USB smart card token uses a x.509 certificate for authentication (rather than an OTP),
it will be examined in the Certificate management lesson.
FORTINET
This is a FortiToken hardware device: The FortiToken 200. It has a LCD screen that displays the 6-digit
code and a bar on the left side of the display indicating the time left before the OTP expiry, which is set by
default to 60 seconds. The device goes into sleep mode after the current interval to save battery life, so it
has a button that can be used to wake it up.
The benefit of the FortiToken 200 compared to third parties is that the token is perpetual and will function
for as long as the battery remains functional (unlike RSA tokens, for example, which expire after a fixed
period).
FORTINET
The FortiToken Mobile is installed on any Android or iOS mobile device as an app. It is a PIN-protected
application that displays the 6 (or 8) digit code in the users mobile phone in 30 or 60 second timesteps
(default 60 seconds). The application stores the seed encrypted and it can be configured to erase the seed
in case the amount of failed PIN attempts exceeds a threshold.
FORTINET
In this section, we will examine the process involved with provisioning both hardware and software tokens
and how to configure users for two-factor authentication with their tokens.
FORTINET
These are the steps that an administrator must follow to provision any new token:
1. Obtain token data. The token data consists of the serial number and seed.
2. Register/add tokens in the validation server.
3. Assign tokens to users.
4. Configure users for two-factor authentication.
Remember, the validation server can either be FortiGate or FortiAuthenticator, depending on your
requirements.
We will explore these steps in detail over the next few slides, using FortiAuthenticator as the validation
server.
FORTINET
Since the first step involves obtaining the token data, which includes the seeds, lets 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. Then, it is encrypted using
2048-bit RSA and stored in a secure database. The seed number is never exposed to human operators,
as it is directly injected into the hardware by an automatic system. Upon request from a customer, the
seed can be destroyed.
FortiToken Mobile includes seeds as well. FortiToken Mobile seeds are generated on demand at time of
provisioning of the token to the user on the FortiGate/FortiAuthenticator. When a provisioning request is
received, the FortiCare system uses a random data source to generate the seed and store it, encrypted,
until it has been securely retrieved by FortiAuthenticator and the users FortiToken Mobile application at
which point the seed is irretrievably destroyed on the FortiCare systems. If the seed is not downloaded
within a maximum of 168 hours (7 days) it is automatically destroyed.
FORTINET
Once the token is seeded, the token data (serial number and seed) needs to be delivered to the validation
server administrator.
The administrator can receive the token data multiple ways. In order of increasing security:
1. Activate encrypted seeds online via 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. Alternatively the barcode on the rear can be scanned using a barcode scanner.
2. Receive the encrypted seeds on a CD. This is currently available only with FortiAuthenticator. The
encrypted seeds are burned to a CD, which is shipped with the tokens in a tamper-evident package.
The seeds are encrypted using a unique secret key per package. Fortinet sends an email (out-of-
band) containing the keys. When the seeds are imported, they are decrypted using the keys, and re-
encrypted one more time before being stored in the FortiAuthenticator database.
3. Generate and provision the seeds in-house using a Token Provisioning tool. The In-house method is
intended for high security organizations that want to have full control of the seeds from their
generation. You need a seed injection system and a hardware token seed burning system, as with this
method, Fortinet ships blank tokens with no seeds. You are required to inject the seeds inside your
secure premises. It is a very consuming process, but it is highly customizable and secure.
FORTINET
You must register any new tokeneither the FortiToken 200 or FortiToken Mobilewith
FortiAuthenticator. You can do this through the FortiToken page.
There are two ways you can add these tokens to FortiAuthenticator: manually create or import.
To manually create tokens, click Create New. If you are registering a FortiToken 200, 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 these 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. If importing a FortiGate configuration file, you can specify whether to import tokens only,
import tokens and users, or import all tokens and users (this would include unassigned tokens).
Each time you register new FortiTokens, the connectivity between FortiAuthenticator and FortiGuard must
be up, as FortiAuthenticator needs to validate each FortiToken against the FortiGuard servers. So
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.
FORTINET
You can assign a token to a local user or remote user through the User Management page. Enable
Token-based authentication and select FortiToken. From here, you can select an existing FortiToken
200 or FortiToken Mobile from their respective drop-down lists (remember, the token must first be
registered with FortiAuthenticator).
For local users only, you can choose to send a temporary passcode for a FortiToken 200 or FortiToken
Mobile over email or SMS. This allows the assignment of 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.
FORTINET
Once you assign a FortiToken 200 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 organizations 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 200 to
display the code.
FORTINET
If you assign a FortiToken Mobile (soft-token) to a user, the process of user activation is as follows:
FORTINET
Before provisioning the first FortiToken Mobile, go to the FortiGuard page and select the required
activation timeout, token size, pin length, and algorithm.
FORTINET
You can also customize the FortiToken Mobile app with your organizations logo. You must configure your
organization logo first under the Organization page. Then, you can assign it to the user. Edit the user
entry from the User Management page (either local or remote user), and from the User Information
section, select the logo from the Organization drop-down box. The logo will then appear on their
FortiToken Mobile app.
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, as well as 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 prior to expiry, the user must contact the administrator to receive a new activation code. We will
examine how to modify the passcode validity time in the next section (Managing FortiTokens).
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.
FORTINET
In addition to the hardware and software tokens, FortiAuthenticator can deliver a one-time password (or
token code) by either email or SMS. If the delivery method is email, you need to ensure you have
configured the user account to include a valid email address. If the delivery method is SMS, 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.
FORTINET
Just because a user is assigned a FortiToken and the user has registered/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 through the User Management page by enabling both Password-
based authentication (this will be used as the first factor) and Token-based authentication (this will be
used as the second-factor).
FORTINET
You can configure two-factor authentication for RADIUS authentication requests from a RADIUS client.
There are four authentication methods available. They are:
Enforce two-factor authentication: 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.
Apply two-factor authentication if available: 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 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 authentication: Removes the need for use of the token passcode even if it is
provisioned. This is used in low risk situations where added security is not required for the specific client.
Not recommended, use with caution.
FortiToken-only authentication: Only validates token passcode. Entering the password will fail and a
challenge will not be made in this case. It 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.
FORTINET
In this section, we will examine ways to manage your FortiTokens, such as how to configure token
settings, how to synchronize tokens if the clock in the token and the clock on FortiAuthenticator are
different, how to manually adjust token drift if the time difference is too large to correct with the
synchronize function, how to monitor token inventory, how to lock a token if lost or stolen, and how to
export tokens.
FORTINET
From the General 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 a FortiToken code should be marked
as valid inside the window. For example, if the field is set to 1 minute the token code in the last, current,
or next minute is considered valid.
set a sync window (or counter window for event-based tokens) so if a FortiToken code is invalid but is
still inside this window, it should be marked out of synchronization.
set the length of time after which a token passcode sent via email or SMS will be marked as expired.
Security can be reduced by changing these settings. For example, by changing the time-based valid
window from 1 min to 100 mins 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. Change with extreme caution.
FORTINET
As mentioned, 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 both 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, as the
codes are time-based. Fortinet recommends synchronizing all new FortiTokens.
You can re-synchronize a FortiToken through the FortiToken page. Locate the FortiToken you want
synchronize and click Synchronize. You must enter the code currently displayed in 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.
FORTINET
When both FortiAuthenticator and the FortiTokens have been initialized prior to setting an NTP server, the
time difference can end up being too large to correct with the synchronize function. As such, you must
manually adjust the drift. You can adjust the drift through a Web browser at:
https://<FortiAuthenticator_IP>/admin/fac_auth/fortitokendrift
FORTINET
The User Inventory widget on the FortiAuthenticator dashboard indicates the total number of registered
FortiToken devices and the total number of disabled FortiTokens.
FORTINET
If a user reports a FortiToken lost or stolen, you can lock the FortiToken. Select the FortiToken from 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.
FORTINET
You can export FortiTokens to a .csv file through the FortiTokens page by clicking Export FTK-200.
Tokens are removed from FortiGuard once provisioned, so it is not possible to re-provision them onto
another system without opening a support ticket. So by providing an export option, you can re-provision
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.
FORTINET
FORTINET
In this lesson, we will examine how to use FortiAuthenticator as a Certificate Authority (CA) that can
generate, distribute, and manage digital certificates. It also describes Certificate Revocation Lists
(CRLs), Certificate Signing Requests (CSRs), and using SCEP to import certificates into a FortiGate
device.
FORTINET
After completing this lesson, you should have these practical skills that you can use to manage
certificates with FortiAuthenticator.
This includes understanding Public Key Cryptography (PKI), asymmetric cryptography, digital
certificates, and Certificate Authorities.
FORTINET
You will also learn FortiAuthenticators role in generating and managing certificates, and how to
configure FortiAuthenticator to generate local CA certificates; import and export certificates and CSRs;
generate client certificates; create and revoke CRLs; and enable and configure SCEP.
FORTINET
Since weve identified FortiAuthenticator as a device that can act as a Certificate Authority (CA), this
section aims to provide a brief refresher of Public Key Infrastructure (PKI)the main infrastructure that
supports elements like CAs and digital certificates.
This subject was discussed in depth in NSE 4, so for more details you may wish to review the Certificate-
based Operations lesson.
FORTINET
Public Key Infrastructure, or PKI, uses asymmetric cryptography as a way to secure communications
between two entities. Cryptography achieves four objectives:
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
secret key has to be exchanged between the sender and recipient so the message can be encrypted and
decrypted. The secret key is exchanged over the Internet, and therefore susceptible to being intercepted.
With asymmetric cryptography, a key pair is used. There is a public key, which is openly distributed, and a
private key, which is kept secret by the owner. So there is no concern about intercepting the public key, as
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 (and vice versa).
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 Certificate Authority (CA). A CA signs each certificate it issues in order to certify
that the digital certificate and its contents are trusted and valid.
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 certificateknown as the root certificatein
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, they are essentially proclaiming this is the entity who we
say it is and we certify it. Accordingly, if users trust the CA and can verify the CAs signature as authentic,
then they must trust that the public key does belong to the entity identified in the digital certificate.
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 CAs 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 web
site, 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.
FORTINET
FortiAuthenticator has several roles that involve certificates and certificate management.
FortiAuthenticator can:
act as a CA for the creation and signing of digital certificates
act as Simple Certificate Enrollment Protocol (SCEP) server
perform remote LDAP authentication using certificates, and
perform EAP authentication using certificates
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 Certificate Revocation
Lists (CRLs).
FORTINET
FortiAuthenticator can also act as a Simple Certificate Enrollment Protocol (SCEP) server for:
FORTINET
A certificate signing request (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 certificate revocation list (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 re-posted by the CA periodically, so any
entities attempting to validate the certificate can see that is revoked based on its presence on the CRL.
A revocation is irreversible. Only those placed on hold (i.e. for a missing digital certificate) can be
reversed.
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.
FORTINET
Extensible Authentication Protocol (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 clients certificate is signed by one of the configured (and authorized)
CA certificates. The client certificate must also match one of the user certificates.
FORTINET
FortiAuthenticator can also integrate with FortiManager to deploy digital certificates to multiple FortiGates
in VPN implementations. Site-to-site VPNs are often only secured with a pre-shared 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 FortiGates. Finally, the FortiGates automatically get the certificates from
FortiAuthenticator via SCEP.
FORTINET
For client-based certificate VPNs, certificates can be created and stored in the FortiToken 300 USB smart
card tokenwhich 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 to Web-based
applications as well as sign/encrypt email, PDF documents, Microsoft Office files, and software.
FORTINET
This section explores how to generate both root CAs and sub-CAs (also known as intermediate CAs)
through FortiAuthenticator.
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 certificatea self-signed CA.
You can create a root certificate through the Local CAs page. You must select Root CA certificate as the
certificate type, and, at 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).
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 was compromised, the entire
PKI structure will fail. By using intermediate CAs, the PKI structure becomes segmented into branches. So
if the intermediate CAs private key is compromised, only one branch in the PKI structure is compromised,
and the rest of the organization remains protected.
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 certificate signing request (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 you do not set
a validity period.
FORTINET
In this section, we will examine how to export and import certificates and CSRs.
FORTINET
You can manually export and import certificates (local or trusted CAs) through the Certificate Authorities
page.
For the FortiAuthenticator root CA and intermediate CA signed by the root, once exported as a file, it can
be imported into another network device, such as the FortiGate. Once imported by the other network
device, that device can validate (and trust) any certificates signed by the FortiAuthenticator CA. We will
examine importing the root certificate into FortiGate on the next slide.
On the import side, FortiAuthenticator can import another network devices certificates. Once imported into
FortiAuthenticator, it can validate (and trust) any certificates signed by that CA.
FORTINET
As mentioned, other network devices, such as FortiGate, can import the FortiAuthenticator root CA. In the
case of FortiGate, this is done through the Certificates page. You can import manually if you have the CA
certificate downloaded on your local computer or you can choose to import through the SCEP protocol.
The URL of the FortiAuthenticator SCEP server is: http://<FortiAuthenticator_IP>/cert/scep.
FORTINET
Trusted certificates are used 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 through the Trusted CAs page.
FORTINET
As mentioned earlier, you can create an intermediate CA signing certificate request (CSR) through
FortiAuthenticator. Once created, the status appears as Pending. In order for it to become active, you
must manually export it and send the file to a third-party CA for signing. Once signed, it is sent back to
FortiAuthenticator where you must import it.
FORTINET
FortiAuthenticator can generate two types of end-entity certificates: user certificates and local service
certificates (Web-server certificates). This section examines how to create these types of certificates.
FORTINET
You can create a user certificate through 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 in FortiAuthenticator, you can select
the user from the drop-down list. You must select the subject input method, either Fully distinguished
name or Field-by-field, and provide the required information. You must also specify an expiration date or
time for the certificate.
You also have the option to configure the certificate further. For example, you can enable the certificate for
Smart Card logon, and specify some advanced options for key usages (for example, non repudiation) and
advanced key usages (for example, code signing).
FORTINET
Creating a local service certificate is very similar to a user certificate. You can create a local service
certificate through the Local Services page. Just as 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.
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 the FortiGate HTTPS access to the Web-based manager. Essentially, the certificate
becomes available to services and other processes that run under the local service store.
You can import a local service certificate through the Certificates page on FortiGate. The FortiGate
administrator must have the local service certificate file available to upload.
FORTINET
In this section, we will examine how you can create certificate revocation lists (CRLs) and how you can
revoke certificates.
FORTINET
You can revoke user certificates through the User Certificates page or local service certificates through
the Local Services page. Select the certificate and click Revoke. You must supply a reason for the
revocation through one of the supplied 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.
FORTINET
The serial number 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 certificates revoked status, you must export and
publish (distribute) the CRL.
You can export the CRL under the CRLs page. On FortiAuthenticator, a CRL exists for each local CA.
Select the CRL you want to export and click Export.
Distributing or publishing the CRL should be performed periodically or each time a new certificate has
been revoked.
It is important to note that if a CA is deleted, their corresponding CRLs are also deleted (along with any
user certificates they signed).
FORTINET
In addition to static CRLs, FortiAuthenticator supports Online Certificate Status Protocol (OCSP) as an
alternative method to checking a certificates revocation status, though normally CRLs are used. The
OCSP status check is typically carried out over HTTP with a request-response format. The authority
responding can reply with a status of good, revoked, or unknown. The OCSP responder can be accessed
via http://fac_fqdn:2560.
FORTINET
FortiGate can also import a CRL from the FortiAuthenticator SCEP client. This is done through the
Certificate page. Select SCEP and enter the FortiAuthenticator SCEP client URL:
http://<FortiAuthenticator_IP>/cert/scep.
FORTINET
As mentioned earlier in this lesson, FortiAuthenticator can act as a Simple Certificate Enrollment Protocol
(SCEP) server for:
Signing CSRs
Distributing CRLs
Distributing CA certificates
FORTINET
You can enable SCEP on the General page. You must specify the default CA and enrollment password.
You must also specify the enrollment method type.
Note that SCEP is based on HTTP. As such, you must enable HTTP administrative access in the
FortiAuthenticator interfaces that face the SCEP clients.
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 generally not recommended.
You can create an automatic enrollment request through 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.
FORTINET
The challenge password can either be randomly generated or the pre-configured default enrollment
password of the SCEP client.
You can choose to distribute the random challenge password manually, over SMS, or over email. If you
select to distribute manually, the random password is displayed at the top of the page once the automatic
enrollment request is created.
After the automatic enrollment request is created, the status is Pending until the user submits their
respective CSR with the challenge password.
FORTINET
If FortiAuthenticator has automatically pre-approved a CSR for FortiGate, the FortiGate administrator must
submit a CSR with the challenge password to FortiAuthenticatorafter which the CSR is automatically
approved.
On FortiGate, the CSR is created through the Certificate page. In addition to filling out all the certificate
information, you must select Online SCEP as the enrolment method and enter the SCEP URL and
password provided by FortiAuthenticator.
FORTINET
As previously mentioned, the manual enrolment method requires the user to submit the CSR first. On
FortiGate, the CSR is shown as Pending until the FortiAuthenticator administrator either approves or
rejects it.
On FortiGate, the CSR is created in the same way as the pre-approved CSR. But this time, you must
select File Based as the enrolment method and submit the CSR file to FortiAuthenticator.
FORTINET
We examined:
Public Key Cryptography
Asymmetric cryptography
Digital certificates
Certificate Authorities
FortiAuthenticators role in generating and managing certificates
Generating local CA certificates
Importing and exporting certificates and CSRs
Generating client certificates
Creating and revoking CRLs, and
Enabling and configuring SCEP
FORTINET
In this lesson, we will examine how to use FortiAuthenticator as a logon event collector that uses the
Fortinet Single Sign-on communication framework to transparently authenticate users.
FORTINET
After completing this lesson, you should have these practical skills that you can use to configure Fortinet
Single Sign-on. This includes:
FORTINET
It also includes:
FORTINET
In this section, we will examine the Fortinet Single Sign-on (FSSO) access control mechanism.
FORTINET
Fortinet Single Sign-on (FSSO) offers a solution for transparently identifying (and implicitly trusting) users
that 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 FortiGate firewall
policy only, as opposed to single sign-on into any Web application or similar.
FSSO is commonly used to transparently authenticate Microsoft Active Directory (AD) users, but with
FortiAuthenticator, it is not limited to that environment only: FSSO can also transparently authenticate
users in non-Microsoft environments.
FORTINET
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 that specific network
service.
FORTINET
For the case of Microsoft Active Directory users, there are two ways of collecting logon events: Domain
Controller (DC) agent mode, and Windows AD Polling mode.
FORTINET
The domain controller (DC) agent mode requires a DC agent to be installed on each of the Windows
Domain Controllers. It also requires a Collector Agent installed on a Windows Server. This is how this
mode works:
1. When the user logs into the Windows network, a logon event is recorded in one of the Domain
Controllers.
2. The DC Agent installed in that DC detects the logon event and forwards it to the Collector Agent. In that
way, the Collector Agent collects the logon events from multiple DCs.
3. The Collector Agent forwards the collected logon 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 depending on the user, the user groups, and the traffic destination.
FORTINET
Its worth mentioning Windows Management Instrumentation (WMI) polling, as it relies on DC agent mode.
FortiAuthenticator supports WMI polling to detect workstation log off. This validates the currently logged on
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 belongs to the Domain Admin group.
FORTINET
Unlike DC agent mode, Windows Active Directory 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 is done directly from FortiGate, so a Collector
Agent is not always needed.
1. The user logs into the network, which generates a logon event.
2. The Collector Agent is periodically polling the DCs to extract the logon events.
3. Logon events are forwarded to FortiGate. They contain, as in the case of the DC agent mode, the user
name, user groups, and 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.
FORTINET
So, if we can have Single Sign-on without FortiAuthenticator, why configure it?
1. Both DC agent mode and polling mode only work in Windows AD environments. You can use
FortiAuthenticator to implement FSSO in both Microsoft and non-Microsoft environments. It can collect
logon events from many different sources, which we will explore later.
2. It offers a Windows AD polling mode that does not require the use of a Collector Agent and it is more
scalable than doing the polling directly from FortiGate.
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.
Users authenticating against Active Directory can be automatically authenticated.
RADIUS Accounting packets can be used to trigger an FSSO authentication.
Users can be identified through the FortiAuthenticator API. This is useful for integration with third-party
systems.
FORTINET
This diagram illustrates the multitude of ways FortiAuthenticator can identify users over the FSSO
framework.
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 in which the user identity and their location (IP)
are discovered. We will discuss 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 or FortiClient. The user information is
forwarded to the subscribing device where the information can be utilized in firewall policies.
Note that multiple methods can also be combined. For example, Single Sign On Mobility Agent may be
used for Microsoft Windows domain PCs but fallback to the login portal with embedded widgets for non-
Windows systems or unauthenticated PCs.
FORTINET
FortiAuthenticator has taken the concept of Fortinet Single Sign-on (FSSO) as used in FortiGate and the
FSSO software client and extended it with several new user identification methods. Due to the flexibility of
the FortiAuthenticator product, this list is continuously growing. This section examines current FSSO user
identity discovery methods.
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 in 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.
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 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.
FORTINET
The FortiClient SSO Mobility Agent is part of the standard FortiClient product installation. When installed,
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 due to WiFi roaming, and automatically updates FortiAuthenticator. When the user
logs off or shuts down, the user is also logged off from FortiAuthenticator. In cases where an unclean
disconnection is made (e.g. power failure, hibernation, network failure), a heartbeat system is implemented
so the user will be de-authenticated following a configurable number of heartbeat failures.
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 off from the browser.
As repeated manual re-authentication may impact the user experience, FortiAuthenticator supports
automated user identification for subsequent access through the use of portal widgets. The widget
implementation, which uses a 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, validity of which is
configurable for up to 30 days, is stored in the users browser. On subsequent visits, the user will be
transparently re-authenticated using the cookie key (assuming it matches that stored on the
FortiAuthenticator). On timeout of the cookie, or should the user clear their cache or visit a new machine,
the user will be required to re-authenticate.
FORTINET
The RADIUS Accounting method uses RADIUS start, interim, and stop accounting packets to trigger
logon/logoff to FSSO. Such RADIUS packets are commonly sent by networking devices such as SSL-VPN
devices, wireless controllers, and switches amongst others.
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.
FORTINET
FortiAuthenticator can parse user name and IP address information from a Syslog feed from a third-party
device, and inject this information into FSSO so it can be used in FortiGate and FortiCache firewall
policies.
Syslog objects include sources and matching rules. Sources identify the entities sending the syslog
messages, and matching rules extract the events from the syslog messages. Messages coming from non-
configured sources are dropped.
FORTINET
To enable integration with third-party systems, FortiAuthenticator offers a programmatic REST API that
can be used to authenticate and de-authenticate 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.
FORTINET
FortiGate devices support the concept of Domain Controller (DC) Agent software for the collection of login
information from Windows Active Directory systems through either polling or installation on the domain
controller. Terminal Services (TS) Agent is a similar concept, except it collects user login information from
Citrix or Windows Terminal Servers. FortiAuthenticator implements the polling functionality directly;
however, it also accepts a feed from both DC Agent and TS Agent installations if necessary.
FORTINET
RADIUS Accounting Proxy is different from the previously mentioned RADIUS Accounting.
RADIUS Accounting is used to convert, for example, third-party (or FortiGate WiFi/VPN login) RADIUS
events to FSSO. This is most useful in an Enterprise environment for adding in additional third-party
user identity sources.
RADIUS Accounting Proxy, on the other hand, takes in one accounting source and redistributes to
multiple FortiGates. This is most commonly used in the ISP/Carrier space.
FORTINET
FortiAuthenticator and FortiGate must first be configured to collect the relevant user logon data. After this
basic configuration is complete, the various methods of collecting the login information can be set up as
needed.
This section intends to walk through an example configuration on both FortiGate and FortiAuthenticator.
FORTINET
Each FortiGate that uses FortiAuthenticator to provide Single Sign-on authentication must be configured to
use FortiAuthenticator as an SSO server. To do this you need to create a Fortinet Single-Sign-On Agent
which sets FortiAuthenticator as an SSO serveron FortiGate.
You can configure the FSSO agent on FortiGate through the Single Sign-On page. You must select
Fortinet Single-Sign-On Agent as the type of SSO agent, enter a name for the agent, enter the IP of your
FortiAuthenticator, and finally enter a secret key. The secret key must be the same as you will define on
FortiAuthenticator when enabling FSSO authentication later in the process.
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 through the User Group page. You must enter a
name for the group and select Fortinet Single Sign-On (FSSO) as the group type.
FORTINET
To allow FortiAuthenticator to listen for requests from authentication clients, you must enable FSSO
authentication.
You can enable FSSO authentication on FortiAuthenticator through the General page. You must select
Enable authentication and enter the secret key. This must be the same secret key that you defined when
creating the FSSO agent on FortiGate.
FORTINET
In order to provide FSSO only to certain 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 from the FortiGate Filtering page. You must name the filter, provide the
IP 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.
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 click Apply & Refresh.
FortiGate is able to view the remote group that you set to filter in the previous slide. The group can now be
used in firewall policies.
FORTINET
Once the basic configuration of both FortiAuthenticator and FortiGate are complete for FSSO, you can
configure one or more discovery methods on FortiAuthenticator. This section explores the various
configuration requirements for each FSSO discovery method.
FORTINET
You can enable one or more discovery methods on FortiAuthenticator from the General page in the
Fortinet Single Sign-On (FSSO) section.
Some methods require further configuration other than enabling the method here. We will explore the
configurations in this section.
FORTINET
In order to use domain controller polling, you must enable Windows Active Directory domain controller
polling.
Once enabled, you must create a domain controller. This allows FortiAuthenticator to poll the Active
Directory event log to track user logons as well as poll the Windows Management Instrumentation (WMI)
logs to track the user logoffs. You can configure domain controllers from the Domain Controllers 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, the FortiAuthenticator and FortiGate must be prepared as discussed in the previous
section.
FORTINET
In order to use RADIUS accounting, RADIUS accounting SSO clients must be enabled.
Once enabled, you have to configure RADIUS accounting from the RADIUS Accounting page. Here, you
are configuring FortiAuthenticator as a RADIUS accounting client to the RADIUS server.
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 clients pre-shared key. You
must also select the type SSO user the client will provide (external, local, remote). If required, you can also
customize the user name, client IP, and user group RADIUS attributes to match the ones used in the
incoming RADIUS accounting records.
FORTINET
Once enabled, you have to configure the Syslog sources from 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. Rules are required for
every syslog source. Predefined rules are available for Cisco and Aruba wireless controllers. For other
systems, custom policies can be created to parse message files in various formats. Finally, you must
select an SSO user type (external, local, or remote).
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 FortiClients. This requires you to enter the secret key. You can also configure
the duration between keep alive 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
Active Directory server in order to spoof a legitimate user logon through the FortiClient SSO Mobility
Agent. FortiAuthenticator will initiate NTLM authentication with the client, proxying the communications
only to the legitimate Active Directory servers it is configured to use. If NTLM is enabled, FortiAuthenticator
requires NTLM authentication when:
the user logs on to a workstation for the first time
the user logs off and then logs on again
the workstation IP address changes
the workstation user changes
NTLM authentication expires (user configurable)
FORTINET
In order to use the domain controller (DC) agent and/or terminal services (TS) agent, the clients must be
enabled. 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 (default is 8002). To enable authentication, select Enable
Authentication and enter the secret key of the DC/TS agent.
FORTINET
In order to use Portal services, which supports multiple authentication methods including manual
authentication, embeddable widgets, and Kerberos authentication, you have to configure portal services
from the Portal Services page.
If you want to use manual portal authentication or widgets, select Enable SSO on login portal. Once
enabled, you must specify if you want to authenticate local users and/or remote users (in a remote LDAP
server). You can also specify if all users can authenticate, or only users that belong to specific groups.
The FSSO widget offers a semi-automatic process to authenticate users when transparent authentication
is not possible. The widget installs a cookie in the users browser that is valid for several days. The cookie
is a security string that is unique to each user. The FortiAuthenticator automatically checks the cookie and
identifies the user and the IP address. The embeddable code is provided once you enable the SSO login
portal. You can place the embeddable code on your organizations website (for example, your intranet
homepage).
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 SSO Web Service refers to SSO using the API. This configuration is needed to allow the API to accept
SSO logins and to tell it which type of users will be authenticating.
FORTINET
This section explores some additional FSSO-related settings that can better calibrate the collection of
relevant user logon data, or improve the efficiency of your network for FSSO.
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 from the Fine-grained Controls page.
FORTINET
SSO users and groups are only used when you need to modify the behavior of a user or group before
sending 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 as some AV
products will "log on" using service accounts on the PC and overwrite the user credentials breaking
FSSO.
Override the default number of concurrent devices a user or group can have in FSSO.
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.
With passive mode, items have an expiry time after which they are removed and re-queried on next logon.
With active mode, items are periodically updated for all currently logged on users.
FORTINET
The supplier" FortiAuthenticator behaves in the same way that a DC Agent would, in that it does its polling
locally then sends the information back to the upstream FortiAuthenticator collector that aggregates from
multiple sources and sends the logins up to the FortiGate(s). To enable scaling of FortiAuthenticator
deployments, you can enable hierarchical tiering of suppliers and collectors from the General page. You
must specify a collector listening port (default 8003).
FORTINET
You can manage any supplier and collector tier nodes from 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.
FORTINET
We examined:
FORTINET
In this lesson, we will examine wireless and wired 802.1X authentication. It will cover configurations
required in FortiAuthenticator, FortiGate, and the Windows workstations for a successful 802.1X
operation.
FORTINET
After completing this lesson, you should have these practical skills that you can use to configure wireless
and wired 802.1X authentication, MAC-based authentication, and machine-based authentication. You
should also be able to identify the supported EAP methods.
FORTINET
802.1X is a standard designed to provide authentication services to network devices that want to join a
local wired or wireless network. The 802.1X standard defines an authentication protocol called Extensible
Authentication Protocol (or 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 clients 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, etc). The authentication is tunnelled from the client to the FortiAuthenticator over the
RADIUS protocol.
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 will be blocked by the authenticator.
The client must authenticate first.
1. The client sends an EAPOL-Start packet to initiate the EAP authentication.
2. The authenticator replies with an EAP-Request/Identity packet to request identification.
3. The client sends its identity (usually the username).
4. The information is forwarded to the RADIUS server in a RADIUS-Access request packet.
5. The RADIUS replies with an Access Challenge packet requesting the password.
6. The authenticator requests the password from the client.
7. The client replies with a Response/Auth packet, which contains the password.
8. The password is forwarded to the RADIUS server, which then replies with an Access-Accept packet to
grant the access.
9. The authenticator sends an EAP-Success packet to the client with a confirmation that the credentials
are OK.
10. The client can now send the user data.
FORTINET
PEAP (protected EAP) forms a potentially encrypted and authenticated TLS between the client and
server using a digital certificate on the server. It is known as the outer authentication method, as it
only creates the TLS tunnel to protect any authentication transactions. Once the tunnel is formed, it
uses an EAP type as an inner authentication method, such as MSCHAPv2.
EAP-GTC (Generic Token Card) is a type of inner authentication method to PEAP that provides user
or device information. It carries a text challenge from the authentication server and a reply generated by
a security token. It allows generic authentications to virtually any identity store, including OTP token
servers, LDAP, Novell E-Directory, and more. It uses digital certificates only on the server side.
EAP-TTLS (tunneled transport layer security) extends the TLS protocol. It uses digital certificates only
on the server side. Once the server is securely authenticated to the client, it uses the tunnel (secure
connection) to authenticate the client.
EAP-TLS also uses the TLS protocol and is considered one of the most secure EAP standards
available, as it supports certificate-based authentication with public keys on both the server and the
client side. It is also the most commonly used method when supporting bring your own device (BYOD)
in the enterprise.
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 appliance.
You can also use the self-service portal with device certificate self-enrollment.
FORTINET
Note that for the case of non 802.1X compliant devices that want to join the network, such as a printer,
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.
FORTINET
FortiAuthenticator also supports machine-based 802.1X authentication. This feature allows a Windows
machine to authenticate to a network via 802. 1X prior to user authentication.
FORTINET
In this section, we will examine how to deploy a wireless EAP-TLS solution. This method has the additional
advantage of supporting both server and client authentication.
FORTINET
In order to configure a wireless solution with 802.1X EAP-TLS authentication, you first require the
following:
A root CA. You can either use an existing external CA for generation of 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 how to configure a root CA.
RADIUS server. This allows FortiAuthenticator to authenticate users via RADIUS. Refer to the
Administering and authenticating users lesson for how to configure a RADIUS server.
Wireless clients. For a wireless 802.1X solution, you require a wireless client. Wireless 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.
FORTINET
As mentioned, EAP-TLS uses public keys on both the server and the client side, so you need a root CA.
The root CA is needed to issue a local server certificate to FortiAuthenticator. To configure EAP-TLS, you
need to:
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 how to create a local server certificate.
FORTINET
2. Configure the user account. This involves binding the users 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 the 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
pre-configured, you just have to set the EAP type. This is done through the Clients page. In this
example, we are setting the EAP type to EAP-TLS. If you want to ensure mutual authentication is
used, this is the only EAP type you should have enabled. Otherwise, it will be possible to fall back on a
less secure, non-mutual method. When configuring 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 on configuring a RADIUS client, see the
Authenticating users lesson.
FORTINET
4. Configure RADIUS-EAP settings. Once the certificates are generated, they must be associated with
EAP-TLS so that they are used during the authentication process. This involves selecting the EAP
server certificate that will be used. This is required for EAP-TLS and EAP-TTLS.
FORTINET
FORTINET
In this example, we will use the native Windows wireless application, 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. But we will examine the manual
configuration for cases where the auto-configuration is unsuccessful.
To manually configure, click Wireless Properties associated with your WiFi connection. In the dialog box
that appears, click the Security tab and ensure WPA2 Enterprise is selected as your security type. From
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
servers identity by validating the certificate.
FORTINET
Now that weve explored how to configure a wireless 802.1X solution using EAP-TLS, lets explore how to
configure a wired 802.1X solution, or what is called port access control.
FORTINET
The process, in general, is very similar. The client tries to connect to the network through a LAN switch.
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 in FortiAuthenticator is the same. The following slides explain how to configure a
Windows station and a D-Link LAN switch for 802.1X authentication.
FORTINET
This is an example of the 802.1X configuration for a D-Link switch. Other vendor configurations are very
similar. You must enable 802.1X, enter the FortiAuthenticator IP address as the RADIUS server IP, and
provide the RADIUS secret key.
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. In this way, the service will automatically start each time the computer is booted. You must
reboot your computer for the changes to take effect.
FORTINET
Once rebooted and the Wired AutoConfig service is running, the LAN connection properties displays a new
tab called Authentication. Under that tab, enable IEEE 802.1X authentication and select the Microsoft
Smart Card or other certificate authentication method (this is EAP-TLS). Note that other EAP methods
are also available to select.
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.
FORTINET
For the case of non 802.1X complaint devices that want to join the network, FortiAuthenticator offers the
option of 802.1X MAC-Based authentication. This section briefly examines the configuration required.
FORTINET
The MAC-based authentication feature is basically a list of MAC addresses that will be allowed in 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.
FORTINET
Once MAC-based authentication is enabled, you must create a list of allowed MAC addresses under 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 a MAC address 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.
FORTINET
Machine, or computer, authentication is a feature of the Windows client that allows a Windows machine to
authenticate to a network via 802.1X prior to user authentication.
FORTINET
Machine authentication is performed by the computer itself, which sends its computer object credentials
before the Windows logon screen appears. Machine authentication commonly occurs on boot up or log
out. FortiAuthenticator caches authenticated devices based on their MAC addresses for a configurable
period.
You can limit access to the network based on the machine credentials provided during authentication. For
example, you can grant access to just the Active Directory server to enable user authentication.
Once 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.
FORTINET
You can configure machine authentication on your RADIUS client through the Clients page. You must
enable Check machine authentication. You also have the option to override group membership.
Without the override groups configured, the user will be authenticated and dropped into 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 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 dropped onto a predefined VLAN (by using RADIUS Attributes assigned to the group).
FORTINET
We examined:
802.1X authentication
Supported EAP methods
Wireless 802.1X authentication
Wired 802.1X authentication
MAC-based authentication
Machine-based 802.1X authentication
FORTINET
In this lesson, we will show some basic troubleshooting tips for FortiAuthenticator.
FORTINET
After completing this lesson, you should have these practical skills that you can use to troubleshoot
FortiAuthenticator. This includes:
FORTINET
This sections outlines some of the more basic areas to check when troubleshooting FortiAuthenticator.
FORTINET
Its 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 (once configured, dont forget to set the default mail server!)
FORTINET
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.
FORTINET
Finally, to find general system and diagnostic information, you can use the status and hardware-info
commands through the CLI.
The status command displays the firmware build number, unit serial number, system time, disk
usage/size, and high availability status.
The hardware-info command displays information about the CPU, memory, disk, RAID, and system time.
FORTINET
This section examines using the FortiAuthenticator log files to troubleshoot issues.
FORTINET
From the Logs page on the Web-based manager, you can find the normal level of debugging required for
every day use. Log types include:
You can also download a debug report, which is encrypted, and send it to the FortiAuthenticator team for
further investigation if necessary.
FORTINET
This slide shows some example logs for portal login and RADIUS logon, with both user name and
password as well as token.
FORTINET
From 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!
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.
FORTINET
This section examines debugging FortiAuthenticator using network utilities, packet sniffers, and third-party
tools.
FORTINET
To test FortiAuthenticator network connectivity, you can use the ping, traceroute, and nslookup CLI
commands. The nslookup command is used to test DNS resolution. You can use either an IP address or
FQDN with ping and traceroute.
FORTINET
When troubleshooting network traffic, it helps to look inside the headers of packets to determine if they are
traveling along the route you expect.
FortiAuthenticators routing table has one entry per each directly connected subnet as well as one entry
per each static route. FortiAuthenticator always uses the most specific route to any destination.
From the CLI, you can use the tcpdump command. It is used to capture the packets being transmitted and
received by FortiAuthenticator on any interface. The command can be set to display packet summary from
the host, RADIUS packet summary from the host, and all packet content. The filter follows the standard
Berkeley Packet Filtering (BPF) syntax. Note that while the sniffer is running, you cannot type any other
CLI command in the same console session. You either need to open a new session or stop the sniffer by
pressing CTRL-C.
From the Web-based manager, you can use the packet sniffer from the Packet Capture page. To start
capturing packets on an interface, select Start capturing for that interface. The Status changes to
Capturing, and the Stop capturing and download buttons become available. The download file is a pcap
file which can be opened in a compatible protocol analyzer such as WireShark.
FORTINET
NTRADPing is a third-party test tool you can use to send RADIUS requests. It supports RADIUS
Authentication and RADIUS Accounting. When configuring the tool, remember to set the correct port.
FORTINET
Wireshark is another third-party test tool you can use. It supports the FortiAuthenticator Web-based
manager traffic capture file and can decrypt RADIUS packets. To do this you need to enter your RADIUS
secret under Preferences > Protocols > RADIUS.
FORTINET
This section includes some helpful tips into how to troubleshoot RADIUS.
FORTINET
When debugging RADIUS issues, ensure you verify the user configuration from 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.
RADIUS authentication is enabled by default, but you can disable it per user.
FORTINET
Is the RADIUS client IP correct? Remember, this could be changed by the NAT.
Is two-factor authentication enforced when the user has no token? Make sure the client has the correct
setting based on the authentication method of the users.
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? If so, ensure Use
Windows AD domain authentication is enabled.
Are you using RADIUS attributes to assign different authentication profiles? This is used in more
complicated deployments. Verify that an Access-Request attribute is not triggering a different profile.
FORTINET
If still experiencing issues with RADIUS, try the following three steps:
The first is to verify whether traffic is reaching FortiAuthenticator. Use the various tcpdump commands in
the CLI. If no traffic is reaching FortiAuthenticator, validate intervening firewall policies and the RADIUS
client configuration.
FORTINET
The second step is to check the log files. Try these 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 (i.e. it hasnt drifted).
You may also want to check the extended logs as well at http://<FortiAuthenticator_IP>/debug.
FORTINET
The third step is to reduce complexity of the RADIUS configuration. Normally this is not required, as the
logs provide enough information for troubleshooting purposes, but just in case try the following:
Remove two-factor authentication from the equation by disabling token from 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. Dont forget to add the laptop as an allowed RADIUS client in the FortiAuthenticator configuration!
FORTINET
Here are some common issues for RADIUS logon fails. In this scenario, the user exists on the system, but
RADIUS authentication fails. Logs say Authentication failed user not found.
To debug, verify the user is not configured as an admin. Administrators cannot authenticate via RADIUS
by default for security reasons (though this is configurable).
FORTINET
In this scenario, 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.
FORTINET
This section includes some helpful tips into how to troubleshoot Fortinet Single Sign-on (FSSO).
FORTINET
When debugging FSSO issues, ensure you verify the domain controller configuration from the Domain
Controllers page. Check whether the account is specified in the correct User Principal Name (UPN)
format. Ensure the domain controller wasnt disabled by accident. Lastly, check with your administrator
whether a secure connection is required.
FORTINET
You can find detailed logs in the FSSO debug log. In this example, it indicates that the wrong password is
being used.
FORTINET
The majority of FSSO issues can be traced back to incorrect permissions when querying LDAP or Active
Directory. This table outlines the feature, where it is located in FortiAuthenticator, and the minimum
Windows permissions required.
FORTINET