Description
This article describes how to manage to access FortiGate through FortiAuthenticator based on the admin account profile privileges created on FortiGate.
Scope
FortiGate, FortiAuthenticator.
Solution
FortiGate steps:
Create the admin profile with the privileges needed.
Note: The name of this profile must be the exact name used in the FortiAuthenticator step 2 (creating group – RADIUS attributes).
Create a RADIUS Server:
Create a RADIUS Server. In this case, FortiAuthenticator is acting as a RADIUS server.
Note: Verify this with Step 1 on FortiAuthenticator.
This step should be completed after step 3 on FortiAuthenticator.
Create a group on FortiGate that matches the remote server. Note that it is necessary to specify the remote server group name, which is the same name as the Group created on FortiAuthenticator.
Create a new admin user with a wild card enabled to match the group created FortiAuthenticator, so any user that is added to the FortiAuthenticatorgroup will be able to access the FortiGate with the privilege associated with the RADIUS attribute:
FortiAuthenticator Steps:
Assumption: LDAP server config already exists and remote users are imported to FortiAuthenticator.
Configure user group (This is the basic step where RADIUS attributes are matched).
The name of this group is the same used as a RADIUS attribute ‘Fortinet-Group-Name’.
The ‘Fortinet-Access-Profile’ attribute must be exactly the same name as the admin profile created in the Step 1 FortiGate configuration.
In this step, select users from LDAP who want to allow access to the FortiGate.
Configure RADIUS policies:
By default, the RADIUS service is not enabled in the interfaces. Therefore, go through the following path:
System -> Network -> Interfaces, select the interface and enable the RADIUS service.
Tips and Troubleshooting steps:
When using a Read/Write profile, if the profile is being loaded incorrectly (e.g. if the profile always loaded is 'super_admin_readonly' when the profile added is with the 'read/Write' permissions), follow the procedure below:
Verify the fnbamd debugs by running the following commands:
diagnose debug console timestamp enable
diagnose debug application fnbamd -1
diagnose debug application authd -1
diagnose debug enable
The logs will show the login attempt to the exact server and username being used:
2025-06-04 11:13:13 2025-05-06 11:13:13 [httpsd 34483 - 1746526393 info] logincheck_handler[536] -- login_attempt (method=6, vdom='VDOM1', name='h***',admin_name='ADMIN-PROFILE1',auth_svr='Radiusserver')
Note here the profile selected is seen along with the server.
In the example above, the profile is loaded wrongly from ADMIN-PROFILE1 instead of ADMIN-PROFILE2.
Make sure to check the RADIUS server config:
config user radius
edit "Radiusserver"
set server x.x.x.x
set secret ENC XXXX
set all-usergroup enable >>>>
If all-usergroup is enabled, the RADIUS server is implicitly a member of every single user group, with NO filters. Any RADIUS user will match ANY group. In this case, removing the setting of 'all-usergroup' will lead to a match with the correct profile.
2025-06-04 11:13:13 2025-05-06 11:16:13 [httpsd 34483 - 1746526393 info] logincheck_handler[536] -- login_attempt (method=6, vdom='VDOM1', name='h***',admin_name='ADMIN-PROFILE2', auth_svr='Radiusserver')
Related article:
Technical Tip: Remote admin login with Radius selecting admin access account profile
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 2025 Fortinet, Inc. All Rights Reserved.