Introduction to authentication
Identifying users and other computers—authentication—is a key part of network security. This section describes some basic elements and concepts of authentication.
The following topics are included in this section:
- What is authentication?
- Methods of authentication
- Types of authentication
- User’s view of authentication
- FortiGate administrator’s view of authentication
What is authentication?
Businesses need to authenticate people who have access to company resources. In the physical world this may be a swipe card to enter the building, or a code to enter a locked door. If a person has this swipe card or code, they have been authenticated as someone allowed in that building or room.
Authentication is the act of confirming the identity of a person or other entity. In the context of a private computer network, the identities of users or host computers must be established to ensure that only authorized parties can access the network. The FortiGate unit enables controlled network access and applies authentication to users of security policies and VPN clients.
Methods of authentication
FortiGate unit authentication is divided into three basic types: password authentication for people, certificate authentication for hosts or endpoints, and two-factor authentication for additional security beyond just passwords. An exception to this is that FortiGate units in an HA cluster and FortiManager units use password authentication.
Password authentication verifies individual user identities, but access to network resources is based on membership in user groups. For example, a security policy can be configured to permit access only to the members of one or more user groups. Any user who attempts to access the network through that policy is then authenticated through a request for their username and password.
Methods of authentication include:
- Local password authentication
- Server-based password authentication
- Certificate-based authentication
- Two-factor authentication
Local password authentication
The simplest authentication is based on user accounts stored locally on the FortiGate unit. For each account, a username and password is stored. The account also has a disable option so that you can suspend the account without deleting it.
Local user accounts work well for a single-FortiGate installation. If your network has multiple FortiGate units that will use the same accounts, the use of an external authentication server can simplify account configuration and maintenance.
You can create local user accounts in the GUI under User & Device > User Definition. This page is also used to create accounts where an external authentication server stores and verifies the password.
Server-based password authentication
Using external authentication servers is desirable when multiple FortiGate units need to authenticate the same users, or where the FortiGate unit is added to a network that already contains an authentication server. FortiOS supports the use of LDAP, RADIUS, TACACS+, AD, or POP3 servers for authentication.
When you use an external authentication server to authenticate users, the FortiGate unit sends the user’s entered credentials to the external server. The password is encrypted. The server’s response indicates whether the supplied credentials are valid or not.
You must configure the FortiGate unit to access the external authentication servers that you want to use. The configuration includes the parameters that authenticate the FortiGate unit to the authentication server.
You can use external authentication servers in two ways:
- Create user accounts on the FortiGate unit. However, instead of storing each user’s password, specify the server used to authenticate that user. As with accounts that store the password locally, you add these users to appropriate user groups.
- Add the authentication server to user groups. Any user who has an account on the server can be authenticated and have the access privileges of the FortiGate user group. Optionally, when an LDAP server is a FortiGate user group member, you can limit access to users who belong to specific groups defined on the LDAP server.
Certificate-based authentication
An RSA X.509 server certificate is a small file issued by a certificate authority (CA) that is installed on a computer or FortiGate unit to authenticate itself to other devices on the network. When one party on a network presents the certificate as authentication, the other party can validate that the certificate was issued by the CA. The identification is therefore as trustworthy as the CA that issued the certificate.
To protect against compromised or misused certificates, CAs can revoke any certificate by adding it to a certificate revocation list (CRL). Certificate status can also be checked online using the Online Certificate Status Protocol (OCSP).
RSA X.509 certificates are based on public-key cryptography, in which there are two keys: the private key and the public key. Data encrypted with the private key can be decrypted only with the public key, and the other way round. As the names suggest, the private key is never revealed to anyone and the public key can be freely distributed. Encryption with the recipient’s public key creates a message that only the intended recipient can read. Encryption with the sender’s private key creates a message whose authenticity is proven because it can be decrypted only with the sender’s public key.
Server certificates contain a signature string encrypted with the CA’s private key. The CA’s public key is contained in a CA root certificate. If the signature string can be decrypted with the CA’s public key, the certificate is genuine.
Certificate authorities
A CA can be:
- an organization, such as VeriSign Inc., that provides certificate services
- a software application, such as Microsoft Certificate Services or OpenSSH
For a company web portal or customer-facing SSL VPN, a third-party certificate service has some advantages. The CA certificates are already included in popular web browsers and customers trust the third-party. On the other hand, third-party services have a cost.
For administrators and for employee VPN users, the local CA based on a software application provides the required security at low cost. You can generate and distribute certificates as needed. If an employee leaves the organization, you can simply revoke their certificate.
Certificates for users
FortiGate unit administrators and SSL VPN users can install certificates in their web browsers to authenticate themselves. If the FortiGate unit uses a CA-issued certificate to authenticate itself to the clients, the browser will also need the appropriate CA certificate.
FortiGate IPsec VPN users can install server and CA certificates according to the instructions for their IPsec VPN client software. The FortiClient Endpoint Security application, for example, can import and store the certificates required by VPN connections.
FortiGate units are also compatible with some Public Key Infrastructure systems. For an example of this type of system, see RSA ACE (SecurID) servers.
Two-factor authentication
A user can be required to provide both something they know (their username and password combination) and something they have (certificate or a random token code). Certificates are installed on the user’s computer.
Two-factor authentication is available for PKI users. For more information, see Certificate.
Another type of two-factor authentication is to use a randomly generated token (multi-digit number) along with the username and password combination. One method is a FortiToken — a one-time password (OTP) generator that generates a unique code every 60 seconds. Others use email or SMS text messaging to deliver the random token code to the user or administrator.
When one of these methods is configured, the user enters this code at login after the username and password have been verified. The FortiGate unit verifies the token code after as well as the password and username. For more information, see Two-factor authentication
Authentication binds to MAC address
In previous FortiOS versions, firewall authentication was source IP based, thus there was no action in response to a MAC address change. This was a security flaw that allowed an unauthenticated user to access restricted resources, especially in a WiFi environment where the IP and MAC binding changed frequently.
MAC addresses can now be bound with the user identity so that the MAC address is matched while matching an auth logon.
Types of authentication
FortiOS supports two different types of authentication based on your situation and needs: security policy authentication and Virtual Private Network (VPN) authentication.
Security policy authentication is easily applied to all users logging on to a network, or network service. For example if a group of users on your network such as the accounting department who have access to sensitive data need to access the Internet, it is a good idea to make sure the user is a valid user and not someone trying to send company secrets to the Internet. Security policy authentication can be applied to as many or as few users as needed, and it supports a number of authentication protocols to easily fit with your existing network.
VPN authentication enables secure communication with hosts located outside the company network, making them part of the company network while the VPN tunnel is operating. Authentication applies to the devices at both ends of the VPN and optionally VPN users can be authenticated as well.
Security policy authentication
Security policies enable traffic to flow between networks. Optionally, the policy can allow access only to specific originating addresses, device types, users or user groups. Where access is controlled by user or user group, users must authenticate by entering valid username and password credentials.
The user’s authentication expires if the connection is idle for too long, five minutes by default but that can be customized.
Security policies are the mechanism for FSSO, NTLM, certificate based, and RADIUS SSO authentication.
FSSO
Fortinet Single Sign on (FSSO) provides seamless authentication support for Microsoft Windows Active Directory (AD) and Novell eDirectory users in a FortiGate environment.
On a Microsoft Windows or Novell network, users authenticate with the Active Directory or Novell eDirectory at login. FSSO provides authentication information to the FortiGate unit so that users automatically get access to permitted resources. See Introduction to agent-based FSSO.
NTLM
The NT LAN Manager (NTLM) protocol is used when the MS Windows Active Directory (AD) domain controller can not be contacted. NTLM is a browser-based method of authentication.
The FSSO software is installed on each AD server and the FortiGate unit is configured to communicate with each FSSO client. When a user successfully logs into their Windows PC (and is authenticated by the AD Server), the FSSO client communicates the user's name, IP address, and group login information to the FortiGate unit. The FortiGate unit sets up a temporary access policy for the user, so when they attempt access through the firewall they do not need to re-authenticate. This model works well in environments where the FSSO client can be installed on all AD servers.
In system configurations where it is not possible to install FSSO clients on all AD servers, the FortiGate unit must be able to query the AD servers to find out if a user has been properly authenticated. This is achieved using the NTLM messaging features of Active Directory and Internet Explorer.
Even when NTLM authentication is used, the user is not asked again for their username and password. Internet Explorer stores the user’s credentials and the FortiGate unit uses NTLM messaging to validate them in the Windows AD environment.
Note that if the authentication reaches the timeout period, the NTLM message exchange restarts. For more information on NTLM, see NTLM authentication and FSSO NTLM authentication support.
Certificates
Certificates can be used as part of a policy. All users being authenticated against the policy are required to have the proper certificate. See Certificate-based authentication
RADIUS SSO
RADIUS Single Sign-On (RSSO) is a remote authentication method that does not require any local users to be configured, and relies on RADIUS Start records to provide the FortiGate unit with authentication information. That information identifies the user and user group, which is then matched using a security policy. See SSO using RADIUS accounting records.
FortiGuard web filter override authentication
Optionally, users can be allowed the privilege of overriding FortiGuard Web Filtering to view blocked web sites. Depending on the override settings, the override can apply to the user who requested it, the entire user group to which the user belongs, or all users who share the same web filter profile. As with other FortiGate features, access to FortiGuard overrides is controlled through user groups. Firewall and Directory Services user groups are eligible for the override privilege. For more information about web filtering and overrides, see the UTM chapter of this FortiOS Handbook.
VPN authentication
Authentication involves authenticating the user. In IPsec VPNs authenticating the user is optional, but authentication of the peer device is required.
This section includes:
- Authenticating IPsec VPN peers (devices)
- Authenticating IPsec VPN users
- Authenticating SSL VPN users
- Authenticating PPTP and L2TP VPN users
Authenticating IPsec VPN peers (devices)
A VPN tunnel has one end on a local trusted network, and the other end is at a remote location. The remote peer (device) must be authenticated to be able to trust the VPN tunnel. Without that authentication, it is possible for a malicious hacker to masquerade as a valid VPN tunnel device and gain access to the trusted local network.
The three ways to authenticate VPN peers are with a pre-shared key, RSA X.509 certificate, or a specific peer ID value.
The simplest way for IPsec VPN peers to authenticate each other is through the use of a pre-shared key, also called a shared secret. The pre-shared key is a text string used to encrypt the data exchanges that establish the VPN tunnel. The pre-shared key must be six or more characters. The VPN tunnel cannot be established if the two peers do not use the same key. The disadvantage of pre-shared key authentication is that it can be difficult to securely distribute and update the pre-shared keys.
RSA X.509 certificates are a better way for VPN peers to authenticate each other. Each peer offers a certificate signed by a Certificate Authority (CA) which the other peer can validate with the appropriate CA root certificate. For more information about certificates, see Certificate-based authentication.
You can supplement either pre-shared key or certificate authentication by requiring the other peer to provide a specific peer ID value. The peer ID is a text string configured on the peer device. On a FortiGate peer or FortiClient Endpoint Security peer, the peer ID provided to the remote peer is called the Local ID.
Authenticating IPsec VPN users
An IPsec VPN can be configured to accept connections from multiple dynamically addressed peers. You would do this to enable employees to connect to the corporate network while traveling or from home. On a FortiGate unit, you create this configuration by setting the Remote Gateway to Dialup User.
It is possible to have an IPsec VPN in which remote peer devices authenticate using a common pre-shared key or a certificate, but there is no attempt to identify the user at the remote peer. To add user authentication, you can do one of the following:
- require a unique pre-shared key for each peer
- require a unique peer ID for each peer
- require a unique peer certificate for each peer
- require additional user authentication (XAuth)
The peer ID is a text string configured on the peer device. On a FortiGate peer or FortiClient Endpoint Security peer, the peer ID provided to the remote peer is called the Local ID.
Authenticating SSL VPN users
SSL VPN users can be
- user accounts with passwords stored on the FortiGate unit
- user accounts authenticated by an external RADIUS, LDAP or TACACS+ server
- PKI users authenticated by certificate
You need to create a user group for your SSL VPN. Simply create a firewall user group, enable SSL VPN access for the group, and select the web portal the users will access.
SSL VPN access requires an SSL VPN security policy that permits access to members of your user group.
Authenticating PPTP and L2TP VPN users
PPTP and L2TP are older VPN tunneling protocols that do not provide authentication themselves. FortiGate units restrict PPTP and L2TP access to users who belong to one specified user group. Users authenticate themselves to the FortiGate unit by username/password. You can configure PPTP and L2TP VPNs only in the CLI. Before you configure the VPN, create a firewall user group and add to it the users who are permitted to use the VPN. Users are authenticated when they attempt to connect to the VPN. For more information about configuring PPTP or L2TP VPNs, see the FortiGate CLI Reference.
Single sign-on authentication for users
Single sign-on (SSO)means that users logged on to a computer network are authenticated for access to network resources through the FortiGate unit without having to enter their username and password again. FortiGate units directly provide SSO capability for:
- Microsoft Windows networks using either Active Directory or NTLM authentication
- Novell networks, using eDirectory
In combination with a FortiAuthenticator unit, the FortiGate unit can provide SSO capability that integrates multiple external network authentication systems such as Windows Active Directory, Novell e-Directory, RADIUS and LDAP. The FortiAuthenticator unit gathers user logon information from all of these sources and sends it to the FortiGate unit.
Through the SSO feature, the FortiGate unit knows the username, IP address, and external user groups to which the user belongs. When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups, the connection is allowed.
For detailed information about SSO, see
User’s view of authentication
From the user’s point of view, they see a request for authentication when they try to access a protected resource, such as an FTP repository of intellectual property or simply access a website on the Internet. The way the request is presented to the user depends on the method of access to that resource.
VPN authentication usually controls remote access to a private network.
Web-based user authentication
Security policies usually control browsing access to an external network that provides connection to the Internet. In this case, the FortiGate unit requests authentication through the web browser.
The user types a username and password and then selects Continue or Login. If the credentials are incorrect, the authentication screen is redisplayed with blank fields so that the user can try again. When the user enters valid credentials, access is granted to the required resource. In some cases, if a user tries to authenticate several times without success, a message appears, such as: “Too many bad login attempts. Please try again in a few minutes.” This indicates the user is locked out for a period of time. This prevents automated brute force password hacking attempts. The administrator can customize these settings if required.
|
After a defined period of user inactivity (the authentication timeout, defined by the FortiGate administrator), the user’s access expires. The default is 5 minutes. To access the resource, the user will have to authenticate again. |
VPN client-based authentication
A VPN provides remote clients with access to a private network for a variety of services that include web browsing, email, and file sharing. A client program such as FortiClient negotiates the connection to the VPN and manages the user authentication challenge from the FortiGate unit.
FortiClient can store the username and password for a VPN as part of the configuration for the VPN connection and pass them to the FortiGate unit as needed. Or, FortiClient can request the username and password from the user when the FortiGate unit requests them.
|
|
Social ID data from FortiClient is recorded so that if an email or phone number is changed on FortiClient, the new values are updated on the FortiGate. The data is sent in KeepAlive messages in the following format:
|
SSL VPN is a form of VPN that can be used with a standard Web browser. There are two modes of SSL VPN operation (supported in NAT mode only):
- web-only mode, for remote clients equipped with a web-browser only
- tunnel mode, for remote computers that run a variety of client and server applications.
|
|
After a defined period of user inactivity on the VPN connection (the idle timeout, defined by the FortiGate administrator), the user’s access expires. The default is 30 minutes. To access the resource, the user will have to authenticate again. |
FortiGate administrator’s view of authentication
Authentication is based on user groups. The FortiGate administrator configures authentication for security policies and VPN tunnels by specifying the user groups whose members can use the resource. Some planning is required to determine how many different user groups need to be created. Individual user accounts can belong to multiple groups, making allocation of user privileges very flexible.
A member of a user group can be:
- a user whose username and password are stored on the FortiGate unit
- a user whose name is stored on the FortiGate unit and whose password is stored on a remote or external authentication server
- a remote or external authentication server with a database that contains the username and password of each person who is permitted access
The general process of setting up authentication is as follows:
- If remote or external authentication is needed, configure the required servers.
- Configure local and peer (PKI) user identities. For each local user, you can choose whether the FortiGate unit or a remote authentication server verifies the password. Peer members can be included in user groups for use in security policies.
- Create user groups.
- Add local/peer user members to each user group as appropriate. You can also add an authentication server to a user group. In this case, all users in the server’s database can authenticate. You can only configure peer user groups through the CLI.
- Configure security policies and VPN tunnels that require authenticated access.
For authentication troubleshooting, see the specific chapter for the topic or for general issues see Troubleshooting.
General authentication settings
Go to User & Device > Authentication Settings to configure authentication timeout, protocol support, and authentication certificates.
When user authentication is enabled within a security policy, the authentication challenge is normally issued for any of the four protocols (depending on the connection protocol):
- HTTP (can also be set to redirect to HTTPS)
- HTTPS
- FTP
- Telnet
The selections made in the Protocol Support list of Authentication Settings control which protocols support the authentication challenge. Users must connect with a supported protocol first so they can subsequently connect with other protocols. If HTTPS is selected as a method of protocol support, it allows the user to authenticate with a customized Local certificate.
When you enable user authentication within a security policy, the security policy user will be challenged to authenticate. For user ID and password authentication, users must provide their user names and passwords. For certificate authentication (HTTPS or HTTP redirected to HTTPS only), you can install customized certificates on the unit and the users can also have customized certificates installed on their browsers. Otherwise, users will see a warning message and have to accept a default Fortinet certificate.
| Authentication Timeout | Enter a length of time in minutes, from 1 to 1440 minutes (24 hours). Authentication timeout controls how long an authenticated firewall connection can be idle before the user must authenticate again. The default value is 5. |
| Protocol Support | Select the protocols to challenge during firewall user authentication. |
| Certificate | If using HTTPS protocol support, select the local certificate to use for authentication. Available only if HTTPS protocol support is selected. |
| Apply | Select to apply the selections for user authentication settings. |