Skip to main content
bmduncan34
bmduncan34
New Member
October 20, 2019
Question

FSSO Fabric Connector: User Group Source - Collector Agent or Local?

  • October 20, 2019
  • 1 reply
  • 3818 views

We have one Fortiauthenticator functioning as a collector for three DC/TS agents.  Currently on my gate I build FSSO groups locally, referencing an LDAP server, rather than building the groups on the collector and having them pushed to the gate.  I'm wondering if there might be an advantage to creating the FSSO groups on the collector and pushing them.  Is it more efficient to do use the collector in that way?  Another question is - when I create local groups on the gate using LDAP as the source, is that group information getting pushed back to my FAC/Collector in some way, so it knows to monitor those groups?  I'm looking for the most efficient or best practices approach to this setup.  Thanks!

    1 reply

    xsilver_FTNT
    Staff
    xsilver_FTNT
    Staff
    December 13, 2019

    Group Filter difference between standalone collector and FAC (FortiAuthenticator) is that :

    - standalone Collector Agent installed on DC (or any domain member with MS Windows server OS), will accept groups selected on FGT (witch help of set LDAP, which is the only role of LDAP in FSSO config on FGT), and those groups will be set to 'config user adgrp' on FGT and also pushed to Collector as per-FGT's-SerialNumber filter. Applicable to just that FortiGate.

    - on the other hand FAC will not accept those

     

    Group Filters can be set on Collector (does not matter if standalone or the one in FAC), and those can be global. On standalone collector it's done with setting group filter as 'Default' one. Such filter is then applied to all connecting FGT units, unless they do have their own, per SN defined, Group Filters / FortiGate Filtering (on FAC).

     

    That could be used as advantage if you have many FGTs connecting and having similar filter. So you'll define one filter to rule them all ;-). Because AD group change, especially for many separated group filters defined for every single FGT, combined with huge group lists may cause performance troubles during update. In contrary, changing one Group Filter list is cheap (in performance).

     

    So, most efficient .. well, there is not a single 'best' solution. If you do manage your one FGT daily and is proficient in that, but do not want to touch Collector too much, then defining and driving filters from that single FGT is probably the most efficient way. If you manage few FGT, or few tens/hundreds of FGT, units, and need almost similar filters everywhere or with minor differences, or you are more familiar with Collector filter definitions, then most efficient way is to set filter(s) on Collector.

    Terms & ConditionsAccessibility statement