Fortinet FortiGate

This page covers administrative access to a FortiGate over TACACS+. It is the device-side counterpart to TACACS+.

FortiGate is the odd one out in this cookbook, and it is worth saying why before any configuration appears.

RADIUS administrative login is also supported by Taranac (via the Fortinet-Group-Name VSA) but was not part of this test and is not documented here.

FortiGate needs three objects to cooperate, and each one can be individually correct while the chain as a whole fails. Read this before the configuration, because the error messages will not tell you which link broke.

The login flow runs: authenticate against Taranac → request authorization from Taranac → match the returned group against a local group → apply the returned admin profile.

config user tacacs+
    edit "TARANAC"
        set server "10.0.0.20"
        set key ENC <TACACS_SECRET>
        set authorization enable
        set source-ip "10.0.0.11"
    next
end

set source-ip pins the address the FortiGate uses to reach the server, which is what Taranac matches against the registered device. If it disagrees with the address on the device’s entry, the request is dropped as coming from an unknown client and nothing is written to the Taranac logs. See Network devices.

config user group
    edit "TACACS-ADMINS"
        set member "TARANAC"
        config match
            edit 1
                set server-name "TARANAC"
                set group-name "FGT_access"
            next
        end
    next
end

The match block is the join between the two systems. group-name must equal the value Taranac returns in the memberof attribute of the FortiGate authorization profile — here, FGT_access. They are two independently-edited strings in two different products that must agree exactly, which makes this the most common place for a working setup to break after someone renames something.

set member "TARANAC" makes the TACACS+ server a member of the group.

config system admin
    edit "tacacs-wildcard"
        set vdom "root"
        set remote-auth enable
        set accprofile "super_admin"
        set remote-group "TACACS-ADMINS"
        set wildcard enable
        set accprofile-override enable
    next
end

wildcard enable is what makes this scale: one admin entry serves every user in the group, instead of a local entry per person. remote-group points at the group from step 2.

config system global
    set remoteauthtimeout 30
end

This is the FortiGate’s timer for remote authentication, and it is the one to raise for push MFA. Taranac holds the exchange open while the user approves the push on their phone — up to about 30 seconds. FortiOS defaults to a much shorter value, at which the firewall gives up before anyone can reach into a pocket and the login simply fails.

The effective window is the smaller of this value and Taranac’s own server-side cap, so raise both together.

config system accprofile
    edit "prof_admin"
        set secfabgrp read-write
        ...
        set cli-config enable
    next
end

show system accprofile does not necessarily list every profile that exists — super_admin was in active use on the tested firewall and does not appear in this output. Do not conclude from a missing entry that a profile is undefined; the name Taranac returns only has to be valid on the firewall, not visible here.

FortiGate’s fnbamd daemon handles remote authentication, and its debug output is by far the most informative diagnostic on this platform — it shows exactly what Taranac returned and how the firewall interpreted it.

diagnose debug enable
diagnose debug application fnbamd -1

It self-disables after 30 minutes. Now log in from another session. A successful login produces this (elided to the lines that matter):

[1784] handle_req-Rcvd auth req … for taranac in  opt=00014001 prot=9 svc=6
[336] __compose_group_list_from_req-Group 'TACACS-ADMINS', type 1
[414] __add_admin_tac_plus_svr-Loaded TAC+ server 'TARANAC' for admin user 'tacacs-wildcard'
[94]  fnbamd_tac_plus_get_next_authen_type-Next authen type pap
[389] __tac_plus_tcps_open-… addr 10.0.0.20, src_ip 10.0.0.11 …
[300] fnbamd_tac_plus_make_authen_request-Building authen start packet: authen_type=2(pap)
[509] fnbamd_tac_plus_validate_authen_reply-TAC+ authen type=2, result=1(pass)
[117] __tac_plus_next_state-State: 'Authen' -> 'Author'
[435] fnbamd_tac_plus_make_author_request-Building author req packet: authen_type=2(pap)
[595] __parse_author_reply_args-arg cnt 3
[363] __add_group-Authorization group 'FGT_access'
[375] __set_admin_prof-Authorization admin profile 'super_admin'
[206] find_matched_usr_grps-Passed group matching
[280] fnbamd_comm_send_result-Sending result 0 …

Read it as a checklist — each line confirms one link in the chain:

diagnose test authserver tacacs+ TARANAC ad_user1 <password>

The first argument is the server name as configured, not its address. Passing an IP returns '10.0.0.20' is not a valid tac_plus server name, which reads like a configuration fault and is not one.

On success the command ends with the assigned profile. On failure:

authenticate user 'ad_user1' on server 'TARANAC' failed
Admin profile: <none>

This is the platform behaviour most likely to surprise you, and it is only visible in the debug output:

Building authen start packet: authen_type=2(pap)
  → TAC+ authen type=2, result=2(fail)
Next authen type mschap
Building authen start packet: authen_type=5(mschap)
  → TAC+ authen type=5, result=2(fail)
Next authen type chap
Building authen start packet: authen_type=3(chap)
  → TAC+ authen type=3, result=2(fail)
Next authen type ??

When PAP is rejected, FortiGate does not give up — it retries the same credentials as MS-CHAP, then as CHAP, each on its own fresh TCP connection, before declaring failure.

A successful login never starts the cascade — PAP passes on the first exchange and the chain stops there. So the cascade in your logs is always a failure signature, which makes it useful: three rejections with ascending authentication types is a wrong password, not a broken server.

• Device configuration — conventions and the rest of the cookbook
• Cisco IOS / IOS-XE — a platform with per-command authorization
• Network devices — registering the device and its secret
• TACACS+ — profiles and templates
• AAA policy — the rules that decide which profile a login gets