AAA and identity - RADIUS, TACACS+, 802.1X
Requirement / business driver
Authenticate and authorise both who administers the devices and what/who connects to the network, with an audit trail.
TACACS+ vs RADIUS
| TACACS+ | RADIUS | |
|---|---|---|
| Primary use | Device administration (CLI) | Network access (802.1X/MAB, VPN) |
| Transport | TCP 49 | UDP 1812/1813 |
| Encryption | Entire payload | Password only |
| Granularity | Per-command authorization | Authorize at access (coarse) |
| Origin | Cisco | IETF standard |
Network access auth
802.1X (supplicant + authenticator + RADIUS server) for managed devices, MAB for non-802.1X endpoints (printers/IoT), with fallbacks. Identity sources internal or external (AD/LDAP), certificate-based auth (EAP-TLS), EAP chaining (machine and user auth together - today standardised as TEAP, whose per-factor outcome is policy input: machine-passed-but-user-failed can map to a limited login/remediation segment rather than all-or-nothing), and MFA integration for stronger assurance (EAP itself cannot carry a second factor, so MFA rides a portal step - CWA then SAML/OIDC to the IdP - or is anchored at certificate enrolment). A third-party RADIUS server can stay the authenticator in a group-based fabric - proxied behind the policy engine, or answering directly with the SGT carried as a RADIUS AV-pair (plus the VLAN) - but SGACL policy download remains the policy engine's job: the incumbent AAA substitutes for authentication, never for the policy plane (Network access control and segmentation - NAC, TrustSec, guest and BYOD). Wireless enterprise auth is the same 802.1X model (WPA2/WPA3-Enterprise); WPA3-Personal (SAE) and OWE are covered with RF in 7.0.
Two identity-path pitfalls - fragmentation and split authC/authZ
EAP-TLS breaks in a way PEAP does not when certificates meet path MTU: the certificate exchange inflates single EAP messages toward ~1.5 kB, RADIUS encapsulation adds roughly 300 bytes, and the resulting datagram exceeds a 1500-byte MTU -> IP fragments of RADIUS/UDP, which firewalls and NAT devices frequently drop (non-initial fragments carry no L4 header to match). Symptom: certificate-based auth times out across exactly the paths PSK/PEAP survive. The fixes are design placements, not knobs: put a RADIUS/policy node on the authenticator's side of the fragment-hostile boundary, provide a jumbo/clean-MTU path to the AAA cluster, or explicitly engineer fragment handling on the security devices in between - and treat AAA reachability as a path-MTU-sensitive service when placing policy nodes (MTU, fragmentation, and PMTUD).
Cloud identity splits authentication from authorisation. The scalable pattern keeps authC local and cryptographic - EAP-TLS against the on-prem RADIUS - while authZ attributes come from the cloud IdP/MDM (group membership, compliance state) fetched out-of-band and matched on the certificate identity. The design win: 802.1X keeps working when the cloud IdP is unreachable (cached/last-known attributes degrade gracefully), and MFA - which EAP cannot transport - is enforced where it fits: at enrolment (issuing the certificate) or at a portal step for sensitive segments.
Scaling the policy plane - personas and placement
The policy infrastructure itself is a design object with three personas: administration (the configuration brain), monitoring (the centralised log/correlation store - without it every policy node reports for itself), and policy service - the RADIUS workhorse that terminates every authentication, portal, and profiling exchange. The design rules follow from the split. Separate the personas as scale grows (standalone -> admin+monitoring pair with a handful of policy nodes -> fully dedicated roles), because a dedicated policy node keeps authenticating even when administration/monitoring are down - the survivable part is the part in the authentication path. Place policy nodes near the NADs they serve: round-trip time is in every login, and the fragment-hostile-boundary rule above is solved by locality, not tuning. The budget has numbers: keep NAD-to-policy-node RTT around 100 ms - the exchange is RADIUS, and TrustSec policy download rides the same channel - while personas in a distributed deployment tolerate roughly 300 ms between one another (SD-Access publishes the same figures for its identity tier, Overlays and BGP EVPN). Dedicate nodes to heavy sidecar roles (context sharing, threat feeds) so RADIUS latency never competes with integrations. And make the farm reachable as one address - load balancer or anycast - with node-grouped peers recovering each other's sessions, so NAD-side configuration stays simple while the farm scales behind it.
Deployment fine print - node-group HA and NEAT
Two details sharpen the policy-plane design. First, PSN high availability needs less machinery than it appears to: every node already holds a full copy of the database, and the NAD's own dead-server detection walks its RADIUS server list - that is the baseline failover, with no clustering required. A node group adds only one thing on top: L2-adjacent PSNs heartbeating each other, where a surviving peer fires a CoA when a member dies mid-authentication so the stuck session restarts cleanly against a live node - which is why node groups matter chiefly behind a load balancer (where the NAD cannot see individual server death) and are over-engineering elsewhere. Second, the authenticated edge can extend past the wiring closet without pre-provisioned open trunks: NEAT makes a small "desktop-side" switch an 802.1X supplicant to the access switch - CISP signalling tells the authenticator it is talking to a switch rather than an endpoint, and on successful authentication the port flips from access to trunk. Conference rooms and temporary spaces get switched capacity whose uplink is earned by authentication, not left as a standing open trunk.
Recommendation / justification
Use TACACS+ for device admin (command authorization + full-payload encryption + accounting) and RADIUS for network access (802.1X/MAB). Prefer certificate-based EAP-TLS with EAP chaining for posture, and integrate MFA for admin/VPN. Justify by the distinct needs: granular admin control vs scalable access control.
What would change this (mid-scenario twist)
- Strong device-admin audit/granularity required -> TACACS+ with per-command authz.
- Mixed managed/unmanaged endpoints -> 802.1X with MAB fallback + profiling.
Validation checks
- Is device admin on TACACS+ (granular authz/accounting) and access on RADIUS/802.1X?
- Are there fallbacks so an AAA outage doesn't lock everyone out?
IPv6 / dual-stack note
AAA transactions and 802.1X operate independent of the data-plane family; ensure the RADIUS/TACACS+ servers are reachable over your management family.
Related
- Network access control and segmentation - NAC, TrustSec, guest and BYOD
- Infrastructure segmentation
- Zero Trust and ZTNA
Spaced repetition
TACACS+ vs RADIUS by purpose: TACACS+ = [...]; RADIUS = [...].
TACACS+ vs RADIUS by purpose: TACACS+ = device administration (TCP, full-payload encryption, per-command authz); RADIUS = network access (UDP, 802.1X/MAB/VPN).
MAB exists because [...].
MAB exists because some endpoints (printers/IoT) can't do 802.1X - they're authorised by MAC as a fallback.
EAP chaining authenticates [...] (stronger posture than either alone).
EAP chaining authenticates both the machine and the user together (stronger posture than either alone).
Why does EAP-TLS fail across some firewalled paths where PEAP works, and what is the design fix?
Certificate exchanges push RADIUS/UDP datagrams past 1500 B -> IP fragmentation, and security devices drop non-initial fragments; fix by placement - a policy/RADIUS node local to the authenticator side (or a clean jumbo-MTU path), not by tweaking EAP.
In the cloud-identity pattern the split is: [...].
In the cloud-identity pattern the split is: authenticate locally with EAP-TLS certificates; source authorisation attributes (groups, compliance) from the cloud IdP/MDM out-of-band.
Why split the policy-infrastructure personas, and where do the policy nodes belong?
A dedicated policy-service node keeps authenticating when administration/monitoring fail - the survivable part is the one in the auth path; place policy nodes near their NADs (RTT + fragmentation locality), dedicate nodes to heavy integrations, and front the farm with a load balancer/anycast address.
When do ISE node groups actually earn their place?
Baseline PSN failover is the NAD's own dead-server list (every node holds the full DB); a node group only adds L2-adjacent heartbeating peers that fire a CoA to restart a mid-auth session when a member dies - chiefly valuable behind a load balancer.
NEAT lets a small edge switch act as an [...] to the access switch (CISP signals switch-not-endpoint), and success flips the port [...] - authenticated switched capacity beyond the closet.
NEAT lets a small edge switch act as an 802.1X supplicant to the access switch (CISP signals switch-not-endpoint), and success flips the port from access to trunk - authenticated switched capacity beyond the closet.
Sources
- Cisco Live BRKENT-2076 (APJC 2022): the ~100 ms NAD-to-policy-node and ~300 ms inter-persona RTT anchors; third-party RADIUS as authenticator with the SGT delivered as an AV-pair.
- Cisco Press, Cisco ISE for BYOD and Secure Unified Access (Woland/Heary; 1st-edition artifact) - node-group HA mechanics, NEAT.
- Cisco Press, CCNP Security SISE 300-715 OCG - personas, distributed deployment, PSN placement and farm fronting.
- Cisco Live BRKEWN-2104 (Krischer, 2024): EAP-TLS/RADIUS fragmentation, TEAP outcomes, cloud-identity split.
- Cisco Press, SCOR; Cisco ISE design guides.