Next, we create RADIUS clients for each Fortinet device that needs to authenticate against this NPS using their IPs and setting shared secret.

Fortigate (10.100.104.13):

FAZ (10.100.104.17):

FMG (10.100.104.252):

FGT

After that just click on Next, as Group membership for users on AD we will specify in Network Policy in the next step, not in the Connection Request Policy.

We create the same Connection Request Policies for FMG and FAZ, and they differ only by RADIUS Client IP.

In this AD topology, I created 4 AD users adminad1,…​admiad4, then created a new AD Group named AllFGTAdmins and added all 4 users to it. We will next match RADIUS Network Policy on this AD Group, i.e. only members of this AD group will be able to authenticate according to NPS Network Policy. This way we prevent the mistake of allowing ANY valid AD user to authenticate against our Fortinet devices. In later examples of assigning Access Profiles from RADIUS, I will add new Groups and make them more granular.

Here I set as condition in the Network Policy matching on the AD group membership and select just AllFGTAdmins group:

Running dia deb app fnbamd -1, dia deb en will show the following error:

And if we do packet capture on the Fortigate, we will see that Fortigate does include this Message Authenticator RADIUS attribute, but the response from NPS does not, and as a result – Fortigate drops successfully authenticated user connection.

To fix this, enable the following option in NPS Console:

To allow the Access Profile to be overriden, we enable this option on admin user (option exists for regular admin users as well as Wildcard users). Also, as a best practice, we create an empty access profile and assign it to this Wildcard user instead of the “super_admin” I assigned above:

User Group containing the RADIUS object:

Now let’s set VSA 6 on NPS to the accprofile name of super_admin:

And trying successfully to log in with user adminad4 I get the correct super_admin profile from the RADIUS server sent VSA Attribute 6:

Before doing any debug we have to understand what messages RADIUS exchanges, what they mean and such as debug lists numeric codes only.

Most popular RADIUS request/response messages/codes as per RFC:

Debug output of successful login with user adminad1 with Wildcard admin user:

Next FGT is counting all other remote servers configured (none in this case) until reaches RAD1 RADIUS server
10.100.104.184 using MS-CHAP2 (configured, not default) and authenticates against it:

Composes Access-Request (code 1) message to the RADIUS server, using default
(not set to custom) source IP, UDP , to the default port 1812:

Adds attribute Message Autenticator:

RADIUS server response is success: code 2 (ACCESS-ACCEPT):

Next is the FNBAMD daemon final result (see table below for values, 0 = success)

FNBAMD authentication daemon response codes in the debug:

Here I am using the user adminad5 which exists in AD, and password is correct BUT he is not part of the FGTAllAdmins
AD group on the RADIUS server. And therefore, will not match the Network Policy of the RADIUS NPS on Server 2019 and thus NPS will reject it.

Intial process is the same as the above example of successful authentication, up to getting aresponse from the RADIUS:

What differs is the RADIUS server response – here it is 3 (ACCESS-REJECT), also FNBAMD daemon final result is
1 (DENY):

The config in FMG is pretty much identical to the FAZ, so I will only show this example.

Or in GUI System Settings → Remote Authentication:

And the same drill – create NPS Policy on RADIUS server to send FMG at least VSA Attribute 6 – name of the access profile, and possibly VSA Attribute 3 – ADOM name.

Additional logs on authentication failure can be found in System Settings → Event Logs, but they are not very detailed.

Here is example of successful and failed logins:

NPS configs. Here I create 2 Network Policies – FGT-readonly and FGT-superadmin. The 1st will assign any user in the AD Group FGTreadonly the accprofile (via VSA Attribute) “readonly” located on the Fortigate already. Users in the AD group FGTsuperadmin, after authentication will get profile “super_admin”. To the FGTreadonly group I added only adminad5 user, and to the FGTsuperadmin AD Group adminad4, adminad3 etc.

For this and the next example I will only show Fortianalyzer configs as in both cases the configuration is the same for both FAZ & FMG.

The NPS side is the same as for FGT – create 2 new Network Policies with Conditions of RADIUS Client IP (FAZ) and user group membership, sending for each policy different accprofile name via VSA Attribute 6 – “readonly” and “Super_User” (there is no “super_admin” profile in FAZ unless you create a custom one with that name).

Fortinet have additional helpful VSA Attribute – 3 Fortinet-Vdom-Name which when sent from RADIUS can be used by Fortigate/FAZ/FMG/etc to override the default VDOM/ADOM the user can access.

NPS: For this I created a new AD Group “FAZ-syslogadom” that contains only adminad8 user. I create then new Network Policy to match FAZ IP and this AD Group. And finally, I set not only VSA Attribute 6 – accprofile, but also VSA Attribute 3 – ADOM name to “Syslog” to be sent by RADIUS server.

Here is the accprofile I created:

And on CLI:

Case 1: Debug of successful authentication with the user adminad7 getting “readonly” profile with access to all ADOMs:

FAZ also has the option of matching on Group Name sent from RADIUS. It is useful when using wildcard users and authenticating against the same NPS server – we cannot in such case allow any Domain Users as matching condition in NPS Policy, as this would allow any AD users that do not exist on FAZ but do exist in AD to authenticate.

Task: create RADIUS-authenticated user adminad9 on FAZ, when it connects assign it profile ADOMSuper_User and limit his access to the FGT-only ADOM.

So for this, I create user adminad9 on both FAZ and AD. I create a new AD Group FGT-only-adom which will have as a member just user adminad9. And then create NPS Policy matching user on AD Group FGT-only-adom and sending with the response also Fortinet VSA Attribute 1 Group-Name to be additional match on the FAZ side.

Using the same RADIUS server:

The user with the matching condition of string “FGT-only”:

After log in, the user cannot change ADOM, and has Autumn as the theme: