FortiGate user identification using FSSO - Fortinet Single Sign-On

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

Documentation

I was unable to find a very general description or reasonable documentation on the topic of FSSO (the most extensive article is for FortiOS 6.0.0). There are only short examples of certain uses (and they contain a number of incorrect information) in various places (and for different versions). It is mostly about using the FSSO group in the Firewall policy. Personally, I don't find it very secure, and I think it could be easily abused. But there are certainly scenarios where it is useful and sufficiently secure.

Even during the testing of FortiGate, a person from Fortinet advised me that FSSO can be used to identify users in the traffic log. When a user logs in on their computer in the internal network, the information that the user is on that IP address is passed on to FortiGate. We then see the username next to the source IP address in the log. It's easier than tracking who has which IP address. And in the case of dynamic addresses, it would be very difficult.

Various Articles at Fortinet

• FortiOS 6.0.0 - Agent-based FSSO
• FortiOS 6.0.0 - Single sign-on to Windows AD
• FortiOS 7.0.1 - Use Active Directory objects directly in policies
• FortiOS 7.0.1 - FSSO polling connector agent installation
• FortiOS 7.0.1 - Poll Active Directory server
• FortiOS 6.2.3 - FSSO polling connector agent installation
• FortiOS 6.0.0 - SSO Servers
• FortiOS 6.0.0 - FSSO in polling mode for Windows AD
• FortiOS 6.0.0 - Agent-based FSSO for Windows AD

FSSO Connected to Active Directory Domain Services (AD DS)

Fortinet uses the term Single Sign-On (SSO), because the user is authenticated in the AD domain, and this information is used by FortiGate, which no longer requires a new user authentication. This authentication cannot be used for security actions such as VPN login.

The principle is that user login events are detected in the event log (Microsoft Windows Security Event Log) on the domain controller. From this, the username, domain, and computer name are obtained, which are translated into an IP address. Only one user can be assigned to one IP address. But the same user can be on multiple IP addresses. The exception is a terminal server, where we can install the agent, then there can be multiple users who are distinguished by ports.

Note: In practice, various users are still shown logged in on domain controllers and Exchange servers. Perhaps this is due to the principle of operation, where in some situations during authentication, the DC or Exchange is indicated as the source. For the mail server, there is a possible solution that the Collector Agent can be used to monitor user logins to the Exchange server (I haven't tried it).

We can set up FSSO in two modes

• Polling mode - FortiGate connects to the domain controllers and remotely reads the logs, which can load FortiGate resources
• with agent (recommended) - uses an agent that processes login data and passes the results to FortiGate, has more configuration options and is recommended for higher loads

FSSO without Agent in Polling Mode

Note: At the beginning, my important practical experience. I set up this mode when deploying FortiGate with FortiOS 6.2.3. In the test, everything looked fine, but right after the start of operation, many people had the problem of session interruptions (the connection was dropping). It turned out that it was caused by FSSO. I described it a bit more in the chapter Session Timeouts - Poll Active Directory Server in FortiGate 6.2.3 bugs, debug and support. In FortiOS 6.4.6, I only did a short test, where it looked like the problems were not there, but I switched to the agent-based variant.

The communication is initiated by FortiGate (Local FSSO Agent), so it must be allowed to communicate with the domain controller through certain ports. Simplified, it's about TCP 445 for access to the logs, TCP 636 for LDAPS (group search), possibly TCP 3269 LDAPS on the Global Catalog, and UDP 53 for DNS. Detailed description is in Technical Note: List of TCP and UDP ports, used by the FSSO Collector Agent software, Ports and Protocols - FSSO - Fortinet Single Sign-On.

In the configuration, we enter the user with which we connect to the domain controller to read the logs. This user can be a member of the Domain Users group and also needs membership in the Event Log Readers group. Information can be found in the article Technical Tip: Restricting FSSO service account.

Configuring FSSO in Polling Mode

• (VDOM) > User & Authentication > LDAP Servers

First, we need to define the LDAP server that we will later use when creating the connector. This is used to read user groups from the domain.

More about the LDAP server configuration has been described in the chapter Defining the LDAP Server in the article FortiGate users, groups and authentication to LDAP (AD DS).

• (VDOM) > Security Fabric > External Connectors (in older versions it was Fabric Connectors)
• Create New > Poll Active Directory Server

Next, we create an external connector and enter the required information:

• IP address or FQDN of the domain controller
• User who has the rights to read the logs
• Select the created LDAP server
• Enable the use of the connector
• We can select users, groups or organizational units (essentially a filter) that we will later use in the FSSO Group (for the identification of all users described here, it is not necessary to set this, then all users and likely their membership in all groups are loaded, if we choose a group, only the users who are its members are loaded)

Configuration in the CLI is as follows.

config user fsso-polling
    edit 1
        set server "192.168.10.10"
        set user "fw-read"
        set password ENC xZvphx7....==
        set ldap-server "PDC"
        config adgrp
            edit "CN=G Test,OU=Firma,DC=firma,DC=local"
            next
        end
    next
end

A Local FSSO Agent is also automatically created.

config user fsso
    edit "Local FSSO Agent"
        set server "127.0.0.1"
    next
end

Note: It seems logical to me that we need to create connectors for all DCs in the domain to have complete information about user logins.

Result - Displaying Users

• (VDOM) > Dashboard > Users & Devices > Firewall Users

From FortiOS 6.4 onwards, we no longer have the Monitor menu section, but everything has been moved to Widgets on the Dashboard. Their appearance depends on our settings. Alternatively, we can add Monitor Firewall Users.

In the list, we see various authenticated users, such as from VPN. To also see users obtained from FSSO, we must have Show all FSSO Logons enabled in the top right corner. Then we see the loaded users, their IP address, and possibly the groups they belong to, how long ago their login was detected, and the amount of data transferred through the FW. The method is Fortinet Single Sign-On.

• (VDOM) > Log & Report > Forward Traffic

We also see the users (and can search by them) in the traffic log (or on FortiAnalyzer).

Use in Policies

• (VDOM) > User & Authentication > User Groups

Apparently from some version of FortiOS, we can use FSSO groups directly in policies. Previously, it was necessary (and is still an option) to create a local group of type Fortinet Single Sign-On (FSSO) and insert groups, users, or OUs from LDAP (which we set up on the connector). We can also use the predefined group SSO_Guest_Users (Default FSSO group).

• (VDOM) > Policy & Objects > Firewall Policy

In the policy, we then set the IP addresses (perhaps the range of the internal network) and the defined user group as the source.

FSSO Event Log

• (VDOM) > Log & Report > Events - User Events

FSSO messages are stored among user events (if we have logging enabled). The actions start with FSSO, for example FSSO-logon, FSSO-logoff, FSSO-polling-LDAP-server.

Troubleshooting FSSO

In the CLI, we can use various commands that will show us information about FSSO. For example, to list the loaded (logged in) users. If we didn't specify Users/Groups in the FSSO connector, we don't see any group in the GUI for the users, but in the CLI it displays (presumably) all the user's LDAP groups. If we have a defined FSSO group, it will also be displayed at the end.

FW (FWINT) # diagnose debug authd fsso list
----FSSO logons----
IP: 10.0.0.18  User: bouska  Groups: CN=Users,CN=Builtin,DC=firma,DC=local+CN=Domain Users,CN=Users,DC=firma,DC=local+CN=
Bouška Petr,OU=Firma,DC=firma,DC=local  Workstation:  
Total number of logons listed: 1, filtered: 0
----end of FSSO logons----

A slightly different user listing is returned by the command diagnose debug fsso-polling user.

Server status / connection.

FW (FWINT) # diagnose debug enable
FW (FWINT) # diagnose debug authd fsso server-status
FW (FWINT) # 
Server Name       Connection Status     Version               Address
-----------       -----------------     -------               -------
Local FSSO Agent  connected             FSAE server 1.1       127.0.0.1

Client status. If we didn't have an active connector, it would return fsso daemon is not running.

FW (FWINT) # diagnose debug fsso-polling client
Client Status: 
IP Address: 127.0.0.1
Serial Number: FG3H0E58xxxxxxxx-xxx
Connection state: ready
SEQ: hello(1), auth(1),logon_event(2)
Group Filter: 

STATS: 
	received hello packet(1)
	sent hello packet(1)
	sent auth packet(1)
	received get AD info packet(1)
	sent AD info packet(1)
	recv AD info packet(0)
	received get logon info packet(1)
	sent logon info packet(1)
	sent logon event packet(2)

Detailed information about the connection status to AD DS.

FW (FWINT) # diagnose debug fsso-polling detail 1
AD Server Status(connected): 
ID=1, name(192.168.10.10),ip=192.168.10.10,source(security),users(0)
port=auto username=fw-read
read log eof=1, latest logon timestamp: Mon Sep 13 08:23:57 2021

polling frequency: every 10 second(s) success(1), fail(0)
LDAP query: success(0), fail(0)
LDAP max group query period(seconds): 0
LDAP status: connected

Group Filter: 
CN=G Test,OU=Firma,DC=firma,DC=local

Debug FSSO

Traditionally, we get the most information by enabling debug mode. Full debug of FSSO.

diagnose debug application fssod -1

For some situations (events), AUTHD debug is also useful, some documentation mentions -1, others 8256. Technical Tip: Useful FSSO Commands

diagnose debug application authd 8256

We can enable timestamp display for individual records and overall enable debug.

diagnose debug console timestamp enable
diagnose debug enable

To disable debug mode, we can use.

diagnose debug disable
diagnose debug reset

FSSO with Agent - Collector Agent AD access mode

FSSO without an agent is described by Fortinet as a modern, advantageous solution. But many FortiGate specialists strongly recommended to me to use the agent mode. Mainly due to performance impacts, but also due to better configuration and filtering.

We install the FSSO Collector Agent as a service on a Windows server in the domain. It obtains information from Domain Controller agents (DC agent), which are installed on the domain controllers. Optionally, the Collector Agent can query the DCs directly without an agent (Polling mode). It can also obtain information from Terminal Server agents (Citrix or VMware Horizon).

Working Mode and LDAP

The Collector Agent can operate in one of two working modes (Working Mode):

• DC Agent mode - recommended
• Polling mode - if we can't install agents on the DCs

DC Agent mode is the standard mode. It requires the installation of agents on the DCs and their update, after the installation, the server must be restarted. It's not a service, but a system library dcagent.dll. It uses the configuration in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\dcagent.

The Collector Agent can obtain user group information from the DC agent. Optionally, FortiGate can load the groups using LDAP. The Collector Agent performs DNS lookups, group verification, workstation checks, and passes information to FortiGate.

Communication and Ports

The Collector Agent listens on UDP port 8002, through which it sends DC agent keepalives and login information. The DC agent must be on all domain controllers and send information to a specific Collector Agent, of which there can be multiple for redundancy.

The documentation states that it passes information to FortiGate using TCP port 8000. But it's actually that the Collector Agent listens on port 8000, to which FortiGate connects (on FortiGate, we enter the agent's address, not the other way around). It's also not often mentioned that SSL can be enabled, then port 8001 is used for FortiGate and 8003 for the DC agent.

AD access mode

The Collector Agent has two methods of accessing user information (AD access mode) Technical Tip: FSSO Windows Directory Access Methods - Standard versus Advanced Mode

• Standard mode - recommended, simpler, uses the naming convention Domain\Username, does not support nested groups, the group filter is defined on the Collector Agent
• Advanced mode - uses the LDAP convention CN=User, OU=Name, DC=Domain, supports nested groups, the group filter is defined on FortiGate

This is how the modes are described in most places. However, I don't understand the description in the document FortiOS 7.0.1 - Use Active Directory objects directly in policies

To use this feature, you must set FSSO Collector Agent to Advanced AD access mode. If the FSSO Collector Agent is running in the default mode, FortiGate cannot correctly match user group memberships.

Agent Installation

• Technical Tip: Downloading FSSO agent software
• Technical Tip: Upgrading FSSO Agents
• Technical Tip: FSSO Collector Agent unable to install DC agent to Domain Controller

We can download the installation files from the Fortinet Service & Support website, menu Support - Firmware Download - Fortigate - tab Download - navigate to our version and finally to the FSSO folder. There are various files, for example:

• FSSO_Setup_5.0.0301_x64.exe - contains the Collector Agent and DC Agent for FortiOS 6.4.7
• DCAgent_Setup_5.0.0301_x64.exe - contains the DC Agent for FortiOS 6.4.7

Using the FSSO_Setup, we can install the Collector Agent and then perform a remote installation of the DC agent on all domain controllers. If we need to manually install the DC Agent, we can use the DCAgent_Setup.

Account for Running the Collector Agent and Required Permissions

During the installation of the Collector Agent, we enter the account under which the service will run. Fortinet recommends (completely insane) the Domain Admin permissions. But it also states that the minimum requirement is membership in the Event Log Readers group. I would expect that when using the DC Agent, it reads the logs and sends them to the Collector Agent, so this permission is not required.

Fortinet doesn't describe this in more detail. However, when we try to run the agent with minimum permissions, we run into problems (non-functionality) and have to go through the logs and find out why things are not working. The first thing is that the account must have rights to the file system on the server where it creates various files (logs, list of loaded users), and in the registry.

Furthermore, we might run into a problem that in the Show Monitored DCs we will see the number of events and the last user login value jumping. When viewing the log, we will see that user logins are detected, but the Show Logon Users list will be empty, and nothing will be transferred to FortiGate either.

When we view the log, we will see events from which we will learn that it failed to load the groups the user belongs to.

[ 2220] logon event(16027): len:31 monitorType:1 dc_ip: 192.168.10.10 time:1631019201 len:18
 data:BOUSKAP/FIRMA/bouska ip:10.0.1.10
[ 2220] ad_user_get_groups error: FIRMA(\\pdc.firma.local)/bouska 5
[ 2220] ad_user_get_localgroups error FIRMA(\\pdc.firma.local)/bouska: 5
[ 2220] cannot get group info for FIRMA/bouska
[ 2220] ad_user_get_groups_str():<NONE>

By default, users (Domain Users) do not have permission to read other users' groups (Member Of). We need to add this permission to our user. This can be done using the Active Directory Users and Computers (ADUC) tool. On the domain or OU with users, we will go to the settings (Properties) and in the Security - Advanced section, we will add the user (or create a group for this purpose) and for Descendant User objects, check the Read Member Of Properties.

Another thing is the detection that the user has logged off. The Collector Agent, in addition to the logs, also uses a method where it connects to the computer using WMI and detects the logged-in user. It typically uses port 445. It requires sufficient permissions for remote access or we can disable these checks. Adding the permission is more complex How can I create a user with WMI query permission?

Configuring the Collector Agent

More detailed information can be found in the documentation Configuring collector agent settings. The configuration is done using the Configure Fortinet Single Sign On Agent application.

• Authentication - Password - enter the password with which FortiGate will authenticate, max 15 characters (the default is fortinetcanada)
• Log file size limit (MB) - 10 MB is a very small value for logs, it needs to be increased
• Log logon events in separate logs - it's helpful to separate certain events for clarity
• Set ignore user list - we select users we don't want to track (e.g., administrators and service accounts), Technical Tip: How and why to use the 'Ignore User List' option in FSSO Collector Agent
• Set Group Filters - we can specify allowed groups, login information for their users is sent to FortiGate, if we don't specify anything, all groups and users are sent (except those we don't track using the ignore list), it's good to limit it so that less information (even just the group list) is passed on to FortiGate
• Advanced Settings - tab General - Use WMI to check user logoff - if we don't have access to clients (traversal or permissions), we can disable the Workstation Check
• Advanced Settings - tab Exchange server - we can set up monitoring of user logins to the Exchange server

The logs are typically stored in the path ""c:\Program Files (x86)\Fortinet\FSAE\" and are the files CollectorAgent.log, logon_event.log and fortilog.txt.

FortiGate Configuration

We have two options, either we define an LDAP server on FortiGate and use it in the connector configuration, or we will receive the user groups from the Collector Agent.

• (VDOM) > Security Fabric > External Connectors
• Create New > FSSO Agent on Windows AD

We create an external connector and enter the required information:

• Name of the connector
• IP address or FQDN of the server where the Collector Agent is installed
• Password set in the agent
• we can also add other agents for high availability
• optionally, we can select a certificate and enable SSL
• we select the source of groups (User group source) - either they are determined by the Collector Agent or we set Local and select the LDAP server, in older versions the setting was called Collector Agent AD access mode and the options were Standard and Advanced, so it's a question whether it's still related to the Collector Agent setting (in it, there is also information that if we load groups on FortiGate from LDAP, the agent should be in Advanced mode)

It seems to me that there are several bugs here. Under Users/Groups I still see 0. The help says it should show the groups loaded from the Collector Agent. However, I see the loaded users in the monitor and when listing them in the CLI, including the groups. But I can't either include the AD groups in the FSSO Group or use them directly in the policy. Only after trying with the password (described below) did the groups suddenly load, and it became possible to create an FSSO group from them or use them directly in the policy.

When I did the initial configuration, I set my own password for the connection from FortiGate on the Collector Agent. I used that password in the external connector configuration. But the connection failed, and the connector remained in the Disconnected state. I tried various other (simpler) passwords, and still nothing. I enabled authd debug on FortiGate, and the following was logged:

2021-09-06 15:40:37 _process_auth[PROVOZ]: server authentication failed, aborting
2021-09-06 15:40:37 disconnect_server_only[PROVOZ]: disconnecting

In the Collector Agent, enabling the password is optional, but in the FortiGate configuration, it is mandatory. I tried disabling Require authenticated connection from FortiGate on the Collector Agent, but it still didn't connect. Finally, I entered the default password (fortinetcanada) on both sides, and the connector connected for the first time. I tried disabling the password on the agent, and the connection remained.

It wasn't until I wanted to describe everything that I made another attempt to change the password, and surprisingly, everything worked with a different password. And even the groups were suddenly loaded. I made several attempts, and now any password works as long as it's the same on the agent or disabled.

CLI configuration, where we can also set other items (e.g., a port other than 8000)

config user fsso
    edit "PROVOZ"
        set server "10.0.0.179"
        set password ENC 3fpG2O....==
    next
end