Internet Access using FSSO

[fmuianga]

Good afternoon,

My firewall is giving access to the Internet to machines that receive the IP that the user with permission used, even though it is a local account it goes to the internet because the IP is recognized in the firewall as the IP of a user with Internet access. I tried to diagnose debug authd fsso clear-logons to clear the cache but the problem prevails.

Let me list the configurations that i did:

1. I installed de FSSO software in domain controller to sync the AD users groups; 2. I created users groups in firewall maped to AD users groups; 3. I created policy IPv4 with the folow information: Name: Full_Access_Users Incoming Interface: Internal (port1) Outgoing Interface: sd-wan Source: all & DSI(users group) Destination: all Schedule: always Service: ALL

The policy is the second counting from top to bottom.

The machine that is not in domain but have the IP thats is recognized by firewall as IP of user with internet access is going to internet for this policy and in fortiview apear the user and that IP going to internet.

I want to block internet access for local users and for users that arent authenticated in my AD.

[xsilver_FTNT]

Hi,

so if I summarize your issue, then some users are stealing IP addresses of already authenticated users known through FSSO, and so those impersonate and pass the firewall as someone else misusing the access privileges of original FSSO user.

That is not a fault of FSSO but flaw of the technology itself.

If you do allow the misuse or have misconfigured DNS, this can happen.

Keep in mind that FSSO is at the end source IP pre-authorization.

I see two possible scenarios:

---

A) original user is logged off and new user was simply provided with IP of the previous user.

In this case new user get unintentionally access according to old user's access privileges, simply because logoff was not detected, or workstation check failed or was not run fast enough.

Solutions:

- retention on DHCP, to keep recently released IPs a bit longer inside and do not provide them back to newcomers so easily

- shorten workstation checks

- use WMI logoff detection on standalone Collector Agent (by default is turned on)

B) new user stole IP of previous FSSO user to gain access

Just a few mitigation hints .. 

- shorten the workstation checks and so user should not pass verification of his existence in AD

- secure DHCP so it's not going to assign IPs to everyone

- split ranges of assigned IPs from DHCP to guests/others and AD computers so then simple source IP in policy will eliminate those out of AD

- make DHCP semi-static, assign static (always the same) IP per MAC to known workstations and reject others

If you wont a stronger authentication then switch to port based identity .. 802.1x !

King regards,

Tomas

[fmuianga]

Thank you for analyzing and for sparing me some aspects

Regards,

Frederico Muianga

[fmuianga]

Hello Tomas, there is one aspect that I think I have not presented that concerns logout or is one of my concerns beyond that above is that local non-AD accounts should not have access to the internet, when i authenticate with a AD account with internet access and then log off to log in with the local Administrator account i reach internet access with this local account. When I log in with an AD account and log out to enter another AD account there it does replace the user on IP because the two are from AD. What might be causing this problem?

That is, with the two AD accounts it is possible to detect the logoff event, now when you log off with an AD account to sign in with a local account it is as if the AD user had not logged in. I want the firewall to detect the logon of the AD user, however much it is to enter with a local account, it should detect the logoff and not give the internet access to a local account.

Thank you very much for your help, your problem analysis was important.

Regards

FMuianga

[xsilver_FTNT]

Somehow missed that one, so hope it will help those who would read later.

If you log into MSFT workstation in AD environment, then there is a logon event. Which could be spotted and processed via FSSO structures and then as user/source-IP/group-membership (for Terminal Servers optionally with assigned source-port-range) passed to FortiGate unit and via authd got into firewall auth list. Which is then used when new session is created and evaluated against firewall policies.

If you logout from MSFT workstation however, then there is basically very limited actions list and nothing we could use as true logoff "event".
However, we can use WMI to check, and that's the reason for "WMI logoff check" by default turned on in standalone FSSO Collector Agent / Advanced options.
In conjunction with Workstation Check, which then would use WMI to periodically validate known user against his presence on workstation. And could trigger user and so source IP record removal if there is issue to verify or clear mismatch (user on workstation != the one Collector expected).

Another possible, and more secure, approach is to use "agent" on workstation.
I'm talking about FortiAuthenticator (FAC hereinafter) as FSSO Collector Agent with conjunction to FortiClient SSOMA (Single Sign-on Mobility Agent) feature/module.
As this client will report any user/workstation/IP status changes to FAC. So logoff from workstation is reported directly by SSOMA agent to FAC without need to rely on AD "events" system.
Similarly SSOMA reports any workstation's IP changes (so no need to periodically check DNS. Computer lock/sleep/hibernate actions are also reported.

Side-note:  Non-AD users, who authenticate against local users storages/databases on FAC or FortiGate can participate in FSSO. If those are for example used in logon to WiFi, and so through some NAS, which is for example RADIUS base-authenticated, then such logon event can create RADIUS Accounting-Request Start message (and similarly Stop message for de-association). And those can be processed be Collector Agents. We are not limited to RADIUS. Syslog and various other approaches like API calls, or iframe logon forms placed in custom portals are possible.

[RachelGomez123]

Follow the Step-by-Step Guide given below for Fortigate Single Sign-On (FSSO)
Configure Fortinet in miniOrange. Login into miniOrange Admin Console. 
Configure SSO in Fortinet Admin Account. Login to Fortigate as an admin. 
Test SSO Configuration. 
Configure Your User Directory (Optional) 
Adaptive Authentication with Fortinet.

Regards,

Rachel Gomez