FortiGate users, groups and authentication to LDAP (AD DS)

Note: The description in the article is based on FortiGate FG-300E with FortiOS version 6.2.3. Which is configured as an FGCP cluster and uses VDOM.

Note: I must say that I increasingly struggle with Fortinet documentation. On one hand, it's very extensive, but on the other hand, it lacks crucial information. It's very inconsistent, and one has to piece together information from various places within a single documentation. But what I find worst is the need to look into several documentations (at least Cookbook and Handbook, and usually different versions have certain parts of the documentation). Some topics are described better, some very insufficiently. Often, descriptions of individual form items in the GUI are missing. And CLI commands are described inadequately. Fortinet innovates a lot, but it happens that the documentation for a new version contains an old description, even if the feature has changed. I had to figure out many things by enabling debug and examining events.

Users and user groups

Documentation Users and user groups

Users

• (VDOM) > User & Device > User Definitions

FortiGate works with users grouped into groups (User Groups). A user is a user account containing a username, password, and possibly additional information. Users can be defined locally on the FortiGate unit or on a remote authentication server.

Different types of user accounts

• Local user - local account on the FortiGate unit, uses name and password, possibly two-factor authentication
• Remote user - username defined on the FortiGate unit, authenticated against a remote server (LDAP, RADIUS, TACACS+)
• Authentication server user - FortiGate group can contain users or groups from a remote authentication server (LDAP, RADIUS, TACACS+)
• FSSO user - uses Fortinet Single Sign On (FSSO), user from Microsoft Windows or Novell network
• Peer (PKI) user - local user who uses a client digital certificate for authentication
• Guest Users - temporary guest account

Two-factor authentication

FortiGate supports two-factor authentication (2FA) for users and administrators. Overall, we can use the FortiAuthenticator solution. One 2FA option is to use a password and user certificate. The second uses a One-time Password (OTP) with the password. This is an authentication code with six digits that is valid for 60 seconds. Options for obtaining/delivering this code are

• Electronic message (email) - sent to the user's email, Fortinet states that if this user setting option is not offered in the GUI (where it should be), it must be set using CLI
• SMS message - sent to the user's mobile number, uses FortiGuard Messaging Service (4 free messages) or we can define our own SMS service
• FortiToken - an interesting solution that generates a One-time Password (OTP). It can be a small physical device or a mobile application. The mobile app is free, but we need a license on FortiGate for each user.

User Groups

• (VDOM) > User & Device > User Groups

A user group is a list of user identities. Most often, FortiGate authenticates users by name and password. It first checks among local users, then on RADIUS, LDAP, or TACACS+ servers that belong to user groups.

There are four types of groups

• Firewall - members can be local users (Local, Remote, Peer (PKI) user) or remote groups (Remote Groups - Authentication server user) from RADIUS, LDAP or TACACS+ server, here we can add only an authentication server (then every authenticated user on this server is taken) or specific groups from the server
• Fortinet single sign-on (FSSO) - members can be groups defined in FSSO, typically from Windows domain, group members are not authenticated (don't enter name and password), these groups cannot be used for VPN
• RADIUS single sign-on (RSSO) - takes authenticated users from RADIUS server, they don't need to authenticate again, RADIUS Start records are set to be sent to FortiGate
• Guests - group used for creating temporary access for guests

Note: FortiGate states that when loading the list of group members from an external server, it only supports a size of 8 kB (if the list exceeds this size, it ignores the rest)

User Authentication

Documentation Authentication, Configuring firewall authentication

There are many places on the Firewall where it's necessary to verify the user's identity and grant access accordingly. Even mere user identification is useful, providing detailed overview in logs.

General terms

User verification

• Authentication - identity verification, it's confirming that a person is who they claim to be
• Authorization - permission, it's verifying that a person has permission to do what they're trying to do

User verification factors

• knowledge factor - something the user knows, like a username and password
• possession factor - something the user has, like an access card, smart card, SSH key, certificate
• inherent factor - something the user is, like biometrics (fingerprint, retina, etc.)

Types of authentication

• single-factor - only one component from one category of factors is used for verification (like name and password)
• two-factor (2FA) - we use two independent categories, for example a chip card (certificate) and PIN (we must have something and know something)
• multi-factor - uses two or more factors

Login information, otherwise known as credentials, are used for authentication and gaining access to information or other resources.

Use of authentication

FortiGate uses authenticated users in many places. Sometimes we use users directly, but often a group is specified. Some places where we can or must use users:

• administrator login to FortiGate unit - admin accounts are used instead of user accounts
• user login to VPN - for SSL VPN (and possibly IPsec) we specify users and groups
• Firewall (Security) Policy - in policies, we can use not only addresses as a source, but also users and groups
• logs and reports - if we have identified users within the traffic, we'll see them in the log

We can use a number of authentication methods, which stem from the types of users described above. Authentication can be handled by an external device FortiAuthenticator.

• local password authentication - local accounts
• password authentication on external server - entered user credentials are sent for verification to an external server, LDAP is supported (thus also Active Directory Domain Services - AD DS), RADIUS, TACACS+, POP3
• certificate authentication - uses Public Key Infrastructure (PKI) and X.509 certificates
• two-factor authentication - the account uses a password and certificate or token code (OTP)

Users, and thus authentication, can be used in two main places and there are different conditions for each use. Fortinet calls this Security Policy Authentication and Virtual Private Network (VPN) Authentication.

Policies allow traffic that can flow between networks. If we use users in a policy, they must be authenticated for the traffic to be allowed. Typically, a login dialog pops up, and it's valid for the duration of the connection. Two methods referred to as Single Sign-On (SSO) are available, which should authenticate the logged-in user without further entering of credentials.

These are RADIUS Single Sign-On (RSSO), where the RADIUS server sends information to FortiGate that a certain user has logged in from a certain IP address, plus additional information. And Fortinet Single Sign-On (FSSO), which works with Microsoft AD DS or Novell eDirectory. I'm still studying FSSO, but so far it seems to work simply. If a user logs into the domain, FortiGate obtains the user's name, IP address, and groups. It then links the user's identity with the source IP address, and uses this in policies. I wouldn't call this authentication.

• (VDOM) > User & Device > Authentication Settings

In global authentication settings, we can set several properties. Authentication timeout, how many minutes of inactivity the firewall connection will keep the user logged in. In Protocol Support, we select protocols where user authentication will be performed (if a user is set in the policy). And which certificate will be used for the HTTPS authentication page.

Authentication on LDAP server

Documentation Authentication Servers - LDAP servers

If we're creating SSL VPN, it's convenient for our domain users to authenticate with their regular account. The configuration involves creating an LDAP server (or several) and user groups, where we include groups from the LDAP server (Remote Groups). We then use these FortiGate groups in the SSL VPN configuration.

LDAP server definition

We need the server address (domain controller), the protocol used and port (typically LDAPS over TCP port 636) and a user with read rights (classic Domain User).

• (VDOM) > User & Device > LDAP Servers

We create a new LDAP server with the Create New button.

• Name - naming of the server on FortiGate
• Server IP, Server Port - server address, standard port is filled in automatically (389, 636)
• Common Name Identifier (CNID) - quite confusingly described, it's the LDAP attribute in which the username is searched, so for AD DS it usually won't be cn, but rather sAMAccountName or userPrincipalName
• Distinguished Name - simplified root of the domain in Distinguished Name (DN) notation, after setting up login we can use the Browse button
• Bind Type - login to LDAP server, typically Regular
• Username - user for reading AD DS in Distinguished Name (DN) notation
• Secure Connection - of course we should connect encrypted via LDAPS

If we use LDAPS, we can enter a Certificate. I would understand this to be the certificate of the authority from which the LDAP server has its certificate. If I select such a certificate, the Test Connectivity button returns Successful, if I select a different one, it returns Can't contact LDAP server. Subsequently, I spent a long time troubleshooting why user authentication wasn't working and was returning unknown user. Only through debugging did I arrive at a message that certificate verification failed when connecting to the LDAP server. It's enough to leave the certificate field empty and the connection works.

If we use userPrincipalName as the Common Name Identifier, we can add the command set account-key-processing strip in the CLI configuration of the server and the domain will be removed from the UPN (UPN suffix), so only the username will be taken.

Creating a group that contains a remote group from LDAP

• (VDOM) > User & Device > User Groups

Then we create a group (Create New) that contains a remote group (Remote Groups) from LDAP.

• under Remote Groups we select our created LDAP server
• we find the desired group, right-click on it and choose Add Selected

Note: It's possible to select only the LDAP server as a Remote Group and not any group. Then all user accounts on this LDAP server are members of the created group.

Note: If we have multiple LDAP servers, we can add all of them to the group and select the same group on them. This ensures higher availability.

Network communication

Communication to the LDAP server leaves from the VDOM where the server is defined, and leaves from the interface that has a route to the given address. It's not necessary to create a policy that would allow communication. This is certainly needed for some scenarios, but I would find it useful to have the option to create LDAP globally and have communication go through the MGMT interface.

Nested groups

Documentation Technical Note: LDAP Nested Group settings and changes in FortiOS 5.6, 6.0 and 6.2

When we use an LDAP group for authentication, by default only user accounts that are direct members of the group are taken. If another group is nested within the group and only then user accounts, they won't work. This is for performance reasons. But we can enable recursive group searching in the LDAP server configuration in CLI.

set search-type recursive

Locking after incorrect authentication

FortiGate has a default setting that after a certain number of failed attempts to authenticate to SSL VPN, the possibility of login is blocked for a certain time. The documentation states that in the CLI global user authentication settings (it's possible to set separately for FortiGate admin logins) it's possible to set a period when login is not possible (blackout period). The commands below show the default values.

config user setting
	set auth-blackout-time 0
	set auth-invalid-max 5
end

In this part of the configuration, there are similar commands for Lockout, which seem almost identical to me. I couldn't find any description, only a brief one among the commands Configure user authentication setting.

config user setting
	set auth-lockout-threshold 3
	set auth-lockout-duration 0
end

But if we're dealing with locking for SSL VPN, it's set in the CLI configuration of VPN.

config vpn ssl settings
	set login-attempt-limit 2
	set login-block-time 60
end

The default settings are 2 attempts and blocking for 60 seconds. After that, the user is shown an error and can't even bring up the login dialog again until the time elapses (it's not the user that's blocked, but the IP address).

Too many bad login attempts. Please try again in a few minutes.

Note: If we're in some part of the configuration in CLI, we can use the show command, which lists the current settings. However, it only shows commands changed from the default state. If we want to display all settings, we can use show full-configuration.

Note: What I only found out in practice (such a basic thing). Setting examples always end with the end command. I thought it was just a jump up one level, but this command also saves the settings of the object. Without it, our changes won't take effect.

Troubleshooting (debug) LDAP

Documentation Troubleshooting Tip: Fortigate LDAP

When problems occur, we can first verify that authentication occurs by entering a name and password against the created LDAP server.

We can do this in the GUI

• (VDOM) > User & Device > LDAP Servers
• edit the given server
• Test User Credentials button

Here we can try, for example, that if we don't change the Common Name Identifier, we won't log in with a username, but the display name like Bouška Petr will work (we can look exactly at the cn attribute in Active Directory Users and Computers).

We can test the same thing with a command in CLI using the command

diagnose test authserver ldap <LDAP server_name> <username> <password>

Practical example

FW1 (root) # diagnose test authserver ldap PDC bouska WrongPassword
authenticate 'bouska' against 'PDC' failed! 
FW1 (root) # diagnose test authserver ldap PDC bouska CorrectPassword
authenticate 'bouska' against 'PDC' succeeded!
Group membership(s) - CN=Domain Users,CN=Users,DC=company,DC=local
...

The next step is enabling debug mode for Remote user authentication (fnbamd is Fortinet non-blocking authentication daemon)

diagnose debug application fnbamd -1
diagnose debug enable

Note: The value -1 is apparently the same as 255, we can use 0 to turn it off.

Now all related events are printed to the CLI (in case of VDOM from all domains). So it's enough to trigger authentication, for example using Test User Credentials.

Example of part of the logs during certificate verification error.

[2307] handle_req-Rcvd auth req 256105300 for bouska in Firewall Admin opt=00014001 prot=11
[409] __compose_group_list_from_req-Group 'Firewall Admin'
[615] fnbamd_pop3_start-bouska
[342] radius_start-Didn't find radius servers (0)
[719] auth_tac_plus_start-Didn't find tac_plus servers (0)
[1662] fnbamd_ldap_init-search filter is: sAMAccountName=bouska
[1671] fnbamd_ldap_init-search base is: dc=company,dc=local
[1019] __fnbamd_ldap_dns_cb-Resolved PDC(idx 0) to 192.168.10.10
[1087] __fnbamd_ldap_dns_cb-Still connecting.
[568] create_auth_session-Total 1 server(s) to try
[962] __ldap_connect-tcps_connect(192.168.10.10) failed: ssl_connect() failed: 5 (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed).
[798] __ldap_try_next_server-LDAP 'PDC' conn failed, svr: 192.168.10.10.
[764] __ldap_error-
[753] __ldap_stop-svr 'PDC'
[3246] fnbamd_ldap_result-Error (3) for req 256105300
[181] fnbamd_comm_send_result-Sending result 3 (error 0, nid 0) for req 256105300
[724] destroy_auth_session-delete session 256105300

To turn off debug mode we can use

diagnose debug disable
diagnose debug reset

FortiGate administrator authentication on LDAP server (Remote authentication for administrators)

Documentation Remote authentication for administrators

Administrators can log into FortiGate with their LDAP (AD DS) account.

• (Global) >System > Administrators - Create New - Administrator

Here, besides Local User, we can also select Match a user on a remote server group or Match all users in a remote server group. I couldn't find a description or differences between these two options anywhere. In practice, the second one works for me, in the documentation examples they use the first one. The only mention suggests that the first option contains one user (but I'm selecting a remote group), the second is referred to as a Wildcard Admin Account. One account contains the entire group, so multiple users are hidden under one name (but the name of the logged-in user from LDAP is written to the log).

If we use VDOM, everything behaves quite strangely. The predefined Admin Profiles are super_admin, which manages everything, including all VDOMs and Global. And prof_admin, where we can assign VDOMs, but it doesn't have access to Global.

We can't define the LDAP server globally, but only in a specific VDOM and we create groups there as well. When we create a Super Admin, we are offered groups from all VDOMs. When we look at the created account in CLI, we see that it still has certain VDOMs assigned, namely root and the one where the LDAP server is defined.

set vdom "root" "FW"

If we remove root in CLI or even in graphics (by switching to prof_admin profile and back), we won't be able to log in. This applies even if we make an administrator to whom we want to assign only a certain VDOM. Apparently, it must always have the Management VDOM assigned.