What to configure
You need to decide which elements of the FortiAuthenticator configuration you need:
- Determine the type of authentication you will use: password-based or token-based. Optionally, you can enable both types. This is called two-factor authentication.
- Determine the type of authentication server you will use: RADIUS, TACACS+, built-in LDAP, or Remote LDAP. You will need to use at least one of these server types.
- Determine which FortiGate units or third-party devices will use the FortiAuthenticator. The FortiAuthenticator must be configured on each FortiGate unit as an authentication server, either RADIUS or LDAP. For RADIUS authentication, each FortiGate or third-party device must be configured on the FortiAuthenticator as an authentication client.
Password-based authentication
User accounts can be created on the FortiAuthenticator device in multiple ways:
- Administrator creates a user and specifies their username and password.
- Administrator creates a username and a random password is automatically emailed to the user.
- Users are created by importing either a CSV file or from an external LDAP server.
Users can self-register for password-based authentication. This reduces the workload for the system administrator. Users can choose their own passwords or have a randomly generated password provided in the browser or sent to them via email or SMS. Self-registration can be instant, or it can require administrator approval. See Self-service portal policies.
Once created, users are automatically part of the RADIUS Authentication system and can be authenticated remotely.
See User management for more information about user accounts.
Two-factor authentication
Two-factor authentication increases security by requiring multiple pieces of information on top of the username and password. There are generally two factors:
- Something the user knows, usually a password,
- Something the user has, such as a FortiToken device.
Requiring the two factors increases the difficulty for an unauthorized person to impersonate a legitimate user.
To enable two-factor authentication, configure both password-based and token-based authentication in the user’s account.
FortiAuthenticator token-based authentication requires the user to enter a numeric token, or one-time password (OTP), at login. Two types of numerical tokens are supported:
- Time-based (TOTP): The token passcode is generated using a combination of the time and a secret key which is known only by the token and the FortiAuthenticator device. The token password changes at regular time intervals, and FortiAuthenticator is able to validate the entered passcode using the time and the secret seed information for that token.
- FortiToken hardware
- FortiToken Mobile, running on a compatible smartphone
Passcodes can only be used a single time (one time passcodes) to prevent replay attacks. Fortinet has the following time based tokens:
For more information about TOTP, see RFC 6238.
- Event-based or HMAC-based (HOTP): The token passcode is generated using an event trigger and a secret key. Event tokens are supported using a valid email account and a mobile phone number with SMS service.
FortiToken devices, FortiToken Mobile apps, email addresses, and phone numbers must be configured in the user’s account.
For more information about HOTP, see RFC 4226.
Only the administrator can configure token-based authentication. See Configuring One-Time Password (OTP) authentication.
Two-factor token and password concatenation
Concatenated passwords and one-time password (OTP) codes can be provided by the client in the password field so that there is no second step to enter an OTP code. This is supported by all authentication methods on the FortiAuthenticator that also support password-only authentication. See Authentication methods.
One-time activation protection for FortiToken on-boarding
One-time activation minimizes the risk of a bad actor stealing a token provisioned to an end-user.
FortiToken Mobile software tokens:
End-users receive an activation code as text and QR code to install the FortiToken Mobile token in the FortiToken Mobile application. The activation code is used to request a token seed for a previously provisioned token and does not contain the token seed. The activation window, during which the activation code is valid, is configurable. When the end-user activates the token, the FortiToken Mobile application sends a unique device fingerprint (device Id) to the FortiGuard FortiToken Mobile server. This device Id binds the token to the device by serving as a critical material to encrypt the token seed. Therefore, only that device can decrypt the seed after it is installed. This prevents a “backup and restore” or cloning attack on the token seed.
Further, the FortiGuard FortiToken Mobile server will only honor a successive activation request if the device Id matches the one sent in the original activation request and is within the activation window. This guarantees that the FortiToken Mobile activation codes cannot be reused, and tokens cannot be stolen if the activation code is somehow leaked after the token is installed. Suppose an attacker intercepts the activation code and tries to activate the token before the intended user can. In that case, the intended user will know since they cannot activate that token on their mobile device and will report the issue.
FortiToken Hardware tokens:
Standard FTK200B tokens are activated from the server device console or GUI by requesting the token seed from the secure FortiGuard FTK Activation Service. FortiGuard records the identity of the device from which token activation request originated. Thereafter, requests to activate the same token, as identified by the token Serial Number, will only be allowed from the server device on which it was originally activated.
Authentication servers
FortiAuthenticator has built-in RADIUS and LDAP servers. It also supports the use of remote RADIUS and LDAP (which can include Windows AD servers).
The built-in servers are best used where there is no existing authentication infrastructure, or when a separate set of credentials is required. You build a user account database on FortiAuthenticator. The database can include additional user information such as street addresses and phone numbers that cannot be stored in a FortiGate unit’s user authentication database. To authenticate, either LDAP or RADIUS can be used. The remote LDAP option adds your FortiGate units to an existing LDAP structure. Optionally, you can add two-factor authentication to remote LDAP.
RADIUS
If you use RADIUS, you must enable RADIUS in each user account. FortiGate units must be registered as RADIUS authentication clients under Authentication > RADIUS Service > Clients. See RADIUS service. On each FortiGate unit that will use the RADIUS protocol, FortiAuthenticator must be configured as a RADIUS server under User & Device > RADIUS Servers.
Built-in LDAP
If you use built-in LDAP, you will need to configure the LDAP directory tree. You add users from the user database to the appropriate nodes in the LDAP hierarchy. See Creating the directory tree. On each FortiGate unit that will use LDAP protocol, FortiAuthenticator must be configured as an LDAP server under User & Device > LDAP Servers.
Remote LDAP
Remote LDAP is used when an existing LDAP directory exists and should be used for authentication. User information can be selectively synchronized with FortiAuthenticator, but the user credentials (passwords) remain on, and are validated against the LDAP directory.
To utilize remote LDAP, the authentication client (such as a FortiGate device) must connect to the FortiAuthenticator device using RADIUS to authenticate the user information (see User & Device > RADIUS Servers). The password is then proxied to the LDAP server for validation, while any associated token passcode is validated locally.
Authentication methods
RADIUS and TACACS+ with PAP, user portals, SAML IdP, and REST API:
- End-user password provided to FortiAuthenticator as cleartext.
- Any type of user account (i.e. local or remote) can authenticate.
RADIUS with CHAP/MSCHAPv2:
- End-user password provided to FortiAuthenticator as a hash digest.
- Only local user accounts with passwords stored using reversible cryptography can authenticate. See Local user account password storage
Machine authentication
Machine (or computer) authentication is a feature of the Windows supplicant that allows a Windows machine to authenticate to a network via 802.1X prior to user authentication.
Machine authentication is performed by the computer itself, which sends its computer object credentials before the Windows logon screen appears. User authentication is performed after the user logs in to Windows.
Based on the computer credentials provided during machine authentication, limited access to the network can be granted. For example, access can be granted to just the Active Directory server to enable user authentication.
Following machine authentication, user authentication can take place to authenticate that the user is also valid, and to then grant further access to the network.
Machine authentication commonly occurs on boot up or log out, and not, for example, when a device awakens from hibernation. Because of this, the FortiAuthenticator caches authenticated devices based on their MAC addresses for a configurable period (see User account policies). For more information on cached users, see Windows device logins
To configure machine authentication, see RADIUS service.