Created on
01-16-2015
12:24 PM
Edited on
09-08-2025
12:18 AM
By
Jean-Philippe_P
Description
This article describes how to restrict a Fortinet Single Sign On (FSSO) Agent Service account to ensure the service account operates with the least privileges required.
Note:
The term FSAE is an older name for FSSO; it is an abbreviation for 'Fortinet Server Authentication Extension' and still appears in some installation paths and registry keys.
Scope
FortiGate/FortiProxy, Fortinet Single Sign On Agent (also known as 'Collector Agent').
Solution
The Collector Agent service that is created by installing a Fortinet Single-Sign-On Agent runs under a service account, rather than the currently logged-in user or the SYSTEM account. This means the service account privileges may impact how the Collector Agent service can perform its tasks.
FSSO itself supports several features and modes to be able to fit into a variety of Microsoft Active Directory (AD) implementations and to meet different requirements. Each of its operation modes (for example: DCAgent mode, WinSec polling, polling from FortiGate directly, etc.) and/or features may require different levels of privileges.
The simplest method is to allow the Fortinet Single-Sign-On Agent to use a service account with domain administrator privileges. This ensures that no matter what FSSO setup is configured, the service will have sufficient permissions to perform its tasks.
However, this may not be a desirable configuration, especially in environments that enforce rigorous security measures. This article aims to explain what privileges may be needed during installation of the various Agents, and what privileges the service account may need depending on mode and features, or what restrictions may apply if privileges are not granted.
To find this service account setting in the Windows server, go to Services (services.msc) and locate Fortinet Single Sign-On Collector Agent. Then, 'right-click' this service and select 'property'. In the examples below, an account called 'fsso-svc' is used.
The steps and privileges are based on default group privileges for AD, based on Windows Server 2012. The privileges associated with specific groups may vary in other environments, so additional adjustments may be required.
Installation and Upgrade of Agents:
The Collector Agent is required to be installed on a domain member host with a Windows OS. It is not required to be a Domain Controller (DC). For the supported Windows OS version, refer to the release notes. FSSO Agent release notes are included in the FortiOS release notes section.
The Collector Agent installation needs to be performed by an account that is a member of the local administrators or domain administrators. The permissions are required for creating local registries, libraries, local folders, logs, etc. If the installation is performed by an account that is not a local or domain administrator, the installed Collector Agent may not operate properly afterwards.
This is only a requirement during the installation.
After the installation of the agent is completed, the permissions may be reduced or changed to an account with a 'Domain Users' access level. However, the service account should have full access to the following registry keys and subkeys:
32-bit machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\collectoragent]
64-bit machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Fortinet\FSAE\collectoragent]
For example:
The service account should also have full control access for the local FSAE folder and subfolders:
C:\Program Files (x86)\Fortinet\FSAE
For example:
Note:
The error NT_STATUS_ACCESS_DENIED (0x80041003) may be encountered in the event viewer after giving full access to the FSSO service user account for the registry keys mentioned above. This happens because the change takes effect after a reboot of the Domain Controller.
Note:
Upgrading a Collector Agent also requires (temporary) local or domain administrator privileges.
DC Agent.
One of the modes that Collector Agent can run under is DC Agent mode. This means that DC Agents are installed on any domain controller that the Collector Agent should pick up user login activity from.
If DC Agent mode is not in use, this step may be skipped.
DC Agent mode is usually recommended in large environments, as, due to its design, the load of detecting the logins is spread across multiple agents and not concentrated in the Collector Agent. However, installing and upgrading DC Agents always requires a restart of the domain controller it runs.
Environments where restarts of domain controllers are not allowed should not consider using DC Agent mode.
DC Agents may be installed in two ways: via Collector Agent or manually.
If DC Agents should be installed from the Collector Agent, the FSSO service account needs (temporary) domain administrator privileges. It will need to connect to the domain controllers and be able to add/modify registry keys and copy DLL files to the Windows system directory.
The DC Agent is technically a DLL that ties into lsass.exe, not a completely standalone agent, and does not operate under a separate service account.
DC Agent can also be installed manually instead, by downloading and running the DCAgent_Setup_xxxxxx.exe or .msi file downloadable from support.fortinet.com.
For example:
DCAgent_Setup_5.0.0314.exe // executable installation file for 32-bit architecture.
DCAgent_Setup_5.0.0314.msi // MSI package for 32-bit architecture.
DCAgent_Setup_5.0.0314_x64.exe // executable installation file for 64-bit architecture.
DCAgent_Setup_5.0.0314_x64.msi // MSI package for 64-bit architecture.
The installation needs to be performed by an account with local or domain administrator privileges on each domain controller. After installation, the DC Agent utility will require entering the IP of one or more Collector Agents.
More details on the manual installation can be found here:
Technical Tip: How to Install DC Agent Graphical Interface (dc_agent GUI)
Technical Tip: Upgrading FSSO Agents
Note:
If the Collector Agent is upgraded, the DC Agent will need to be upgraded as well, using the same method as the initial installation.
An upgrade of the DCAgent will require a reboot, as the DCAgent core component is a DLL ('dcagent.dll') hooked into the system32.
The other main operating mode of FSSO is Windows Security Event Log polling (directly or via WMI).
If this is in use, the service account must be able to connect to the DC and read event logs. This may be achieved by adding the service account to the group 'Event Log Reader'.
If no Collector Agent is in use, and FortiGate (or FortiAuthenticator) performs polling directly (see Technical Tip: FSSO polling connector agent configuration and troubleshooting steps, for example), the account FortiGate (or FortiAuthenticator) is configured to use also requires these permissions.
No other explicit privileges are required for the polling itself.
For example:
02/21/2024 12:48:48 [ 6576] [E][EPPoller]Could not open the event log on:DCserver.domain.local (e=1314)
In addition to login detection, whether through DC Agents or via polling, the Collector Agent also interacts with the domain for other features, and may require additional privileges accordingly.
These include:
The Collector Agent uses LDAP to determine which groups a detected user is a member of. This means the service account needs to be able to query LDAP. The privilege is usually a given for any member of 'Domain Users', and by default, every account is a member of 'Domain Users'.
To verify this, 'right-click' any domain user in the Active Directory, select Properties, and then go to 'Security'. In the Security tab, check 'group or usernames' and make sure the service account is there. In addition, select the service account, and check the permissions for it. There should be one option called 'Read Group membership' which should be allowed by default, otherwise the Collector Agent will not be able to retrieve the group membership of the user.
Workstation Check.
The Collector Agent can perform workstation checks, meaning it connects to each workstation associated with every login it is aware of, to determine if the user is still actually logged in.
The Collector Agent utilizes WMI to achieve this. To execute the query properly, the service account either needs to be a domain administrator or a local administrator on the workstation it is connecting to.
The account also needs to be part of the local groups on the remote workstation:
Performance Log Users -> Without this group, the Collector agent can't read the IP address of the machine.
Remote Desktop Users -> Without this group, the user will erroneously show as no longer being logged on. This is also required for an RDP session.
This Microsoft article provides more information about WMI on a remote computer:
Microsoft documentation: Connecting to WMI on a Remote Computer
By the end of the Microsoft article, it should be clear that an administrator account is required for remote access through WMI. Due to User Account Control, the account on the remote system must be a domain account in the Administrators group.
If WMI access is not set properly, workstations in the Collector Agent will not be verified.
Note:
Some configuration changes may require restarting the Collector Agent service (such as editing thread count in Collector Agent -> Advanced Settings). In such cases, an administrator account is required, and the configuration utility will run under whatever administrator enabled editing the configuration.
In addition to restricting privileges, certain other settings may be put in place to ensure the service account operates cleanly and with the minimum requirements.
These may include:
While the service account is technically a domain user, it is not expected that any actual user will utilize the account. The Collector Agent (and thus service account) does not require internet access.
However, the Collector Agent DOES need to be able to contact the domain controllers and users' workstations, depending on the configuration. This traffic should ideally be exempted from FSSO altogether, as much of it originates from domain controllers or servers that have multiple logged-in users.
For example:
Deny Logon Locally:
As the service account is not expected to be used by any actual user, it can be further restricted by setting Deny Logon Locally.
For example:
Additional info about this Microsoft option is available on MSDN:
If a service account is restricted too much, certain behaviors might be observed:
The Collector Agent log (inside the installation directory of the Collector Agent) does not update anymore, or is not even created.
Various registry error messages.
The Collector Agent does not save any configuration changes
Running the command diagnose debug app auth -1 may return messages such as the following:
Server challenge:
7b 6e 93 2d 40 37 90 24 0a 00 0e 67 92 2a 82 06
MD5 response:
1b d7 74 10 cd 29 c5 e6 53 2b 6d de a0 c5 d1 1f
_process_auth[FSSO_collector]: server authentication failed, aborting
disconnect_server_only[FSSO_collector]: disconnecting
Note:
Some of the above issues are due to how the Collector Agent stores configuration settings.
In particular, any configuration is saved in a corresponding registry key (such as the password to connect to FortiGate), and if the service account has no permissions to access the registry, it cannot store or read the relevant configuration details.
Note:
When troubleshooting FSSO issues, a TAC support engineer may ask to try a domain admin/system account instead of the currently used limited-access account.
This is an expected step to test if the observed issue is related to the granted permission level. The FSSO service account is required to be a member of the ‘Server Operators’ role for the FSSO NetAPI Polling to work properly with Windows Server 2019 Domain Controller and higher.
Technical Tip: Explaining FSSO - a primer
Technical Tip: Upgrading FSSO Agents
Technical Tip: Windows event IDs used by FSSO in WinSec polling mode
Technical Note: How to enable audit of logon events on Windows Server for FSSO
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.