Let’s assume a simple scenario. You have two different teams managing your FortiGate firewalls. One team is made up of network administrators who need full access to the firewalls. The other team only needs limited access and should not be able to make any configuration changes.
A common way to handle this is by using administrator profiles and a remote radius server. You can assign different admin profiles based on who is logging in, without creating local users on every firewall. In this post, we will look at how to achieve this using Cisco ISE and Radius. You do not have to use Cisco ISE, any Radius server can do the job, but this post focuses on Cisco ISE since it is commonly used in enterprise environments.


Overview
For this example, we will have two users, each belonging to a different group with different access requirements. In most environments, group membership is managed by something like Active Directory. For the sake of simplicity, I am going to use local identity groups on ISE.
On FortiGate firewalls, there is a concept called Admin Profiles. An Admin Profile defines what a user can and cannot do on the firewall, such as whether they can enter configuration mode or only run specific show commands. FortiGate comes with two built-in profiles called super_admin and prof_admin. We will also create two custom profiles called read_only and no_access.
- bob is part of the network-admin group and needs full access (super_admin)
- brad is part of the noc-user group and only needs limited access (read_only)
We will use the following components for this example.
- Cisco ISE
- Version - 3.4.0.608 patch 3
- IP address - 10.10.0.13
- FortiGate
- Version - v7.6.3 build3510
- IP address - 10.10.0.150
TL;DR
When a user logs in to the firewall, the firewall sends a Radius request to the Radius server, Cisco ISE in this case. ISE first checks the user credentials to see if the login is valid.
If the credentials are valid, ISE then looks at the user’s identity group and evaluates the authorization policy. Based on this, ISE responds with an Access-Accept message and includes vendor-specific attributes that tell the firewall which Admin Profile to apply to the user.
If the credentials are invalid or the user does not match any allowed policy, ISE responds with an Access-Reject, and the login is denied.
FortiGate Configuration
Let’s start with the FortiGate side configuration, which is pretty straightforward. Ideally, you should configure your Radius server first before making any changes to the firewall.
Define the Radius Server
First, define your Radius server by navigating to User & Authentication, Radius Servers and clicking Create new.

config user radius
edit "ise-01"
set server "10.10.0.13"
set secret ENC AeEJIivhN0si63ndgiVK
set nas-ip 10.10.0.150
next
endCreate a User Group
Next, create a user group on the FortiGate. This group will be used to map users authenticated via Radius to the firewall. Navigate to User & Authentication, then User Groups, and create a new group. Set the type to Firewall.
Under Remote Groups, reference the Radius server we created in the previous step. You can ignore the Members field.

config user group
edit "radius-user-group"
set member "ise-01"
next
endAdmin Profiles
Next, we will create two admin profiles, read_only and no_access. As the names suggest, the read_only profile provides read-only access, while no_access does not allow any administrative access. These profiles will be referenced in the upcoming steps when we map users and permissions coming from the Radius server.

config system accprofile
edit "read_only"
set secfabgrp read
set ftviewgrp read
set authgrp read
set sysgrp read
set netgrp read
set loggrp read
set fwgrp read
set vpngrp read
set utmgrp read
set wanoptgrp read
set wifi read
set cli-diagnose enable
set cli-get enable
set cli-show enable
set cli-exec enable
set cli-config enable
next
end
config system accprofile
edit "no_access"
next
endCreate an Administrator
Next, create an administrator user on the FortiGate. Navigate to System, then Administrators, and create a new administrator called radius_admins.
Set the type to Match all users in a remote server group, and for Remote User Group, select the radius-user-group that we created in the previous step.

This part can be confusing, especially if you are coming from another vendor like Palo Alto. This administrator is not a real user account that someone logs in as. It is a placeholder used by the FortiGate to map Radius authenticated users to an admin context.
You will also see an Administrator profile field, which in this example is set to no_access which we created earlier. This profile is not what ultimately defines the user’s permissions. When a user logs in, the Radius server, Cisco ISE in this case, authenticates the user and sends back the admin profile that should be applied. One of the main benefits of this approach is that you do not need to create or manage local administrator accounts on the firewall. All user identities and access control are managed on the Radius server.
You also need to configure set accprofile-override enable via the CLI, as this option is not available in the GUI. This is required so that the FortiGate can apply the admin profile sent by the Radius server.
config system admin
edit "radius_admins"
set remote-auth enable
set accprofile "no_access"
set vdom "root"
set wildcard enable
set remote-group "radius-user-group"
set accprofile-override enable
next
endCisco ISE Configuration
On the Cisco ISE side, there are a few different components that need to be configured for this to work. This includes adding the firewall, adding the FortiGate Radius dictionary, creating authorization profiles, and configuring policy sets. We will go through each of these one by one.
Radius Dictionary
A Radius dictionary defines vendor-specific attributes that are used during authentication and authorization. Fortinet uses vendor-specific attributes to pass information such as Admin Profiles.
A dictionary file that identifies FortiGate Radius vendor-specific attribute value pairs may look like this.
VENDOR Fortinet 12356
BEGIN-VENDOR Fortinet
ATTRIBUTE Fortinet-Group-Name 1 string BOTH
ATTRIBUTE Fortinet-Client-IP-Address 2 ipaddr BOTH
ATTRIBUTE Fortinet-Vdom-Name 3 string BOTH
ATTRIBUTE Fortinet-Client-IPv6-Address 4 octets BOTH
ATTRIBUTE Fortinet-Interface-Name 5 string BOTH
ATTRIBUTE Fortinet-Access-Profile 6 string BOTH
END-VENDOR FortinetSave this file as dictionary.Fortinet and import it into Cisco ISE by navigating to Policy, Policy Elements and Dictionaries. Then, navigate to Radius, select Radius Vendors, and click the Import button.

Once imported, it will be listed under Radius Vendors. Out of all the available attributes, the one we will be using is called Fortinet-Access-Profile. This attribute is used to tell the FortiGate which admin profile should be applied to the user after a successful login.

Network Device Profiles
Network device profiles in Cisco ISE are used to define vendor-specific settings, such as which Radius dictionary to use and which protocols are supported. This is important because ISE needs to know how to interpret the attributes sent by the device and which attributes it can return.
To create one, go to Administration, Network Resources, then Network Device Profiles. From here, you can either use an existing profile (if you have one already for Fortinet) or create a new one and assign the Fortinet Radius dictionary we created in the previous step.

Add the Network Device
Next, add the Firewall to Cisco ISE. This tells ISE which device will be sending Radius requests.
Navigate to Administration, Network Resources, then Network Devices and create a new device. Specify the hostname and IP address of the firewall, then associate it with the device profile we created earlier. You can leave most of the other fields set to their default values.

Next, select the tick next to the Radius Authentication Settings and enter the Radius shared secret, ensuring it matches on both sides.

Authorization Profiles
Authorization profiles define what access is granted to a user after they have been successfully authenticated. This is where we tell ISE which attributes to send back to the firewall, such as the user role and privilege level.
You can navigate to authorization profiles by going to Policy, Policy Elements, then Results, and selecting Authorization Profiles.

For this example, we need two authorization profiles. One profile is for network-admins and the other is for noc-users. These profiles will be referenced later in the authorization policy.
Each profile is set to ACCESS_ACCEPT and associated with the FortiGate Admin Profile. Under advanced attributes, we will use the Fortinet-Access-Profile attribute to tell the FortiGate which admin profile should be applied to the user. Make sure the profile name sent by the Radius server matches exactly the admin profile name configured on the firewall.


Identity Groups and Users
As mentioned earlier, I am using local users and identity groups in Cisco ISE for this example. In most production environments, this would usually be an external identity source such as Active Directory.
Here, you can see two local users, bob and brad, each assigned to their respective identity groups. The network-admin group will later be mapped to the super_admin profile on the firewall, while the noc-user group will be mapped to the read_only profile.

Policy Sets
Policy Sets in Cisco ISE define how authentication and authorization requests are handled. They allow you to match incoming requests against specific conditions and then apply the appropriate authentication and authorization logic.
You can navigate to policy sets by going to Policy, then Policy Sets. In this example, we created a dedicated policy set for FortiGate firewalls.

A policy set can be matched against many conditions, such as device vendor, device location, or protocol type. To keep things simple, we are matching the policy set based on the IP address of the firewall using the Radius NAS IP address (this doesn't scale well on real environments, as you may have guessed 😄)
Within the policy set, the authentication policy is evaluated first. This step verifies who the user is and checks their credentials. In our case, authentication is done against the internal user database in ISE.

Once authentication is successful, the authorization policy is evaluated. This determines what level of access the user should receive. Here, we match users based on their identity group and return the appropriate authorization profile, which maps the user to either the super_admin profile or the read_only profile.

Testing and Verification
To verify everything is working as expected, you can check the Radius authentication logs in Cisco ISE. Navigate to Operations and look at the Live Logs. Here, you should see successful authentication and authorization events for both users.
I logged in as both bob and brad, and you can clearly see that each user matched the correct authentication and authorization policies, along with the expected authorization profile.



When logging in as bob, who is mapped to the super_admin profile, I can create new objects in the GUI. From the CLI, I also have access to configuration mode, which confirms that the correct admin profile was applied.

fortivm-01 #
config Configure object.
get Get dynamic and system information.
show Show configuration.
diagnose Diagnose facility.
execute Execute static commands.
alias Execute alias commands.
exit Exit the CLI.
fortivm-01 #When logging in as brad, who is mapped to the read_only profile, the access is restricted. In the GUI, the option to create new objects is not available. From the CLI, configuration mode is also not accessible.

fortivm-01 $
get Get dynamic and system information.
show Show configuration.
diagnose Diagnose facility.
execute Execute static commands.
alias Execute alias commands.
exit Exit the CLI.
fortivm-01 $This confirms that the admin profile sent by the Radius server is being applied correctly and that access is enforced based on the user and their assigned profile.




