FortiGate VPN Lands in the Wrong Group: RADIUS Matching
Fortinet-Group-Name is matched against the reply, not your local group label. Trace the three names before widening the match to Any.
The login succeeds, the tunnel comes up, and the user lands on the wrong policy or no policy at all. Nothing in the FortiGate log announces that the group was missing, because from its side authentication worked and the group match simply did not fire. The chain you need to inspect contains three separate names, and they are usually not the same string.
Three names with three jobs
Write all three down before touching any configuration, because two of them live on different systems.
| Record | Illustrative value |
|---|---|
| Directory membership checked by the RADIUS policy | Engineering VPN users |
| Returned Fortinet-Group-Name string | vpn-engineering |
| FortiGate local access group | VPN-Engineering |
The directory group is what your RADIUS policy evaluates. The returned attribute is a value inside the Access-Accept reply. The FortiGate local group is a container that policy references by name. Confusing any two of those produces a login that works and an authorisation that does not.
Where the match is actually made
Fortinet's RADIUS group-matching explanation documents Fortinet-Group-Name as the default group attribute. FortiGate compares the configured remote server and the group-name value against what the reply carries, which means the comparison is against the returned string, not against your local group's display label.
That is why a local group called VPN-Engineering can sit beside a returned value of vpn-engineering and match nothing at all. Case and spelling are not cosmetic in this comparison. Pick one string, use it in the reply, and reference the same string in the gateway's match rule.
On FortiAuthenticator the group has to be associated with the attribute and included in the matching RADIUS service policy, with the group-attribute return control enabled where applicable.
The reply can succeed without the attribute
For NPS or another RADIUS server, enforce the directory-group condition in the policy and then configure the supported reply attribute. A successful password check produces an Access-Accept on its own, and an Access-Accept with no group string is a perfectly valid reply that authorises nothing on the FortiGate side. This is the most common shape of the problem.
Defining a group is not the same as sending it. Those are two configuration steps on two different screens, and only one of them is usually done.
Why matching Any is a trap
An Any remote-group match is a legitimate design when the RADIUS server already admits exactly the population you want. Choose that delegation deliberately. Broadening the match to make a missing attribute go away admits every account the RADIUS server happens to accept, including ones that were never meant to have VPN access. The symptom disappears and the access control quietly stops existing.
If you cannot name who the RADIUS server is supposed to admit, you are not ready for an Any match.
Keep four records for support
When it still does not work, collect four things: the RADIUS policy that was selected, the group attribute actually returned, the FortiGate server and value it was matched against, and the resulting local group. Those four records locate the break without exposing passwords or changing group membership to see what happens.
Test one authorised and one out-of-scope account under the real rule, and check the resulting policy and resource access as well as the authentication result. Only the pair tells you whether the match is doing what you think.