RADIUS vs TACACS+ on FortiGate SD-WAN: Choosing the Right AAA Backend (Part 1 of 2)
Part 1 of a two-part series on running admin AAA against a FortiGate SD-WAN edge. This post stays at the protocol and design layer — what RADIUS and TACACS+ actually are, the server options worth considering, and when each is the right answer specifically for FortiOS. Part 2 covers the FortiGate-side configuration with three worked RBAC examples.
This builds on NSE4 Part 4, which introduced RADIUS as one of four authentication backends. Here we go several layers deeper, because once you’re running an SD-WAN fleet — even a small one — admin AAA is no longer optional.
Why this question keeps coming up
A FortiGate SD-WAN edge sits at the boundary between three audiences who all need to log in:
- Network engineers doing routing, SD-WAN, IPsec, and security-profile work.
- NOC / operations running diagnostics, restarting tunnels, opening or closing policies temporarily.
- Auditors and compliance reviewing config, logs, and policy state.
Local accounts don’t scale across a fleet. As soon as you have more than two or three boxes, you need a centralised identity backend with revocation, MFA, and an audit trail. The two protocols that are fit for that purpose are RADIUS and TACACS+, and the choice between them is more nuanced than the usual “RADIUS for users, TACACS+ for admins” shorthand suggests — particularly on FortiOS.
The protocols, briefly
RADIUS (RFC 2865 / 2866)
| Property | Detail |
|---|---|
| Transport | UDP/1812 (auth), UDP/1813 (accounting) |
| Encryption | Only the User-Password attribute is hidden (MD5-XOR with shared secret). Everything else — usernames, attributes, replies — is in the clear. |
| Combined operations | Authentication and authorization are returned together in Access-Accept |
| Accounting | Separate Accounting-Request / Accounting-Response exchange, optional |
| Extensibility | Vendor-Specific Attributes (VSAs) — vendor ID + sub-attributes |
| Stateful? | No — fire and forget plus retransmit. UDP. |
The fact that RADIUS authorisation rides inside the Access-Accept is the defining property: there’s no way for the network device to ask “can this user run command X?” mid-session. You decide once, at login, and the session inherits whatever attributes came back.
TACACS+ (Cisco-defined, now RFC 8907)
| Property | Detail |
|---|---|
| Transport | TCP/49 |
| Encryption | Entire payload obfuscated with shared-secret-derived MD5 stream (still not strong crypto, but covers everything — usernames, attributes, command lists) |
| Separated AAA | Authentication, Authorization, and Accounting are independent transactions |
| Per-command authorization | Yes — the device asks the TACACS+ server about each command before allowing it |
| Stateful? | Yes — TCP session per AAA exchange |
The headline difference is per-command authorization — TACACS+ was designed for device admin AAA, RADIUS was designed for dial-up network access AAA. Their assumptions about granularity differ.
Side-by-side, focused on FortiOS
| Dimension | RADIUS | TACACS+ |
|---|---|---|
| Transport | UDP, lossy, retransmit | TCP, reliable |
| Payload protection | Password only | Whole packet |
| Per-command authz | No (FortiOS doesn’t ask, and protocol doesn’t fit) | Supported in protocol — but FortiOS only uses TACACS+ for authentication and accounting, not per-command authorization |
| MFA / Duo / RSA | Native — challenge-response in Access-Challenge | Supported via Duo TACACS+ proxy, but less common |
| 802.1X, SSL VPN, IPsec XAuth | RADIUS is the standard | TACACS+ does not fit these flows |
| Multi-vendor support | Universal | Strong on Cisco, weaker elsewhere |
| Cloud identity providers | Most expose RADIUS endpoints (Okta, Duo, JumpCloud, Entra ID via NPS extension) | Effectively none expose TACACS+ as-a-service |
The crucial line is the third: FortiOS does not implement per-command TACACS+ authorization the way Cisco IOS does. It uses TACACS+ to authenticate the admin and (optionally) log the session, but the access profile that decides what commands the admin can run is local to FortiOS. That removes TACACS+‘s biggest historical advantage on a FortiGate.
RADIUS server options worth knowing
The “which RADIUS server?” question is rarely answered from scratch — most shops have something already. Here’s what each option actually gets you on a FortiGate:
Microsoft Network Policy Server (NPS)
The default answer for any AD-joined org. Free with Windows Server. Network policies map AD security groups to RADIUS responses. Combined with the Azure MFA NPS extension you also get Microsoft Authenticator push for VPN and admin login. Pain points: Windows-server-only (so HA means Windows clustering or two boxes with FortiGate fail-over between them); the policy editor is dated; it’s RADIUS-only — no TACACS+.
FortiAuthenticator (FAC)
Fortinet’s identity appliance. Native FortiToken issuance, deep VSA support, FSSO collector duties, certificate authority, SCEP, and a clean web UI. If you’re already running FortiManager + FortiAnalyzer, FAC slots in as the third leg. The strongest option specifically for FortiGate fleets because the VSAs and group-mapping flows are tested end-to-end against FortiOS. Costs licensing; can run as a VM.
FreeRADIUS
The OG. Runs anywhere. Speaks every dialect of RADIUS. Backed by a flat file, SQL, LDAP, or whatever you wire up. Maximum flexibility, maximum operational responsibility — you own the upgrades, the HA pair, the rate-limiting, and the EAP cert chain. Worth using when you want a small, auditable, vendor-neutral RADIUS layer in front of an existing identity store, or when you’re integrating with weird upstream systems.
Cisco ISE
NAC-grade. Designed for 802.1X with posture, profiling, and policy sets that span thousands of switches. Can absolutely do FortiGate admin AAA, and many enterprises do — but it’s overkill if device admin is your only use case. Pairs naturally with TACACS+ for Cisco device admin and RADIUS for everything else, including FortiGates.
Aruba ClearPass
Same shape as ISE — full NAC platform — preferred in HPE/Aruba shops. Same caveat: overkill for FortiGate admin AAA alone, ideal if it’s already deployed for wired/wireless 802.1X.
Okta RADIUS Agent
Bridges Okta as the identity source to RADIUS-speaking devices. Push MFA, group mapping, and SSO log unification all roll up into Okta. Fine choice for cloud-first orgs that don’t want to run NPS or FreeRADIUS. The agent itself is a small Windows or Linux service — be aware it’s a single-host shim unless you build redundancy yourself.
Duo Authentication Proxy
Not a directory — a proxy. Sits between the FortiGate and an upstream auth source (AD via LDAP, an existing RADIUS server, etc.) and adds MFA. The FortiGate talks RADIUS to Duo Proxy; Duo Proxy talks LDAP/RADIUS to the directory and Push/Phone/HOTP to the user. Lightweight, well-documented, and the pragmatic answer when “I need MFA on FortiGate VPN by next week” is the requirement.
Microsoft Entra ID (Azure AD) via NPS extension
The cloud-identity option for Microsoft shops. NPS still runs locally and is what the FortiGate talks to; the NPS extension passes the auth out to Entra for password validation and MFA. Works, widely deployed, and the recommended Microsoft path. The drawback is that it’s still NPS — same operational profile — with an extra cloud dependency in the auth path.
JumpCloud / Foxpass / Cloud RADIUS
A class of cloud-hosted RADIUS-as-a-service offerings, useful for orgs without on-prem infrastructure or AD. The FortiGate sends RADIUS over the public internet (with secret + ideally IPsec or a private link) to the provider. Good for small-mid orgs without a Windows estate; review the BAA / data-residency story before adopting.
Decision shortcut
| If you have… | Start with… |
|---|---|
| AD on-prem, Microsoft-leaning | NPS (+ Azure MFA NPS extension if MFA matters) |
| FortiManager / FortiAnalyzer already | FortiAuthenticator |
| ISE or ClearPass already | Reuse it; one less moving part |
| Okta as your IdP | Okta RADIUS Agent |
| AD on-prem and need MFA fast | Duo Authentication Proxy in front of NPS or LDAP |
| No AD at all, cloud-first | JumpCloud / Foxpass / Okta |
| Hard constraint on vendor neutrality and deep customisation | FreeRADIUS |
When RADIUS beats TACACS+ on FortiGate
Some of these are obvious; some catch people out.
1. Anything that authenticates an end user, not an admin. SSL VPN, IPsec dial-up VPN, captive portal, 802.1X for wired and wireless — all of these are RADIUS-only on FortiOS. TACACS+ doesn’t even appear on the menu.
2. MFA integrations. Duo, Okta Verify, Microsoft Authenticator (via Azure MFA NPS extension), RSA SecurID, Yubico OTP via FreeRADIUS — every mainstream MFA provider integrates via RADIUS challenge-response. TACACS+ MFA exists but is rarer and less ergonomic.
3. Cloud-hosted identity. Okta, JumpCloud, Foxpass, Entra ID — none expose TACACS+ as a SaaS offering. If your IdP lives in the cloud, your AAA protocol to the FortiGate is going to be RADIUS.
4. Reusing existing infrastructure. If you’ve stood up RADIUS for your wireless network, your VPN, or your 802.1X switching, FortiGate admin auth piggybacks on it for free. Adding a separate TACACS+ deployment for two FortiGates is rarely worth it.
5. Multi-vendor estates. RADIUS is the lowest common denominator across Fortinet, Palo Alto, Juniper, Aruba, F5, and most cloud appliances. If you want one identity backend for everything, RADIUS is the cleaner choice.
6. The TACACS+ command-authorization argument doesn’t apply on FortiOS. This is the one most people miss. On Cisco IOS, TACACS+ buys you the ability to authorize each configure terminal and write memory command at the server. On FortiOS, command-by-command authorization is not delegated to TACACS+ — the local admin profile governs what an admin can do. So the TACACS+ feature you’d be paying for on a Cisco box doesn’t materialize on a FortiGate.
When TACACS+ is still the right answer
It’s not all one-sided. TACACS+ wins in specific situations:
1. You already run TACACS+ everywhere for Cisco device admin and your auditors expect a single AAA story across the network. Adding FortiGate to the same TACACS+ servers (using FortiOS’s authentication-only TACACS+ implementation) keeps the audit trail coherent, even if FortiGate doesn’t use the per-command authz feature.
2. Compliance frameworks that explicitly require encrypted-payload AAA for device admin. Some PCI / HIPAA / FedRAMP interpretations prefer TACACS+ specifically because the username and authorization data are encrypted on the wire, not just the password. RADIUS over IPsec or RadSec (TLS) addresses the same risk, but if your auditors prefer TACACS+ as a control statement, it’s the easier conversation.
3. Strong separation between user AAA and admin AAA. Some orgs deliberately run admin AAA on a different protocol and a different infrastructure to reduce the blast radius of a compromise of the user-AAA system. TACACS+ on a separate ISE instance for admin-only is a clean pattern for this.
4. You need command accounting on FortiOS. Even though FortiOS doesn’t do per-command authorization via TACACS+, it does support TACACS+ accounting for admin sessions, and some orgs find that audit trail valuable. It’s also achievable via FortiAnalyzer and event log, but TACACS+ accounting is sometimes the path of least resistance for a SOC team that already pipes TACACS+ accounting into a SIEM.
RadSec — a quick word
If you’re deploying RADIUS over an untrusted network (for example, branch FortiGates phoning home to a hub-side RADIUS server over an SD-WAN overlay that crosses the public internet), look at RadSec — RADIUS over TLS over TCP, RFC 6614. FortiOS supports it (config user radius → set server-identity-check enable and TLS profile). RadSec gives you the channel encryption that classic RADIUS lacks, while keeping the RADIUS attribute model your servers and policies already speak. Worth doing if your RADIUS path is anything other than a trusted local LAN.
Recommendation for an SD-WAN edge
For most FortiGate SD-WAN deployments — small to mid-size, AD-backed, MFA required, mixed admin and VPN auth — the best-fit pattern is:
- RADIUS as the single AAA protocol from FortiGate.
- NPS or FortiAuthenticator as the RADIUS server, depending on whether you’re a Microsoft or Fortinet-centric shop.
- MFA via Azure MFA NPS extension or FortiToken Cloud at the RADIUS layer.
- Local fallback admin account with a vault-managed password for break-glass.
- RadSec if RADIUS traverses anything you don’t fully control.
This covers admin AAA, SSL VPN, IPsec, and 802.1X-managed branch wireless on a single protocol and a single identity backend, with no TACACS+ infrastructure to maintain. For an AD-joined Cisco-heavy enterprise that already runs TACACS+ for IOS admin, layering FortiGate in via TACACS+ for admin only is also defensible — but you’ll still need RADIUS for the VPN side, so you end up running both.
Part 2 walks through the actual FortiOS configuration for this design — the RADIUS server entry, the VSA-based group-to-profile mapping, the three RBAC profiles for senior engineer / NOC operator / compliance auditor, and the verification commands you’ll wish you had during the first failed login.