FortiAuthenticator 802.1x EAP-TLS - answer about accounting

[daemon]

Hi,

I'm working with the following setup:

• FortiGate

• FortiAuthenticator

• FortiSwitch (wired access)

• FortiAP (wireless access)

User identities are synchronized into FortiAuthenticator via SAML from Azure AD. Based on SAML group membership, I assign users specific VLAN IDs and group name attributes.

Wi-Fi Scenario (FortiAP):

• 802.1X authentication is handled by FortiAuthenticator.

• FortiGate acts as the NAS and receives RADIUS accounting.

• FortiGate successfully builds RSSO sessions, including username, IP address, and group name.

• I can create identity-based firewall policies based on the group – :white_heavy_check_mark: this works perfectly.

LAN Scenario (FortiSwitch):

• 802.1X authentication is again handled by FortiAuthenticator.

• FortiSwitch acts as the NAS and communicates directly with FortiAuthenticator.

• FortiAuthenticator assigns the correct VLAN ID, but FortiGate does not receive any identity/group info.

• In Firewall Users, no username or group is shown – only traffic from IP within the VLAN and have name from certificate.

What I want:

I’d like wired 802.1X connections via FortiSwitch to behave the same as Wi-Fi:

• FortiGate should be aware of the user identity and group,

• so I can build consistent firewall policies based on user groups (e.g., "infrastructure").

My question:

Is this possible using:

• FortiAuthenticator (with Azure AD via SAML),

• FortiSwitch as RADIUS NAS,

• and FortiGate,

• without requiring any endpoint agents?

Specifically:

• Can FortiAuthenticator forward RADIUS accounting to FortiGate for RSSO?

• Is there an official recommendation or workaround?

Thank you very much in advance!

[Dorothy_Olvera]

Authenticator doesn’t forward RADIUS accounting to FortiGate, so when FortiSwitch talks directly to it, FortiGate misses user info. For wired setups with full user identity and group visibility, it’s best to have FortiGate act as the NAS or manage the switch via FortiLink.That way, FortiGate gets all the details needed for RSSO and firewall policies no agents required.

[daemon]

Could you give me some advice on how to achieve this? I use Fortilink interface.

[Dorothy_Olvera]

Hey, since you use FortiLink, just have FortiGate handle 802.1X directly through the switch. FortiGate will then get all user info for RSSO and firewall policies. No agents needed.

[daemon]

Is there any documentation on this? I couldn't find anything like that anywhere, Fortigate only handles accounting for AP.

[Markus_M]

Hi daemon,

try it different. FortiGate has FortiAuthenticator as a RADIUS server for directing the EAP-TLS to it. Once authentication is done (with EAP-TLS), try to have FortiGate send RADIUS accounting to FortiAuthenticator and have FortiAuthenticator translate it to FSSO. Send FSSO back to FortiGate.

This dated PDF https://community.fortinet.com/t5/FortiAuthenticator/Solution-Guide-Fortinet-Solutions-RSSO-RADIUS-S... has something similar for VPN, whereas only the part of FortiGate configuration for sending accounting messages, and FortiAuthenticator for receiving and translating them to FSSO.

Best regards,

Markus

[daemon]

This unfortunately uses LDAP as the source of users, I have already come across this manual but unfortunately I am not able to complete step 4 because I don't have LDAP and I sync users to FAC via SAML.

[Markus_M]

Hi daemon,

LDAP shouldn't be relevant, the guide is not meant to be followed step by step, but the FortiGate should start sending accounting messages after authentication has finished. How the authentication is done on the backend (FAC) should not matter.

Best regards,

Markus

[daemon]

Hi Markus,

Thanks for the clarification.

I've tried multiple approaches to get RSSO communication working, but I'm currently stuck due to issues with the user accounts. The accounts I'm working with are integrated into FortiAuthenticator via SAML, and that seems to be the root of the problem.

When configuring accounting, I don't really have a valid option to choose from:

• If I select LOCAL, the users are not recognized because they are not local accounts.

• If I select EXTERNAL, the only available option is LDAP, which doesn’t apply to my setup with SAML users.

Unfortunately, this setup doesn’t seem to work with the current RSSO configuration. I’m likely missing something specific that applies to SAML-based users, but I couldn’t find clear documentation or examples covering this.

Here's a brief excerpt from the logs, which may help highlight the issue:

Found no FAC local group for remote LDAP users invalidate cache status for user that previously failed group lookup: SSO_EXT_USER/USER.TEST

It looks like the group mapping or cache is failing, possibly due to the nature of the SAML accounts.

Could you please advise if there's a specific way to enable accounting or group mapping for SAML-authenticated users in this context? Any concrete guidance would be much appreciated.

Best regards,
Daemon