The Radius Server is correctly setup on the Fortigate, and can pass both the Connection Status and User Test
It seems that we have missed something to tell the Fortigate that if a user is not found locally, that it should then look at a remote Radius Server (the FortiAuthenticator). If we add the user on the Fortigate and tell the Fortigate that the user is a Radius User, then this works perfectly.
But surely this is not correct. You can't surely need to add potentially 100's of users local and then be adding them on the FortiAuthenticator.
What have I missed. I am sure that it must be a case that if the user is not defined as a local user on the Fortigate, that I can tell it to look for the user on the Radius Server.
All help greatly appreciated
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
i had similar case and this was my configuration.
let the communication pass thru Radius, config FortiGate and FAC radius service, then configure FAC to talked to your LDAP server.
under FAC, you need to define Realm, Radius Service Policy and User groups including Radius attributes. Please check also from FAC admin guide how to use with "LDAP filter".
Now under FG you can define group name similar to your FAC user group created.
Fortigate Newbie
Thanks for that
So on the Fortigate, is the key to this in defining a group name "exactly" the same as the FAC usergroup ? I'm sure we tried this. So there definitely isn't some setting somewhere that needs to be set to tell the Fortigate to forward all unknown locally defined users to the Remote Radius server ?
Hi,
Having users on FortiGate, specified, type radius, would work for a few users, especially if you'd like to provide those with FortiToken 2FA but your remote server is not capable of doing 2FA.
But you mentioned FortiAuthenticator !
So there is definitely no need to have users local on FortiGate, even for 2FA.
Therefore completely remote users IS the right way.
First I would highly suggest to have local users defined on FortiGate kept inside a separate user group from those of remote origin.
And so have separate user group for users from remote server, like RADIUS, where this server is defined as sole/exclusive member of user group on FortiGate (NOT mixed with other users).
Then in simplest way possible all the users matching this remote server (those who will be able to successfully authenticate against that server) will be seen as members of this group.
That should work and is simplest way possible how to get remote users from RADIUS (or other things like LDAP/TACACS+) being group members on FortiGate.
Then you can complicate and narrow the things a bit (and I would recommend to get better control over allowed users).
Either on FortiGate side, by feature called "group match", which allows only specific users from remote server, those bearing Fortinet-Group-Name AVP (for RADIUS) and where this string from Access-Accept match user group definition on FortiGate, being only allowed members of the group.
More on Group match in old, but still valid, KB article:
https://kb.fortinet.com/k...amp;externalId=FD36464
Or by narrowing realm and RADIUS Client policy on FortiAuthenticator side only, also to allow only specific users defined on FortiAuthenticator to pass to RADIUS Client (FortiGate in this role).
OR, best way possible, combine those together, so:
---
1. FortiAuthenticator (FAC hereinafter)
- define where you'll get users from, as those can be local users on FAC, or users learned/synced to FAC from your LDAP via Authentication > User Management > Remote User Sync Rules
- group those users on FAC to local group
- set additional RADIUS attributes (AVPs) per group and set Fortinets' Fortinet-Group-Name to string, that will be inherited by all the local users from this group when they authenticate and propagated into Access-Accept
- set realm
- set RADIUS Client > Policy, to use this realm AND !! do NOT FORGET to edit/set allowed groups and select created group, otherwise users will authenticate against realm but would not inherit anything from group AVPs settings
2. FortiGate (FGT hereinafter)
- set RADIUS Server - point to FAC
- set user group with FAC as only member
- set group match to explicitly same string as you have set in FAC and APV Fortinet-Group-Name
- use that group in policy
- test (even 'diag test auth radius <SERVER-FAC> pap <testuser> <password>' should return group membership learned from RADIUS server via/from Access-Accept / Fortinet-Group-Name )
Use, share, enjoy.
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 |
---|---|
1712 | |
1093 | |
752 | |
447 | |
231 |
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.