Hot!FSSO - Identity-based policies some sessions fall through

Author
Wayne1
Gold Member
  • Total Posts : 198
  • Scores: 4
  • Reward points: 0
  • Joined: 2004/03/11 08:04:32
  • Location: Switzerland
  • Status: offline
2019/04/18 03:19:44 (permalink) 6.0
0

FSSO - Identity-based policies some sessions fall through

Hi
 
We are currently testing identity-based policies with FSSO and Agents 5.0.0256 on our 2 DC's with a FG Cluster 6.0.4. So far everything works well with only one exception, some sessions/applications are not using the user-based policy and take the next IP-based policy. 
Policy 1 has the FSSO User Group and the IP range address as source, destination is "all" and services also "all" with Deep Inspection active. So far almost all session are catching this policy 1 for the corresponding users and the log show that FSSO Agent collect correctly the the MAC Address, Username and IP address of such users and is delivering to the FG. But some sessions with HTTP, HTTPS or other Services from such a computer are not matching this policy and use the next one which is only IP based and fits as well. But what I would like to know is why those sessions have no User shown in the logs, only IP address and MAC address even the FSSO Agents both see this user as authenticated with Status OK at that time. So the Forti should already know from which user this session was initiated and also use policy 1. Somehow 1 or 2 hours later, all Session goes through the correct user based policy and are not falling through anymore.
 
We use the FSSO Collector Agents with the same setting on both Win2019 DC's:

Thx
Wayne

Attached Image(s)


 
FG-200E, FG-200D, FG-100E, FG-60E, FWF-60D, FWF-60E, FAZVM64, Fortimail VM
#1

4 Replies Related Threads

    Jirka
    Gold Member
    • Total Posts : 130
    • Scores: 4
    • Reward points: 0
    • Joined: 2014/07/09 11:34:53
    • Location: Czech Republic
    • Status: online
    Re: FSSO - Identity-based policies some sessions fall through 2019/04/18 05:18:25 (permalink)
    0
    Hi Wayne,
    this is an interesting question that interests me as well. I've met it several times.
    I hope we find the cause.
     
    Jirka
    #2
    xsilver
    Expert Member
    • Total Posts : 449
    • Scores: 103
    • Reward points: 0
    • Joined: 2015/02/02 03:22:58
    • Location: EMEA
    • Status: offline
    Re: FSSO - Identity-based policies some sessions fall through 2019/04/23 07:09:13 (permalink)
    0
    Hi Wayne,
     
    it does not matter if Collector see users authenticated, important is how does it see FortiGate (FGT).
    So, when user traffic fall into second, non-FSSO policy, pay attention to what is on FGT and compare it to workstation and Collector data about source IP, user and group membership.
     
    Possible issues might come from IP changes (workstation might be notebook which had turned WiFi on and now has different IP but user is not known from this IP, or switched back to wired but DNS and so FSSO kept only one IP of previous connection).
    Another usual issue source is group membership. Which might get unresolved due to issues to get response back from LDAP, or due to group membership changes.
    Next source might be in multiple Collectors where user data are not properly updated and FGT unfortunately connected to the Collector with less users in database.
    Issues might be more .. so, Id start from workstation, get IP addresses, check DNS, check user group membership and follow path to check Collectors (and especially the one to which is FGT connected), then check how FGT see the user and IP addresses of the workstation, and one of last steps might be flow debug and session list check. Because there might be even session from before user was known, still governing traffic through firewall, which is state-full !
     
    Some commands which might help from my FSSO debug plan:
     
    B.2. Workstation’s output under affected user account
    ipconfig /all
    echo %username%
    ping -4 -n 2 %logonserver:~2%
    net use
    time /T
    date /T
    B.3. on FortiGate collect output of those commands (log console output to text file, SSH connection preferred over direct console for its speed):

    get system stat

    diag debug reset
    diag debug en
    diag debug authd fsso server-status
    diag debug auth fsso list
    diag fire auth list
    diag wad user list

    diag sys session filter clear
    diag sys session filter dst 206.190.36.45
    diag sys session clear

    diag debug flow filter clear
    diag debug flow filter addr 206.190.36.45
    diag debug flow show fun en
    diag debug flow show con en
    diag debug flow show ipr en
    diag debug flow trace start 50
    diag debug enable
     
    # On the workstation open a browser and go to http://206.190.36.45 , wait for an issue reoccurence
    # mentioned IP supposed to get resolved to server of yahoo.com but used like this in filters makes traffic and session debug easier
    # after issue present and flow stops, run bellow commands to terminate debug

    diag debug reset
    diag sys session filter clear
    diag debug flow filter clear
     

    Kind Regards,
    Tomas
    #3
    Wayne1
    Gold Member
    • Total Posts : 198
    • Scores: 4
    • Reward points: 0
    • Joined: 2004/03/11 08:04:32
    • Location: Switzerland
    • Status: offline
    Re: FSSO - Identity-based policies some sessions fall through 2019/04/25 05:53:15 (permalink)
    0
    Hi Tomas
     
    DNS and IP address changes I can definitely exclude, this are fixed IP's by DHCP reservation and with static DNS records. What I could see in such a situation, on the Agent the User is shown as authenticated, but on the Forti "Firewall User Monitor" the user is missing. So it must definitely something between Agents and Forti.
     
    Thank your suggestions I figured out the main problem, it always happens when we (IT Admins) for e.g. started an MMC Application with the RUNAS command and authenticated once again to the DC with Domain Admin credentials for this MMC, afterwards the existing authenticated User in the Agent list and it's bound IP and MAC address was overwritten of course with the Admin user and of course fall then through the policy with all further session. I mean, it's totally logical, we just forgot the case that we start the MMC within RUNAS and once started, all further sessions of such a computer are not bound to the origin user anymore. Now set a filter to the Admin and this has reduced the falling through session to Applications which were started probably before authentication happened, mostly it's TeamViewer or some https sessions to some MS servers.
    Thank you very much for your detailed answer, we will update this thread with our findings for other sessions which are still falling through some other FSSO based policies.
     
    Best regards
    Wayne

     
    FG-200E, FG-200D, FG-100E, FG-60E, FWF-60D, FWF-60E, FAZVM64, Fortimail VM
    #4
    xsilver
    Expert Member
    • Total Posts : 449
    • Scores: 103
    • Reward points: 0
    • Joined: 2015/02/02 03:22:58
    • Location: EMEA
    • Status: offline
    Re: FSSO - Identity-based policies some sessions fall through 2019/04/25 06:22:02 (permalink)
    0
    Hi Wayne,
     
    thanks for mentioning your findings.
    Yes, it is logical as once you take over ownership of the workstation via RUNAS, then first there are logon events for your admin on workstation and the original user is also not present in hive and so workstation verification will fail for that user.
    I would suggest 'Set Ignore User List' to your attention, and if suitable then put your admin users you are using for RUNAS into the list. List should also contain any service accounts which are used to run background service operations on workstations. List also accepts wildcards.
     
    One another hint for possible readers of this thread .. if user is on Collector, but not on FortiGate, it also might mean that there is Group Filter, either global one or specific for that FortiGate, which do not contain any group from those where user is memberOf.

    Kind Regards,
    Tomas
    #5
    Jump to:
    © 2019 APG vNext Commercial Version 5.5