Technical Tip: FortiGate admin access using FortiAuthenticator

[AmirZ]

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:

1. Create a new admin profile (In this example, a read-only profile has been used).

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).

2. 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.

   

3. 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.

   

4. 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.

1. Configure FortiGate client:

2. 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.

   

3. Configure RADIUS policies:

   

   

4. 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:

• ADMIN-PROFILE1 - Has read-only access.
• ADMIN-PROFILE2 - Has read/write access.

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