FSSO Authentication Issue-Same Credentials, Different IP

[Ammar-Ud-Din]

FSSO Authentication Issue: Same Credentials, Different IP – No Access

We’ve identified an issue with Fortinet Single Sign-On (FSSO) where users are unable to authenticate when connecting from a different IP address using the same username and password.

Problem Overview: When a user logs in from one IP address, FSSO successfully authenticates and grants access. However, if the same user attempts to connect from a different IP (e.g., switching networks or subnet), authentication fails—even though the credentials remain unchanged.

Possible Cause: FSSO relies on IP-to-user mapping via polling agents or DC agents. If the IP address changes and the new IP isn’t mapped to the user in the collector agent’s cache, the firewall cannot verify the user identity, resulting in failed authentication.

Suggested Additional Steps:
1) Force logoff from AD to trigger a fresh login event.
2) Restart the FSSO Collector Agent service to refresh mappings.
3) Ensure all domain controllers are properly polled by the collector agent.

Work Around:

Option 1:
Manually clear the user’s session entry from the FSSO Collector Agent or polling source (e.g., DC Agent), and remove any stale AD session records. This will trigger a fresh authentication and update the IP-user mapping.

Option 2:
Flush the DNS cache on the user’s device and perform a Windows logout/login or reconnecting to the network. This process helps clear any stale network records from the system and initiates a fresh authentication cycle, which can assist in resolving FSSO-related login issues.

[pminarik]

Majority of polling sources (event logs, DC Agent) provide a hostname, which the Collector will always try to resolve to get the user's current IP, so the first step towards a functional user that just moved to a different IP is to ensure that DNS records are up to date, and update fast.

The refresh can then be triggered by two events:

- "IP address change verify interface" aka DNS check. By default started every 60 seconds. If the FSSO has the hostname of the PC, it will use DNS to keep the IP updated.

- New logon event: If the user generates a new logon event, the Collector will go through the whole process of processing a logon even, which includes resolving the hostname via DNS.

As you can see from this, FSSO is critically dependent on correct and fresh DNS records. If for any reason DNS cannot be "trusted", there's not many alternatives left. The best one is probably FSSOMA (clients actively reach out to the FAC Collector to report their current IP and user), but that requires FortiAuthenticator + special FSSOMA license + FortiClients installed on endpoints. (they can be the free version nowadays, but of course they will be easier to handle if managed by FortiClient EMS).

[Ammar-Ud-Din]

As part of this new procurement, it is important to highlight that the customer has no intention to purchase additional products, such as FortiAuthenticator or FSSOMA licensing, solely for the purpose of enabling Fortinet Single Sign-On (FSSO). This requirement imposes a limitation on the solution architecture, and must be carefully considered during the planning and recommendation phases.

While Fortinet’s FSSO offers a native integration with Windows AD environments and is a widely adopted solution, its heavy dependence on accurate and timely DNS resolution introduces potential reliability challenges—particularly in dynamic network environments. The Collector’s reliance on hostnames (from event logs or DC Agents) and subsequent DNS lookups means that any delay or inaccuracy in DNS updates can result in incorrect user-IP mappings, thereby impacting security policy enforcement.

Fortinet does offer FSSOMA as an enhancement to mitigate this issue. However, deploying FSSOMA requires:

- A FortiAuthenticator appliance or VM,

- A separate FSSOMA license, and

- FortiClient installed on all endpoints.

This approach introduces both additional cost and infrastructure complexity, which is not aligned with the customer’s procurement objectives.

It is also important to acknowledge that there are several alternative SSO solutions in the market that:

- Deliver accurate user identification without relying on DNS,

- Do not require additional licensing or infrastructure, and

- Offer simpler integration with modern identity platforms such as Azure AD, Okta, or Google Workspace.

Given the customer’s requirements—namely, avoiding extra product purchases and reducing integration overhead—it is advisable to explore alternative SSO implementations that can provide reliable and cost-effective user identification without the limitations observed in FSSO's default configuration.

We appreciate your understanding and look forward to a recommendation that meets the customer’s operational and financial expectations.