RADIUS, TACACS+, and Network Access Authentication

Why it matters

RADIUS and TACACS+ support different AAA use cases, including VPN, Wi-Fi, 802.1X network access, and network-device administration. Design choices include external identity sources, certificates, EAP methods at a high level, MFA chaining, authorization profiles, command authorization, proxying, failover, timeouts, retries, accounting, source IP validation, and protected shared secrets.

Design checklist

Define whether the service is user network access, VPN, or administrative device access.
Record identity source, certificate or factor requirements, authorization profile, logging, and HA behavior.
Protect shared secrets and avoid insecure defaults or plaintext directory handling without a clear protection boundary.
Test failover and distinguish device reachability, client identity, policy decision, and accounting failure.

Failure-isolation workflow

Follow a request from client or device to authenticator, AAA service, identity source, policy response, and accounting record. Compare time, source address, certificate state, selected policy, timeout, and retry behavior. Do not infer device trust from directory authentication alone.

Common mistakes

Do not place real secrets in tickets or examples, assume RADIUS encrypts every attribute end to end, or use PAP or weak EAP without explaining the risk and compensating boundary.

Fictional example

Wi-Fi authentication fails only at one site. The evidence shows the access point can reach the AAA service, but its source address is not included in the authorized client list. The repair is a reviewed client definition, not a broad anonymous fallback.

Operational decision points

Start by identifying RADIUS Access-Request, Access-Accept, Access-Reject, Access-Challenge, TACACS+ administration, source validation, certificates, timeout, retry, and accounting. Keep those elements separate in the change record: a successful technical step can still leave an inappropriate authorization, unavailable dependency, or incomplete audit trail. Scope decisions to a named owner, system, time window, and evidence source.

Practical workflow

trace client or device, network access server, AAA service, identity store, policy response, and accounting record in time order. At each stage, decide whether the observed result is sufficient to continue, needs an owner question, or requires a bounded rollback or escalation. Avoid turning an unavailable log or delayed response into proof that no activity occurred.

Evidence and review checklist

collect source address, network access server, request identifier, selected EAP or policy result, identity-store outcome, timeout or retry count, clock state, and accounting reference.
Confirm the accountable owner, expected dependency, approved exception, and next review date.
Test an ordinary permitted path and a relevant denial or expiry condition using approved accounts and non-sensitive data.
Separate service availability symptoms from identity, policy, session, and logging outcomes.

Fictional operational example

A VPN user receives a reject after an MFA proxy is introduced. The access server reaches RADIUS, but the identity store response is delayed beyond the configured timeout. The team adjusts an approved resilience setting after validating the full request path.

Validation boundaries and failure modes

RADIUS commonly carries network-access authentication and accounting; TACACS+ is often used for device administration and command authorization. Selection depends on the platform and policy, not a universal ranking. Preserve client source information through load balancers or NAT, and validate dead-server and failover behavior with synchronized clocks.

Before closing a review, confirm the result with the system owner and retain a reference to the relevant configuration, event, approval, or test. Missing evidence should create a follow-up question, not an unsupported conclusion about safety, authorization, or exposure.

Focused review checklist

High availability requires more than two servers. Verify source preservation through load balancers or NAT, shared policy and certificate state, dead-server detection, timeout and retry behavior, accounting continuity, and clock synchronization. Packet and log evidence should be captured at the client, network access server, AAA service, and identity source where permitted.