Associating user logins through RADIUS/RSSO with logins through LDAP/FSSO...

[Stan_O_]

...or enforcing per user web filter quotas across login mechanisms.

Good Day.

I'm nearing completion of the initial configuration of our new Fortinet firewall (FG-200D, FortiOS 5.2.3).  It's my first experience with the product/company and, in all, I'm impressed and pleased with the purchase.  One of a few areas I'm struggling to get the behavior I seek is relative to web filtering.

We're using FortiCollector/agent based FSSO for our Windows AD workstations and also support BYOD over wireless utilizing 802.1X with RADIUS authentication. I've configured a policy that allows for 60 minutes of browsing sites in the General Interest - Personal category throughout the workday (with a generous lunch period definition that does not include the timer).  The policy seems to work well, with one exception noticed so far.  When a user consumes their quota on their workstation, a separate quota counter for their same account authenticated through RADIUS to connect to the WLAN still provides a means to circumvent the policy.

Last night I configured RSSO (thanks to the document at http://docs.fortinet.com/d/fortigate-rsso-with-windows-server-2008-nps/download), thinking it may hold the key to associate the user account authenticated through LDAP/FSSO with the same user account authenticated through RADIUS/RSSO.  Alas, in spite of my success early this morning tracking the RSSO logins through User & Device > Monitor > Firewall, I could see in Log & Report > Security Log > Web Filter that separate timers incremented for my (work related, honest) personal browsing activity on my workstation and on my smartphone.

Is it possible to achieve this unified quota approach and can any guidance be offered?

Thanks,

Stan

[xsilver_FTNT · Accepted solution]

Hello Stan,

I'd suggest to open a ticket on Fortinet support site as this gets a bit more complex and I'm not aware of your whole config.

However, FSSO/RSSO/LDAP/RADIUS are different mechanisms and it's hard to combine the login records from all of those. Currently FortiGate see those records as separate login channels and so authentication sessions are made separately for each channel through which the user was seen.

For example:

- user join WiFi network and authenticate to 802.1x via RADIUS

- RSSO is configured on FortiGate and as remote RADIUS server authenticate user and send RADIUS accounting start packet to FortiGate then FortiGate will create RSSO authenticated record for the user/workstation/IP

- then user log to workstation computer with his domain credentials

- FortiGate get those logon data via FSSO from either local DC polling or from standalone Collector Agent and based on those data create FSSO authenticated record

- at that time you should have 2! authentication records, independent of each other, from RSSO and FSSO source

- if you bind both of them to respective user groups, and use both those groups in policy or policies (separate for FSSO/RSSO) then you'll get both timers ticking and when last one times out the user should be disabled from using resource protected by identity-based policy.

However I'd suggest to simplify config and decide which of the mechanisms to use. If all users are domain members, no guest, then I'd go through FSSO only. If you have guests or non-domain members I'd go through guest management in FortiGate and for non-domain members maybe through NTLM authentication fallback from FSSO in the same policy.

There is multiple ways how to combine those auth methods. Another one is to use FortiAuthenticator where you'll consolidate FSSO/RSSO or other auth channels to a single user auth record and then use FortiAuthenticator as RADIUS or RSSO or FSSO data source to FortiGate, so FortiGate would have a single user record for the user and source IP of his workstation (as you should keep in mind that all FSSO is primary source IP based authentication).

Best regards, Tomas

[Stan_O_]

Tomas:

Thanks for the reply and the guidance.  I've taken a minimalist approach to local user groups on the FortiGate to this point, but it sounds like maintaining two timers as long as they tick together would be an acceptable solution.  I've been pulled away from this for the time being, but will follow up here and/or with support as needed.

Thanks again,

Stan