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

FSSO and TS/Citrix Best practices and experiences

Hi, 

 

recently moved on 5.6 and it is a huge improvement from 5.4 I am actually getting use to the new GUI!.

 

The objective of this thread is to collect real life experience on FSSO implementation so to give people that google how to configure FSSO, some updated information on how to practically do it. Fortinet support seems not to have a clear idea on how to do that, and every support tech that you call will have a different answer (someone says WMI is the way, someone says agent mode is the ONLY way)

 

What i know so far:

 

- When TS/Citrix environment are in use, YOU HAVE TO use the TSagent. Even if polling mode works, it will apparently log the last user logged in and associate with that particular host IP. Next user that logs in will override the last user in the logs: new user will appear, previous user will disappear.

 

What i DO NOT know:

 

- in FSSO configuration, you can only reference one LDAP. But i'd like to reference two from the same FSSO for HA purposes, can this be done?

- what is the best way to intercept MACs (as in Apple laptops) that have the AD integration connector thing

 

What i think is at current stage (with 5.6) the best way to implement FSSO:

 

- Install collector agent somewhere on a member server

- Deploy DC agents on ALL DCs and restart DCs, send collector agent

- Deploy TSAgents on ALL TS/Citrix servers and restart, send to collector agent

- Config LDAP server

- Config FSSO and point to the collector agent IP and reference the configured LDAP(s?).

 

Is this the right/best way to get to the closest 100% accuracy? What is your experience on the matter?

 

thanks

8 REPLIES 8
Philippe_Gagne
Contributor

Hi,

 

About the LDAP. You can have two LDAP servers in the same configuration. You have to do it in CLI.

 

config user ldap

edit LDAP

set server "192.168.1.1"

ser secondary-server "192.168.1.2"

next

end

 

From there, you will be able to use only one LDAP configuration in FSSO. LDAP redundancy done!

 

FSSO, I suggest installation of two collectors. It can be install on DC. In the Fortigate configuration, you will add the IP of collectors in the same FSSO configuration. In CLI, it looks like:

 

config user fsso

edit FSSO

 set server 192.168.1.1

 set password fortinet

 set server2 192.168.1.2

 set password2 fortinet

 set ldap-server "LDAP"

next

end

 

For TS/CITRIX: yes, you have install TSAgent on all of them. You already said it. You have to configure it to send logs to both collectors. 

 

From there, I think everything should work fine! You were close! :)

 

Philippe

 

myrdin

Thanks Philippe this is great!

 

So is this the actual suggested/recommended way to set up FSSO by Fortinet? I cannot seem to get a consistent answer from support. 

 

Thanks again

 

 

Philippe_Gagne

Hi,

 

You're welcome! :)

 

In the NSE4 course, Fortinet talks about agent mode and polling mode. I prefer agent mode because in massive login hours (like 8:00AM, when everybody start there working day!), I'm sure collectors will not miss any login events. I have a customer who manage around 800 users on three Active Directory domains, it works like a charm! 

 

Mobile users can be a challenge when they switch between wired and wireless connectivity on the network. No login event will be sent/shown in Security Event logs on the DCs. NTLM can help, but it can takes few minutes the grant back there specific access. Or, you can use "Mobile agent" with FortiClient. I think you need EMS and Mobile license in the fortigates.

 

Other challenge, have a TAC case open on this one: RDP connections take precedence on local login. I explain: I got a computer where a user have restricted access to Internet, I'm logging to TS with an admin account that have full access on Internet... local computer will have the same rights for the time this RDP session is open. DC Agent see an event "MSV1_0" from the local computer an assign the login seen to this IP.  I can let you know the result if needed! :)

 

Have a nice day!

 

Philippe

 

xsilver_FTNT

Hi myrdin,

there is not a single "right" way to configure the FSSO and that's why you are getting different answers from support.

There is multiple modes/ways to set FSSO properly and every one has it's own strengths and weaknesses.

In general:

- agent mode (DC/TS agents + collector) si considered the most robust solution. But some admins do not like, or their corporate security policy do not allow them to instal anything non-MSFT onto DC. As this more rely on agent installed on every DC and TS, then it's this weak point which can revert this mode useless (unacceptable) for certain customers. - agentless/polling .. and this can be done from FortiGate or from Collector. And to make it "simpler" there are 3 polling modes on Collector side, while FortiGate does WinSec poling only. I'd consider Winsec better then NetAPI. And WinSec+WMI better then WinSec alone. WinSec poling is good to get logon events like 4624 made by MAC-OS workstations. And when polling then definitely from Collector and not from FortiGate. But hey, if you have SoHo deployment, one DC, 20 users .. well then polling from FortiGate might be useful option. For anything bigger I'd use standalone Collector (it's free so why not to use that and spare resources on FortiGate).

 

When running standalone collector, use it in Advanced mode (mean LDAP group format). As if you add LDAP to FortiGate's FSSO Agent config, it will let you use that LDAP to choose user groups into filters and set that filter on Collector from FortiGate. And FortiGate will do so in LDAP format. Match.

If you have more FortiGate units and want a same group filter for all, then rather set that filter on Collector, as Default (for all connected FortiGates which did not pushed their own specific filter), and let FortiGate without LDAP in FSSO to gather groups from Collector.

 

Not enough? Bigger network ? Tiering! Yes, FortiAuthenticator has built-in Collector as well and can scale up. Plus can do RADIUS accounting to FSSO, Exchange serves polling, syslog to FSSO, SAML and more .. basically any authentication into FSSO and to FortiGates. Part of that could be done even in standalone collector.

 

So ..

- if you have Collector on FortiGate, you do not need dual LDAP as that LDAP is not used for group membership, but just for group filter settings and ease of administration.

- MAC-OS in the network ? WinSec polling from Colelctor

- Terminal Servers ? Install TSAgent on each of them, unless you want to use explicit proxy (WAD) on FortiGate and does session based NTLM authentication via proxy (older way to handle TS).

- cannot install DC Agents ? Use polling from Collector

- cannot install Collector on DC ? Install on any domain member running server version of Windows, not necessarily DC

 

Hope I haven't scared you much and gave a bit of insight why FSSO deployments can differ but still be a best way for specific situation/restrictions/needs.

 

Kind regards,

Tomas

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

myrdin

Thanks heaps for all your contributions

myrdin
New Contributor

btw, what do you consider a large network?

 

Also do you have best practices value for the timers in the collector? or the default will work?

 

thanks

xsilver_FTNT

Hi,

 

> btw, what do you consider a large network?

how about .. 8-10DC++ & 5k++ users

but that is definitely just shooting from hip, because what matter is not amount of users, but network distances (RTT) and amount of logons. This can be largely different. Think of two models: office=where users log-in at 0900 and leave at 1700, and compare to campus/school where users log into lab/class workstations, all of them within few minutes or seconds each time class starts (every 90 minutes or so).

Therefore, regardless the office might have 2-3x the users, from logon events amount the school will be off charts when compared to office model.   > Also do you have best practices value for the timers in the collector? or the default will work?

The best values are those which work for you!

Start with defaults and if you feel the need, change those.

Those should work for most of the networks, but surely not for everyone. Some admins do not want workstation checks, some want them stricten and dead-entry shorter. Think of variables interaction and consequences. There is always something for something.

For example dead entry shorter then 8 hours if good security practice, so workstations failing in check for whatever reason are kept as dead for those 8 hours from last logon seen. Which might 'accidentally' cover all office hours => no impact. But if you shorten this to secure the network without fixing issue with 'not-verified' workstations seen in Collector, then users might get cleared off the list before the end of their work hours complaining thet they cannot access internet or whatever FSSO protecting resource.

 

Bets regards,

Tomas

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

myrdin

once again, thanks for the time you are spending responding to my queries.

 

 

Labels
Top Kudoed Authors