Skip to main content
daemon
daemon
New Member
July 8, 2025
Question

FortiAuthenticator 802.1x EAP-TLS - answer about accounting

  • July 8, 2025
  • 1 reply
  • 1779 views

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!

    1 reply

    daemon
    daemonAuthor
    New Member
    July 9, 2025

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

    daemon
    daemonAuthor
    New Member
    July 9, 2025

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

    Markus_M
    Staff & Editor
    Markus_M
    Staff & Editor
    July 9, 2025

    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-Single-Sign-On/ta-p/195358 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
      daemonAuthor
      New Member
      July 9, 2025

      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
      Staff & Editor
      Markus_M
      Staff & Editor
      July 10, 2025

      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
        daemonAuthor
        New Member
        July 11, 2025

        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

        Terms & ConditionsAccessibility statement