Hello,
I've got 2 Fortigate 600E clusters on which my students will go to the internet.
The students will be authenticated by a Windows NPS server. In the connection request policy I've created a "Radius server group" to forward the accounting packages. The NPS server seems to be loadbalancing the accounting packages instead of sending the accounting packages to both clusters. When this happened the RssO users are logged on the wrong Fortigate cluster.
So I'm looking for a way to sync the RssO users between the cluster. I haven't seen a way to do is and I suspect it is not possible with Fortigate... Anyone have any experience with this issue?
Thanks!
Ivo
Both FSSO Collectors, standalone (free of charge), or the one in FortiAuthenticator (paid), can process RADIUS Accounting packets to create SSO users, which then can be distributed according to Group Filters to connected FortiGate(s).
Therefore, if you are not able to fix NPS to send RADIUS Accounting in parallel to both FortiGates and do RSSO on them, then you can set up at least free standalone Collector on any DC (preferred, but any Domain member MSFT server class OS is fine) and collect+process RSSO there and distribute it to connected FortiGates.
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Hi,
Thanks for the awesome response. I'm going to configure it right away!
Will keep you posted.
Ivo
Hi,
have you made it working ?
Did the FSSO Collector solved your issue ?
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
xsilver wrote:Hi,
have you made it working ?
Did the FSSO Collector solved your issue ?
I almost got it working. I'm receiving the accounting packages on the FssO agent.
I can see them coming in the debug log of the fsso agent.
Aparently the Windows NPS isn't sending the framed-ip-address in the accounting package. So the users won't appear in the "Logon user list". I've created a ticket with Fortinet Support and got a session with them tomorrow and try to resolve this.
I think we just need to add a custom attribute in the connection request policy.
In the future we also might want to use groups with the accounting packages. Do you have any best practices for those use cases?
Thanks for thinking along!!
Best practice for RSSO (RADIUS based Single Sign On) is to send accounting data from NAS, not NPS.
Usual practice is to send accounting from Network Access Server/Service, therefore from AP, WLC or Firewall.
Because those are the entry points on border and those do have (should have) complete data.
NPS, Network Policy Server/Service, might not have complete data, for example:
- NAS is WLC, and does authenticate via RADIUS against NPS
- but NPS is not the one assigning IP, but NAS uses 3rd party DHCP
Above mentioned scenario is not uncommon.
And this way NPS do not know which IP was assigned through NAS from DHCP.
Therefore accounting for RSSO from NPS might not be ideal. Then set it the way that accounting will work this way ... - WLC will send Access-Request to NPS which does authenticate user - NPS will return back Access-Accept _WITH_ access privileges (selected group tagging attribute for FGT) to WLC (NAS)
- WLC will assign IP (maybe with help from 3rd party DHCP)
- WLC will then send Accounting-Request _WITH_ user group tagging data resent from NPS, plus Framed-IP-Address
- this way WLC will be able to send complete data to RSSO handling point, and it does not matter if it's FGT or Collector Agent
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1735 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.