Description
This article explains how FortiGate parses a successful RADIUS authentication response (Access-Accept) to learn group membership information for the authenticated user.
Scope
FortiGate, FortiAuthenticator.
Solution
Introduction:
FortiGate is frequently used to authenticate users in various contexts, such as VPN, WiFI, or Captive Portal authentication. FortiGate can also apply user groups (with explicit or implicit members) to provide granular policy matching and thus granular access control.
- 'Explicit' members in this context refer to groups that consist of local or imported users.
- 'Implicit' members in this context refer to groups that are configured with one or more remote servers, and a matching condition that users must meet to be considered a member of the group.
This article delves into groups with remote RADIUS servers and what information FortiGate looks for to determine if a user may be considered a member of a group on FortiGate.
RADIUS Attributes:
Any information conveyed via RADIUS is passed in so-called RADIUS Attributes; these are default or vendor-specific attributes with specific names, a specific value format (like string or IP), and a value depending on the situation.
By default, FortiGate checks for group information in a Fortinet-specific attribute called Fortinet-Group-Name. This attribute should contain the group name in a string format, and may appear multiple times in the same RADIUS response (Access-Accept).
The RADIUS server must include this attribute in the response if the FortiGate should match the authenticating user to one or more groups.
In the above example, the FortiGate receives two strings, 'test-group' and 'test2', and can assign the user to a group like this:
config user group
edit "radius-vpn"
set member "FAC-VM"
config match
edit 1
set server-name "FAC-VM"
set group-name "test-group" <----- This string must match the string in the RADIUS attribute.
next
end
next
end
FortiGate can also use alternative RADIUS attributes for group membership if so desired, either the Class or FilterID attribute. This may be set via CLI in the RADIUS server configuration:
config user radius
edit <>
set group-override-attr-type <filterID|Class>
end
By default (meaning Fortinet-Group-Name attribute is checked), this setting is unset.
FortiAuthenticator:
If FortiAuthenticator is used as a RADIUS server, it must be configured to provide the Fortinet-Group-Name (or alternate RADIUS attribute) in the response.
FortiAuthenticator does not automatically create and include a corresponding attribute if a group is defined on FortiAuthenticator.
To ensure FortiAuthenticator sends the group attribute, the following needs to happen:
- A user group needs to be created.
- After creation, the user group needs to be edited so a RADIUS Attribute can be added.
- The 'Fortinet-Group-Name' attribute is found under vendor 'Fortinet'.
- Both 'FilterID' and 'Class' are found under vendor 'Default'.
Once the attribute has been added to the group and the user is a member of the group (either outright or matching the filter), the group needs to be added to the RADIUS policy, and filtered for:
FortiAuthenticator does not include attributes from groups that are not filtered for!
As an alternative, the group name attribute (Fortinet-Group-Name, Class, FilterID) may be configured for each imported user in FortiAuthenticator, and will always be included, but this results in significant management overhead. It is recommended to manage attributes related to group membership in group objects, not in individual user objects.
Third-party RADIUS servers:
If a third-party RADIUS server is used (like NPS, or a FreeRADIUS setup, or similar), the third-party RADIUS may not be familiar with Fortinet-specific RADIUS Attributes like 'Fortinet-Group-Name'.
To this end, there is an available RADIUS dictionary (link below) that lists the Fortinet-specific attributes by name, associated ID, and expected type. If the RADIUS server does not allow for importing the dictionary, attributes can be added manually.
As an alternative, all RADIUS servers should support the default RADIUS Attributes, including 'Class' and 'FilterID'.
Related articles:
Technical Tip: Fortinet's RADIUS Dictionary and VSAs (latest)
Technical Tip: How to configure Group Matching using Radius 'Class' Attribute on Windows NPS
