Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Wayne11
Contributor

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

4 REPLIES 4
Jirka1
Contributor III

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

xsilver_FTNT
Staff
Staff

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 [link]http://206.190.36.45[/link] , 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

 

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

Wayne11

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

xsilver_FTNT

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.

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

Labels
Top Kudoed Authors