First time setup putting AD Usernames / Groups into Web Filters

[fred3]

We are introducing a Fortigate_80F for the first time in our networks.  This is a Windows Server based domain network.  We want to set up the Fortigate web filters to pick up usernames from AD Security Groups and assign names or groups to web filters.  Then, the objective is for each User to be treated by the same web filter structure no matter which workstation they may be logged into.

This appears to require two things:

1) Get the Groups / Names attached to the web filter rules in Fortigate.

2) Determine the matching Usernames from web accesses reaching the Fortigate.

How is this best done?

We don't want the Users to have to log into anything new or additional - just the domain at Windows logon.

I've gone through likely references and remain fairly lost.  But, suggested references would be appreciated.

[SoGo]

What you want to do can be done in two ways, through LDAP and through SSO, so you mention only having to authenticate once, I would recommend using FSSO, forti Single Sign On, this is an agent that you install in your AD, and it will send the information of your users and groups to your fortigate, this can be integrated with the security profile, be it web filter, application control, etc, with the ssl vpn users, and even to monitor the users in your network in general, The convenience is that the user only has to log in once on the device so that all the restrictions/permissions settings of the group to which he belongs are applied.

[SoGo]

To download the agent you can find it on the support.fortinet page, you integrate it through the fabric connectors

[Debbie_FTNT]

Hey Fred,

to expand a bit on SoGo's comments:

- FSSO (Fortinet Single-Sign-On) is a mechanism for Fortinet products to read user logins from an AD environment (either by reading the Windows Security Event log on domain controllers, or by hooking into the LSASS service)

- In principle, the Collector Agent would detect when users log into their workstation and this is reported on a monitored Domain Controller

- Collector Agent would then look up the user's groups via LDAP

- Collector Agent would then forward the user login+group information to FortiGate

-> Collector Agent is quite versatile with group filters, ignoring accounts (service accounts for example, to avoid them replacing existing user logins), ignoring IPs, or handling a whole domain forest

- On FortiGate, you could have policies with different groups as source, and depending on the group set the appropriate web filter

As an overview: https://docs.fortinet.com/document/fortigate/6.0.0/handbook/482937/agent-based-fsso

Let us know if you have questions regarding this :)

[fred3]

Thank you!  That's helpful AND encouraging.
Before I go much further, I'm thinking about the big picture: the end user experience. 

If we use FSSO, does the user see anything different?  I'd prefer NOT.

(So the SSO is the domain logon as usual?  And the "single" part means that Fortigate responds nicely to the domain logon?)
We are using 2FA on the workstations.  I'd hope that there wouldn't be any conflict with that.  In the end, the user gets logged on to the domain - which is where this scenario begins, right?
 

[SoGo]

exactly FSSO is transparent from the user, and the logon doesnt change

[fred3]

Debbie,

I'm sorry but that link doesn't seem to work for me.

[Debbie_FTNT]

Hey fred3,

can you try the link again? It works for me just fine.

Regarding 2FA at the workstations, no, FSSO doesn't interfere with that; it passively collects login information from domain controllers and doesn't care what else might be going on with the workstations.

Regarding the users not noticing anything - ideally, this is the case.

There can be a few pitfalls with FSSO, however.

For example:

-> FSSO tracks one login per IP

-> usually this is the user login

-> if a service account or administrator account performs some activity on the workstation, this can trigger a login event and replace the user login in FSSO, and suddenly the user might no longer match the intended policies, because FSSO and FortiGate believe a different user (with different group/webfilter permissions/etc) is active

Another example:

-> if a user moves their laptop from Ethernet to Wi-Fi, this usually includes an IP change

-> FSSO would initially still have the old IP information, and the user might lack access on the new IP

-> FSSO regularly resolves workstation names against domain DNS to verify if IP changes happened

-> depending on which DNS server has the user's IP and which DNS server FSSO checks, it could take several minutes for FSSO to notice the IP change and share with FortiGate to allow the user proper access again

This is to say:
- I would strongly suggest setting up a lab/small-scale test before rolling out FSSO company wide

- check what method of detecting logins (DC Agent, or polling) would work best with your environment

- get all the fine-tuning done (such as ignoring administrators/service accounts, having non-FSSO policies in place for devices that can't log in such as printers/IP phones/etc, ensure DNS servers have updated IP information quickly for FSSO to see,...)

-> test the most common scenarios that might be challenging for FSSO (service/admin accounts interfering, IP changes, RDP (as that can generate a login on the remote AND local workstation, which could again replace the original user),...)

- if you have terminal servers, they will need a Terminal Server Agent running on it to also be covered FSSO (FSSO can then distinguish between different users on the same IP based on assigned port-ranges, which FSSO otherwise does not allow for)

Initial configuration of FSSO can be a headache and a half, but everything you check/test/configure in the beginning will ensure it runs smoothly afterwards :)

[fred3]

Thanks!  Yes, the link is working now.

And, thanks for the comments about logon contexts and the development process.

It sounds like Collector Agents ("CA"s) are used in both methods: DC Agent or polling.

How are these CA's generally hosted?
I might note that we have a fairly small network, distributed across 3 interconnected sites, with 30 users who will be the focus of Fortigate web filtering.  So, maybe polling is fine although the comprehensiveness of logons makes DC Agents attractive for minimizing Help Desk calls. ??

[Debbie_FTNT]

Hey fred3,

yes, Collector Agents are used in both DC Agent and polling. They typically run on a host (frequently one of the domain controllers) in your network; the Collector Agent runs under a specified service account that needs some privileges to modify the local registry of the host it's running on and, if you're doing polling, Event Log reading permissions (https://community.fortinet.com/t5/FortiGate/Technical-Tip-Restricting-FSSO-service-account/ta-p/1980...)
In your case, you could plop the Collector Agent on a host in your central site (if you have one) and then either have it push out DC Agents to the domain controllers (you don't have to install DC Agent manually, Collector Agent can do that when you select which DCs to monitor), or just select what DCs you want to poll. It shouldn't make too much of a difference if you go with DC Agent or polling; in one the Collector Agent is accessing event logs on the DCs, in the other the DC Agent hooks into LSASS to monitor user logins and forwards relevant information automatically.