Skip to main content
dieter
New Member
September 14, 2020
Question

CA upload interval to Fortigate

We often have users that are in the FSSO Agent list, but ar not known on the fortigate. Sometimes it takes several minutes.

So user comes to work, logs in. Logon event is picked up by FSSO agent. But user has no access to mail (in cloud) or internet. Explain that to the user...

 

At what interval are logged on users uploaded from FSSO CA to Fortigate ? Can the interval be lowered ?

    10 replies

    xsilver_FTNT
    Staff
    Staff
    September 14, 2020

    Hi,

    once Collector Agent finishes the checking on received logon event, the user is put to internal user list on Collector, and new logon is then pushed to all connected FortiGate units where group membership of that user match with Group Filter.

    This update from Collector to FortiGates is .. usually pretty instant!

    AFAIK there is no option to delay it, and there is no need to do so. Therefore there is nothing to lower.

     

    That brings me, and you, to question Why it is delayed? As it takes "several minutes", it brings me to usual sources, or more precisely mistakes in FSSO setup/design,  where  .. 

    - Collector do not monitor all the DCs (in polling mode) and so delayed logon is actually another new logon, like to exchange, or shared folder which is spotted and processed by FSSO, rather then original logon to workstation

    - Collector operates in DCAgent mode, but workstation made logon towards DC where there is no DCAgent running and listening, so it's missed logon again

    - user's group membership did not matched the Group Filters on first logon, but later on it did so later logon was delivered

    - Network connection between Collector and FGT is too long or choppy, so first logon update was not received by FGT but some consecutive one was OK

     

    I would suggest to make thorough check of FSSO settings, on FGT and on Collector/DCs as well. That all DCs are polled or monitored by DCAgents. That FGT has right Group Filter on Collector. That group membership of users match intended settings of Group Filters. Have a test user and check with single clean account.

     

    dieter
    dieterAuthor
    New Member
    September 14, 2020

    Hi, thank you for the many suggestions.

     

    On a sidenote: In fact a DC without an agent should be no problem, because an agent can collect logon events from logs from different DC's.

     

    So here's our setup:

    - I have agents on all DC's. Working in DC Agent mode. All collect logs from all DC's security logs and from on prem exchange (that server is not a DC btw).

    - Two of the DC's also operate as collector. Fortigate has both configured (primary and secondary).

     

    Communications between collectors and agents seem to be fine. Fortigate has good (and redundant) connectivity to the collectors.

    Group filters are pulled from the fortigate config, I can see them replicated in every agent too ("Filter set by Fortigate").

    Yes sometimes there's an issue with a user who was only minutes ago added to a new group, but we know there's a delay there (group membership is only refreshed when logging on).

     

    In fact, because of the issues we've seen for quite some time, I already rebuilt the entire setup (uninstalling and reinstalling all agents/collectors, redoing the config in them, reconfiguring on the fortigate...). Not that easy (needs reboots, looses connectivity, clears cached users...), so I would not like to do it all over again ;)

     

     

     

    In regard to "missing" the initial logon (when the user first logs on to the workstation): what logon event ID should I be looking for ? I should be able to match it with the agents logon event log, right ?

     

    Our on prem exchange server is not a DC. Should I install an agent on it ? Currently none installed. But then again, a user logging on should be first seen through a logon event to a DC...

    xsilver_FTNT
    Staff
    Staff
    September 15, 2020

    an agent can collect logon events from logs from different DC's.

     

    If we speak about DCAgent, then no. DCAgent collect logons just from local DC as it is hooked directly to LSAS on that DC.

    If we speak about Collector Agent, then in Polling mode, yes. The Collector can poll (retrieve) logs from multiple DCs.

     

    As you described you are in DCAgent mode AND you have two Collectors, then make extra sure that all the DCAgents actually do report to both collectors.

     

    Because first, Collector agents act independently of each other and do not share any info.

    Second, if you do have more than one collector in FGT's config inside a single connector, which I would do for redundancy purpose, then this FGT actually does talk to only one collector at a time, till this permanent socket connection dies, then next Collector in a row is used, till this one fail, and again next one is used. There is no concept of primary and secondary or HA restore back to primary when reachable again. When last one is used, then first one is used again. List of Collectors inside a single connector on FGT is simply a circular list.

    Therefore it is crucial that all the collectors do have their own and accurate list of logons.

     

    FGT # .. that will show you to which collector is FGT connected to in CLI for example .. so debug there first

    diag debug en diag debug authd fsso server-status

     

    DCAgents are listed, if connected, in Collector agent's exported config at the bottom.

    C:\Program Files (x86)\Fortinet\FSAE\saved_config

    Examples:

     

    {DC without agent at all}

    ALFA\R24.alfa.xsilver.org     Domain controller is running 64 bits Windows     Status:DC Agent not installed

     

    {DC with agent, but reporting to just one Collector} ALFA\C24.alfa.xsilver.org    Domain controller is running 64 bits Windows    DC Agent version: 5.0.254.0    [HKLM\SOFTWARE\Fortinet\FSAE\dcagent]       enable_log=0       log_file=C:\Program Files\Fortinet\FSAE\dcagentlog.txt       donot_resolve=1       no_keepalive=0       ignore_list=       domain_DNSsuffix=    [ca]       10.109.19.88=8002  <<< address and port to which collector this agent will report, you should have two such records, those can be added via DCAgent GUI or directly to registry keys {see path in [] brackets}.

     

     

    Q: "what logon event ID should I be looking for ? I should be able to match it with the agents logon event log, right ?"

    A: Well, modern Windows uses most often EventID 4624, Kerberos one .. more on other and useful EventIDs for FSSO in KB.fortinet.com

     

    Q: "Our on prem exchange server is not a DC. Should I install an agent on it ?"

    A: If you do have users who work from non-domain computers, but use Exchange with domain logons to read their emails/calendar, and you want those user be seen in FSSO, then set collectors to read the events from Exchange as well. However, credential verification of those users should spring Kerberos logons as well, so check WinSec as you might see those already. 

    Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
    Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.
    Security Operations Summit: Modernize SecOps. Operate AI-Native.AMER: November 4 | 9:00 AM PST. India and SAARC: November 5 | 10:00 AM IST. EMEA: November 5 | 10:30 AM CET. APAC: November 5 | 11:00 AM SGT