FGT1 04 Firewall Authentication V2 PDF

DO NOT REPRINT
FORTINET
Firewall Authentication
In this lesson, we will show you how to use authentication on the firewall policies of a FortiGate.
Normal firewall policies involve separating devices based on the IP address or subnet involved.
Adding authentication to firewall policies, however, provides a mechanism to make decisions on not
just where the device is, but who is using the device.
DO NOT REPRINT
FORTINET
After completing this lesson, you should have a solid understanding of the mechanics of authentication
on a FortiGate as well as some practical skills configuring firewall authentication.
DO NOT REPRINT
FORTINET
Traditional firewalling grants network access by authenticating the source IP address only. This is
inadequate, as the firewall cannot determine who is using the device to which it is granting access.
This can pose a security risk.
Authentication allows action based on the user, not just the IP address. In this way, inspection rules
follow individuals across multiple devices.
DO NOT REPRINT
FORTINET
Not all available methods of authentication can be used for firewall authentication (for example,
certificate-based authentication cannot be used). You can, however, use local password
authentication, remote password authentication, and two-factor authentication. Two-factor
authentication is slightly different from the others, as it is enabled on top of an existing methodit
cannot be enabled without first configuring one of the other methods.
In this lesson, we will discuss all three available methods.
DO NOT REPRINT
FORTINET
The first and simplest method of authentication is Local Password Authentication. User account
information (user name and password) is stored locally on the FortiGate device, so there is no lookup
to an external server for user validation.
Local Password Authentication is the simplest method of authentication to configure, since you only
need access to the FortiGate. Other methods of authentication are more complex, as they involve
configuring the exchange of information between the FortiGate and a remote server as well as
configuring the various users and user groups on the server itself. Troubleshooting in those situations
becomes more complicated, as you need to examine both the FortiGate and external server. With
Local Password Authentication, you need only examine the FortiGate.
DO NOT REPRINT
FORTINET
The second method of authentication is remote server authentication (or server-based password
authentication). This includes any form of authentication where the final decision on user credentials is
made by an external servernot the FortiGate. This method is desirable when multiple FortiGate
devices need to authenticate the same users or user groups.
With remote server authentication, user information is sent from the FortiGate to a remote server. The
remote server then evaluates the information it receives and sends a response. The server response
is examined by FortiGate and consults its configuration to deal with the traffic. However, it is the
server not the FortiGate that has final authority over evaluating the user credentials.
With Remote Server Authentication, the FortiGate does not store all (or, in the case of some
configurations, any) of the user information locally.
DO NOT REPRINT
FORTINET
Multiple protocols are supported for remote user authentication, including POP3, RADIUS (includes
server authentication and the single sign on method, RSSO), LDAP, and TACACS+.
Single sign on (SSO) methods, such as FSSO, NTML, and RSSO, are also supported for remote user
authentication.
DO NOT REPRINT
FORTINET
With a FortiGate, you can implement Single Sign On (SSO) using FSSO and RSSO.
SSO allows a single login event to be used for all authentication and access situations. Without SSO,
if a user logs in to a Wi-Fi network, they will need to log in through a firewall policy separately when
they try to pass traffic. SSO links multiple authentication events to a single event.
DO NOT REPRINT
FORTINET
One remote server authentication protocol worth mentioning is POP3, as the login credentials the
remote server accepts is different from most other authentication protocols. Most other authentication
protocols user the user name. POP3 servers, however, authenticate users based on email address.
Some POP3 servers require the full email with domain (user@example.com), others require the suffix
only, while still others accept both formats. This is determined by the configuration of the server itself
and is not a setting on the FortiGate. You can only configure POP3 authentication though the CLI.
You can also use LDAP to validate with email, rather than the user name.
DO NOT REPRINT
FORTINET
The third, and final, method of authentication for firewalls which is really just an extension of an
existing authentication method is two-factor authentication.
Traditional user authentication requires your user name plus something you know, such as a
password. The weakness with this traditional method of authentication is that if someone obtains your
user name, they only need your password to compromise your account. Furthermore, since people
tend to use the same password across multiple accounts (some sites with more security vulnerabilities
than others), accounts are vulnerable to attack, regardless of password strength.
Two-factor authentication, on the other hand, requires something you know, such as a password, and
something you have, such as a token. This increases the complexity for an attacker to compromise an
account, as it puts less importance on often-vulnerable passwords. With this authentication method,
security is split between two different options: both a password and a key of some kind.
DO NOT REPRINT
FORTINET
One-time passwords are one such method you can use with Two-Factor Authentication as something
you have. FortiToken and FortiToken Mobile (hardware and software respectively) both generate
one-time passwords. The passwords for both FortiToken and FortiToken Mobile generate every 60
seconds.
You can deliver OTP through alternative methods, other than providing the end user with a token or
mobile app. For example, you can send an OTP through email or through an SMS phone message.
It is very important that FortiTokens are synchronized with the FortiGate. Otherwise FortiGate cannot
predict the correct string to use.
DO NOT REPRINT
FORTINET
Tokens use a specific algorithm to generate a one-time password. The algorithm consists of:
a seed, which is a randomly-generated number that does not change in time, and
the time, which is obtained from an internal, accurate, clock
Both seed and time go through an algorithm that generates a one-time password on the token. The
OTP has a short life span, usually measured in seconds (60 seconds for a FortiToken, possibly
more/less for other RSA key generators). Once the life span ends, for example after 60 seconds, a
new one generates.
With two-factor authentication using a token, the user must first log in with a static password followed
by the OTP (or code) generated by the token. A validation server (a FortiGate) receives the users
credentials and validates the static password first. The validation server then proceeds to validate the
OTP. It does so by re-generating the same OTP using the seed and system time (which is
synchronized with the one on the token) and comparing it with the one received from the user. If the
static password is valid, and the one-time password matches, the user is successfully authenticated.
Again, both the token and the validation server must use the same seed and have synchronized
system clocks. As such, it is crucial that you configure your FortiGates date/time properly or link it to
an NTP server.
DO NOT REPRINT
FORTINET
To use a FortiToken, you must first register it on a FortiGate device. Whether its a hardware or
software token, a serial number is used to provide the FortiGate with details on the initial seed value.
If you are using FortiToken Mobile, each FortiGate (and FortiGate VM) allows for two free activations.
More than this requires the purchase of activations codes for additional mobile tokens from Fortinet.
You cannot register FortiTokens on more than one FortiGate. A deployment like that requires the use
of a central FortiAuthenticator. In that case, the FortiTokens are registered on the FortiAuthenticator
and not the FortiGate. FortiGate uses FortiAuthenticator as its validation server, which allows the
same FortiToken to be used for access on multiple FortiGate devices.
DO NOT REPRINT
FORTINET
Not all types of authentication involve prompting the user to enter their login credentials. While active
authentication (used with LDAP, RADIUS, Local Password Authentication, and TACACS+) prompts
the user to manually enter credentials, passive authentication (used with FSSO, RSSO, and NTLM)
determines user information without ever asking the user to log in. Passive authentication, therefore,
occurs transparently for the user.
DO NOT REPRINT
FORTINET
Active authentication prompts the user based on:

the protocol of the traffic they use to try and pass through a firewall, and
the firewall policy itself
The policy must specify the authentication protocols allowed, such as HTTP/S, FTP, and Telnet. If the
policy that has authentication enabled does not allow at least one of the supported protocols for
obtaining user credentials, the user will not be able to authenticate.
Passive authentication determines the user identity behind the scenes and does not require any
specific services to be allowed within the policy.
DO NOT REPRINT
FORTINET
You can enable both active and passive authentication. If both active and passive authentication are
enabled and a users credentials can be determined through passive means, then the user will never
receive a login prompt, regardless of the order of any firewall policies. This is because there is no
need to prompt the user for active authentication credentials when passive authentication can
determine who they are. When active and passive authentication methods are combined, active
authentication is intended to be used as a backup only for when passive authentication fails.
No one method of authentication is considered more important than another. The first method that can
determine a user name for any traffic is the deciding factor. Ultimately that determines how the traffic
is handled.
DO NOT REPRINT
FORTINET
A firewall policy defines and matches traffic going from the source to the destination.
An IP address is required as part of the policy configuration for the source and destination. User, user
group, and device information can be enabled as well. If enabled, they become part of the source
definition for that policy. Accordingly, a source is comprised of source address(es)+source
user(s)/group(s)+source device(s).
DO NOT REPRINT
FORTINET
No service (with the exception of DNS) is allowed through the firewall policy prior to successful user
authentication. DNS is allowed because it is a base protocol and will most likely be required to initially
see proper authentication protocol traffic. Hostname resolution is almost always a requirement for any
protocol. However, the DNS service must still be defined as allowed within the policy in order for it to
pass.
In the following example, Policy #1 allows users to use external DNS servers on the other side of
port2 in order to resolve host names, prior to successful authentication. Therefore, the DNS traffic is
allowed through even before authentication happens. It is also allowed if authentication is
unsuccessful, as users need to be able to try to authenticate again. Any service that includes DNS
would function the same way, like the default ALL service.
Policy #2, on the other hand, never allows DNS traffic, even after successful authentication. The
HTTP service is TCP port 80 and does not include DNS (UDP port 53).
DO NOT REPRINT
FORTINET
In this example, assuming active authentication is used, any initial traffic from the 10.10.1.0/24 subnet
will not match policy #1. Policy 1 looks at the IP as well as the user information, and since the user
has not authenticated there is no match.
Next, a check is made against policy #2. There is a match and traffic is allowed with no need to
authenticate.
When only active authentication is used, if all possible policies that could match the source IP have
authentication enabled, then the user will receive a login prompt (assuming they use an acceptable
login protocol). In other words, if policy #2 also had authentication enabled, the users would receive
login prompts.
If passive authentication is used and it can successfully obtain user details, then traffic form
10.10.1.0/24 with users that belong to the guest-group will apply to policy #1 even though policy #2
does not have authentication enabled.
DO NOT REPRINT
FORTINET
If you want all users connecting to the network to authenticate through active authentication, you can
enable the captive portal. With captive portal, network interfaces perform authentication at the
interface levelregardless of the firewall policy that allows it or the port that it ultimately leaves by
(authentication being enabled or disabled on the policy is not a factor). Essentially, a captive portal is a
convenient way to authenticate web users on wired or Wi-Fi networks through an HTML form that
requests the users name and password. You can host a captive portal on a FortiGate device or an
external authentication server.
The captive portal setting must be enabled on the Ingress interface of the traffic. Captive portals are
not compatible with interfaces in DHCP mode.
DO NOT REPRINT
FORTINET
Using the previous example, with captive portal enabled on port 1 all traffic from behind port 1 would
receive a login prompt, not just the users in the 10.10.1.0/24 subnet or traffic that may be going
somewhere other then port 2.
Passive authentication never requires a captive portal, since it obtains user details differently. Only
active authentication methods can use the captive portal feature (depending on the configuration).
DO NOT REPRINT
FORTINET
A firewall policy can have the captive portal suppressed. When suppressed, traffic that matches the
source and destination are not presented with the captive portal page. The captive-portal-exempt
setting must be enabled in the CLI for each firewall policy and only applies to traffic that matches that
policy. The security-exempt-list CLI setting, however, applies those sources at all times, regardless of
the firewall policy settings.
Depending on the configuration, one option or the other usually results in simplifying your
configuration more. Use the option that best fits the requirements of the situation and results in less
confusion or ongoing maintenance.
You can create and configure security exempt lists only from the CLI. However, you can enable them
through the GUI settings.
DO NOT REPRINT
FORTINET
You can enable disclaimers to be used in conjunction with captive portal, if desired. Disclaimers are
not considered authentication or a captive portal, but the two tend to go hand-in-hand. With the
authentication and disclaimer setting, the disclaimer appears before the user authenticates and acts
as a reminder of the rules for the network. Under this setting, users must accept the terms in the
disclaimer in order to proceed with the authentication process.
Neither a security exemption list nor a captive portal exemption on a firewall can bypass a disclaimer.
DO NOT REPRINT
FORTINET
Any time FortiGate is required to jump into the traffic stream (with authentication pages or disclaimers
for example), you can modify the particulars of the block page through the GUI.
Editing HTML-related block message requires knowledge of HTML, to ensure proper positioning and
look of the page. The default layout is the Simple View, which hides most of the replacement
messages. Use Extended View to show all editable replacement messages.
DO NOT REPRINT
FORTINET
An authentication timeout ensures users do not authenticate and then stay in memory indefinitely. If
users stay in memory forever, it would eventually lead to memory exhaustion.
There are three options for timeout behavior:
IDLE Looks at the packets from the hosts IP. If there are no packets generated by the host device
in the configured timeframe then the user is logged out.
HARD Time is an absolute value. Regardless of the users behavior, the timer starts as soon as
the user authenticates and expires after the configured value.
NEW SESSION Even if traffic is being generated on existing communications channels, the
authentication expires if no new sessions are created through the firewall from the host device,
within the configured timeout.
Choose the type of timeout that best suits the needs of authentication in your environment.
DO NOT REPRINT
FORTINET
Weve mentioned users and user groups several times in this lesson. Now, well take a closer look at
how both users and user groups are used by FortiGate for firewall authentication. Before that,
however, well give a short refresher on how you create users and groups on an external server, which
is useful if Remote Password Authentication is used as a method of authentication.
DO NOT REPRINT
FORTINET
LDAP is a standard remote authentication protocol currently supported by the FortiGate device. The
behavior of LDAP is defined through multiple RFCs.
LDAP is an application protocol for distributed directory information services. It can also be viewed as
a database that contains user accounts, among other things. The structure of this database is similar
to a tree that contains entries (or objects) in each branch. Each of these objects has a unique
identifier, which is called the distinguished name (or DN). The objects also have attributes, and each
attribute has a name and one or more values. This structure is defined in what is called a directory
schema.
DO NOT REPRINT
FORTINET
The hierarchy of an LDAP schema is not required to hold any resemblance to the organization.
However, generally the name conventions used and the group structure match with the name of the
company and corporate hierarchy very closely.
DO NOT REPRINT
FORTINET
On the top, we have the root or DC. This is where an LDAP tree always starts, with any schema.
After that the groups are defined using C, OU, and/or O. The exact behavior and options used depend
on the schema and what exactly is being defined. At the end of the tree is the UID, which contains
specific details about a particular user.
The full path to find a user contains all of the information necessary in order to locate a user within the
tree structure. This means you will need the DN (somewhere to start), the group information (C, OU,
O), and the UID.
DO NOT REPRINT
FORTINET
What you enter for the LDAP configuration depends heavily on the servers schema and security
settings. Windows Active Directory is very common.
Common Name Identifier is the attribute name to look up in order to find the user name. Some
schemas will call this UID, Active Directory calls it sAMAccountName or sometimes cn.
Distinguished Name identifies the top of the tree to look in. Generally this will be a DC value.
The Bind Type setting will vary, depending on the security settings of the LDAP server. Normally,
this will need to be Regular, with the credentials being for a user, that is authorized perform LDAP
queries.
DO NOT REPRINT
FORTINET
To see if a users credentials can successfully authenticate or not, you must use the CLI or enable to
authentication on a firewall policy. The GUI will only test if the initial LDAP connection to the server is
successful or not.
Because the GUI only tests success/failure, either look at the server logs or run a packet sniff to see
both sides of the LDAP communications so you can find out exactly what is happening. Exact output
will vary depending the Hierarchy of the LDAP server that was queried.
diagnose test authserver can be used to test most (not all) methods of authentication.
DO NOT REPRINT
FORTINET
RADIUS doesnt have the same kind of behavior as LDAP, as there is no tree structure to consider.
Normal authentication queries with the RADIUS protocol begin with an Access-Request being sent
from the FortiGate to the RADIUS server. Valid responses to this are Access-Accept and AccessReject (yes and no effectively).
If Two-Factor Authentication is enabled on the server, it will come back with an Access-Challenge
message, where it is essentially looking for more information. Any other response from the server is
not considered to be a valid response.
DO NOT REPRINT
FORTINET
RADIUS configuration on a FortiGate is straightforward.

The servers location needs to be defined along with the secret that was set up in order for the server
to allow remote queries. Backup servers (with separate secrets) can be defined in case the primary
server fails.
DO NOT REPRINT
FORTINET
Testing RADIUS is much the same as LDAP. The GUI can test the connection to the server, but not a
user login. Make sure that authentication is operational prior to implementing it on any of your firewall
policies.
Like LDAP, it reports success, failure, and group membership details depending on the servers
response. Deeper troubleshooting requires server access.
DO NOT REPRINT
FORTINET
Now that weve examined how to create users on the LDAP or RADIUS server, lets look at how to
create the firewall users and groups on the FortiGate. This is the first step to authentication: creating
firewall users and groups.
You can create firewall authentication users through the Users & Devices > User > User Definition
page of the FortiGate GUI. A wizards walks you through the creation process.
You are required to define the type of user (Local or Remote) and the user credentials. For remote
authentication, you must select the server to authenticate as well. There are other optional settings
available, such as adding contact information , enabling Two-Factor Authentication, or adding the user
to a User Group.
DO NOT REPRINT
FORTINET
Once youve made user accounts, you can assign firewall policies to them. But rather than assign
firewall policies to act on individual users, you can put users into groups with policies making
decisions based on the group itself. These groups are known as user groups. By assigning individual
users to the appropriate user groups, you can control access to network resources. You can define
both local and remote user groups on a FortiGate device. There are four user group types:
Firewall
Fortinet Single Sign On (FSSO)
Guest, and
RADIUS Single Sign On (RSSO)
The firewall user groups do not need to match any sort of group that may already exist on a server.
The firewall user groups exist solely to make configuration of firewall policies easier.
Note that most authentication types have the option to make decisions based on the individual user,
rather than just user groups.
DO NOT REPRINT
FORTINET
As mentioned, one of the four user group types is Guest. Guest groups are user groups that
exclusively contain temporary user accounts (the whole account, not just the password), and are most
commonly used in wireless networks. Guest accounts expire after a predetermined amount of time.
You can automatically create guest users on the fly, or manual create them through an admin user.
You can create special admin users that only have access to create and manage guest user accounts.
DO NOT REPRINT
FORTINET
You can configure user groups through the FortiGate GUI under User & Device > User > User Group.
You must specify the user group type, the local users that belong to the group, and the remote
authentication server(s) that contain the users that belong to the user group.
User groups simplify your configuration if you want to treat specific users in the same way. For
example, if you want to provide all Accountants with access to the same network resources. If you
want to treat all users differently, you would need to add all users to firewall policies separately.
DO NOT REPRINT
FORTINET
Once youve created firewall users and groups, you can move on to configuring the policies.
IP information is part of the source definition for a policy in combination with any configured user and
groups specified. Just because a user is in a group does not mean they can only be referenced by
using the group.
DO NOT REPRINT
FORTINET
After creating firewall policies, you can monitor access of your firewall users. To keep track of who is
authenticated through the firewall policies there is a User Monitor section in the GUI located under
User & Device > Monitor > Firewall.
The User Monitor screen displays who has authenticated through the firewall policies of your
FortiGate device at any given moment. It does not include administrators, because they are not
authenticating through firewall policies that allow traffic they are logging directly into the FortiGate.
This feature also allows you to de-authenticate a user or multiple users simultaneously.
DO NOT REPRINT
FORTINET
There are no events logged for successful or failed login attempts through a firewall policy.
Users that log in successfully show up in the monitor. Those that do not are prevented from passing
through the firewall.
Once a user is successfully logged in, all further logs generated from the host automatically begin to
contain their user information. Default reports and charts are set up so that the source adjusts to be
the user or the IP if there is no authentication.
You can find the list of possible log events that can show up in the Log & Report > Event Log > User
section in the Log Message Reference Guide on the doc.fortinet.com website.
DO NOT REPRINT
FORTINET
In this lesson, we discussed:
Authentication, what it is and how it works

Three methods of authentication, specifically Local Password Authentication, Remote Password
Authentication, and Two-Factor Authentication
The different authentication protocols
One-time passwords and tokens
Authentication types (active and passive)
Authentication policies
Captive Portal and disclaimers
Authentication timeout
Users/user groups, both in regards to an external LDAP or RADIUS server and through the
FortiGate, and
How to monitor firewall users

FGT1 04 Firewall Authentication V2 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FGT1 04 Firewall Authentication V2 PDF

Uploaded by

Copyright:

Available Formats

DO NOT REPRINT

Active authentication prompts the user based on:

RADIUS configuration on a FortiGate is straightforward.

In this lesson, we discussed:

Authentication, what it is and how it works

You might also like