Description
This article provides an overview of available redundancy configurations in Fortinet Single-Sign-On (FSSO) setups and what common configuration mistakes to avoid.
Scope
FortiGate, FortiProxy, FortiAuthenticator, FSSO Agents.
Solution
Fortinet Single-Sign-On (FSSO) is a solution that allows Fortinet products, in particular FortiGate and FortiProxy, to discover user logins from a variety of sources, primarily Active Directory, and treat users as authenticated and members of specific groups. This in turn allows a FortiGate or FortiProxy to apply policies in a granular manner and manage access privileges of users accordingly.
An explanation of FSSO may be found here: Technical Tip: Explaining FSSO - a primer
A detailed guide to FSSO troubleshooting may be found here: Troubleshooting Tip: FSSO Complete troubleshooting for TAC tickets
Such a setup in turn requires that authentication information is available reliably; if authentication information is not available, users may lose access to resources they require for critical operations, as they no longer match the requisite policies on FortiGate or FortiProxy.
To this end, there are some options to consider when looking to build a resilient FSSO setup.
Login Detection Redundancy:
As FSSO works by detecting logins through various means, ensuring resilient login detection is a primary concern. There are a few options to ensure logins are detected reliably. This includes combining multiple different detection methods and/or using the FSSO Mobility Agent.
Combining Detection Methods:
FSSO uses different ways to detect logins. These include DC Agent mode, Polling mode, TS Agent, RADIUS Accounting, and Syslog; a more in-depth explanation of these may be found in the FSSO primer linked above.
Collector Agent (and FortiAuthenticator) is able to perform all four methods in parallel. While Collector Agent is technically configured to perform either DC Agent Mode or Polling Mode, in Polling Mode, it can still receive DC Agent logs!
The DC Agent may need to be installed manually (as outlined here for example: Technical Tip: How to Install DC Agent Graphical Interface (dc_agent GUI)) and pointed to the Collector Agent, but no matter the operation mode, the Collector Agent does listen on port 8002 (8003 if SSL is enabled) for DC Agent messages.
To ensure the Collector Agent performs both, DC Agents need to be deployed on domain controllers, and the Collector Agent itself configured for polling mode. Polling mode does use more resources on the Collector Agent host, so it may be necessary to monitor the performance and resource usage of the Collector Agent host and increase available resources if there are performance-related issues.
FortiAuthenticator allows explicit enabling of any or all of the listed methods. The only caveat is that it cannot use SSL to communicate with DC Agents, as the port (8003) is used by FortiClient Mobility Agent.
Mobility Agent:
The FSSO Mobility Agent (FSSOMA) is a FortiClient feature subset (or a standalone Agent) that reports user logins to FortiAuthenticator. As the Agent is hosted directly on each user's endpoint, this may be more accurate, especially in cases where users frequently change their IPs. The Mobility Agent may be configured to report to multiple FortiAuthenticators as well. FortiAuthenticator can also combine Mobility Agent with any or all of the other detection methods listed above.
Note:
Mobility Agent does NOT work with Collector Agent, only with FortiAuthenticator. It also requires an additional license on FortiAuthenticator.
Login Collection Redundancy:
Login Collectors (Collector Agent, FortiAuthenticator) is where the logins are tracked and maintained. They provide the user login information to FortiGate for the actual application. To this end, the Collector Agent/FortiAuthenticator should also operate redundantly.
Collector Agent:
Collector Agent does not inherently offer anything like High Availability. Multiple Collector Agent instances may be set up on different servers in the same environment instead to ensure at least one Collector Agent remains available to FortiGate. FortiGate can only handle up to six Collector Agents in a redundant manner, so it is not feasible to deploy more than six Collector Agents.
Collector Agents can synchronize a very limited configuration (group filter and ignore user list, outlined here: Technical Tip: FSSO Collector Agent - sync configuration with other agents) to other Collector Agents; all other configurations must be mirrored manually.
Each Collector Agent maintains their list of logins, and as long as each Collector Agent relies on the same sources, they should have the same logins. There may be slight differences as the Collector Agent behaves a bit differently if a FortiGate is connected or not.
In particular, on a Collector Agent connected to a FortiGate, the Collector Agent will limit its login maintenance to the logins that are also forwarded to FortiGate, and logins that are not forwarded are not checked and may grow stale. Login maintenance in this case refers to the DNS lookup (IP address change) and WMI check (Workstation Verification).
Collector Agents not connected to a FortiGate check all logins regularly, and may thus have slight differences if stale logins are removed or different IPs or users are detected during checks.
FortiAuthenticator:
FortiAuthenticator provides a few different options for resilience. This includes High Availability setups and FSSO Tiering.
In an active-passive cluster, FortiAuthenticator synchronizes all FSSO-related configuration and also mirrors FSSO sessions to the secondary. In a failover event, the secondary has the same list of logins and FSSO configuration and takes over for the primary. FortiGates may log a temporary loss of connection to the FSSO server, but should not be affected otherwise.
Note:
FortiAuthenticator failover should take a maximum of three minutes. If it takes longer than five minutes for some reason, FortiGate may purge the FSSO sessions it has, and all traffic by all FSSO users would also be purged.
In a load-balancing configuration, FSSO sessions and configuration are not synchronized. The same FSSO configuration may be manually configured to allow the load-balancing node to detect the same logins and maintain its own FSSO session list.
FSSO Tiering is a feature that allows FortiAuthenticator to forward FSSO Sessions to another FortiAuthenticator; this may also be called Hierarchical FSSO. More details may be found here: Technical Tip : FortiAuthenticator and Single-Sign-On (SSO) Tiered Architecture
This can be set up between any two FortiAuthenticators as long as they can reach each other and have a similar firmware version, whether the Authenticators form a load-balancing cluster or are independent devices.
The receiving FortiAuthenticator does not perform any checks on the login, like LDAP group lookups, DNS, or WMI verification, instead relying on receiving updates from the sender FortiAuthenticator, which performs the login maintenance. FSSO Tiering cannot be used with Collector Agents.
FortiGate/FortiProxy:
FortiGate (or FortiProxy) is the final destination for FSSO logins, and the firewall may use the FSSO logins to apply policies in a granular manner. There are various configuration options available to ensure that FortiGates are able to maintain an FSSO user list.
External Connector:
A FortiGate is set up to receive FSSO logs from the Collector Agent or FortiAuthenticator by configuring an External Connector of type "FSSO Agent on Windows AD'. The corresponding configuration in CLI is under 'config user fsso'. Up to five such connectors may be configured per VDOM.
However, only one Connector should be configured per domain.
While deploying multiple Collector Agents in the same environment may lead to the assumption that each Collector Agent requires its Connector on FortiGate, this is not correct.
Collector Agents in a single domain should all be associated with the same Connector to ensure the same group filter applies across all Collector Agents in the domain. The same FSSO filter groups in FortiGate can only be associated with one Connector at a time!
Depending on the setup, already existing filter groups may be overwritten to link to a different Connector than originally intended if there are multiple Connectors for the same domain.
In addition, FortiGate may receive the same user login from different connectors; these would be treated as different logins. This means the second login replaces the first login, and all traffic associated with the first login is purged from the session table!
Instead, mulitple Collector Agents in the same domain should be associated with the same External Connector in FortiGate. Up to six Collector Agents may be added to a single connector.
FortiGate rotates through the entries as needed; it sticks with a Collector Agent until it loses the connection, then establishes a connection to the next and sticks with that Collector Agent instead. If FortiGate has reached the end of the list and the final Collector Agent becomes unreachable, FortiGate will start from the beginning. The currently used Collector Agent is highlighted in bold when hovering the cursor over the connector:
In case of a FortiAuthenticator load-balancing setup, each node (primary and load-balancing nodes) may be added as their own Collector Agent entries in the same Connector.
Windows AD Polling:
Windows AD polling is a method that allows FortiGate itself to poll event logs on domain controllers directly. This is configured via an 'Active Directory Connector' in External Connectors. Only a single server may be configured, but if a hostname is configured instead, and this name resolves to multiple IPs, FortiGate will try to connect to each resolved IP if the previous IPs are unreachable/unresponsive.
Only one Active Directory connector should be configured per domain, and it should not be configured for the same domain if an FSSO Agent connector already exists.
This is due to the same group filter restriction as mentioned above; filter groups may only be linked to one (1) connector, whether that is an FSSO Agent or Active Directory Connector.
High Availability:
FortiGate/FortiProxy also offers High Availability configuration options.
In both active-passive and active-active setups, FortiGate and FortiProxy synchronize FSSO sessions to the secondary node. FSSO sessions are per-VDOM and do not get shared between different VDOMs.
Related articles:
Technical Tip: FSSO Collector Agent failover configuration
Technical Tip: FSSO Collector agent redundancy with two Windows AD and two Fortinet DC Agents
