Study guide
10.4 Administrative Access Control: RADIUS vs TACACS+
HPE Aruba Networking Certified Associate - Campus Access HPE6-A85
Track your progress as you read
Finished sections get a check mark.
1 Introduction: HPE6-A85 Exam Overview
HPE6-A85 Exam Facts and Current Blueprint
2 Chapter 1: Network Stack Fundamentals
1.1 OSI Reference Model and Encapsulation 1.2 TCP/IP Protocol Suite and IP Headers 1.3 Layer 2 Operation, ARP, and 802.1Q Tagging
3 Chapter 2: Physical Connectivity and Host Addressing
2.1 Ethernet Media and Transceiver Standards 2.2 Power over Ethernet (PoE, PoE+, PoE++) Standards and Budgeting 2.3 LLDP, LLDP-MED, and Voice VLAN Configuration 2.4 Host IP Addressing and DHCP Relay Operations
4 Chapter 3: Network Resiliency and Virtualization
3.1 Virtual Switching Framework (VSF) Architecture and Topologies 3.2 VSF Split Detection, Failover, and Auto-Stacking 3.3 Virtual Switching Extension (VSX) Architecture and Operations 3.4 High-Availability Gateways: VRRP and VSX Active-Gateway
5 Chapter 4: AOS-CX Architecture and Switch Operation
4.1 AOS-CX Hardware Portfolio and State Database Architecture 4.2 Network Analytics Engine (NAE) and Automated Telemetry 4.3 AOS-CX Interface Configuration and Port Control 4.4 Link Aggregation (LAG) and LACP Configuration
6 Chapter 5: Layer 2 Protocols and Spanning Tree
5.1 AOS-CX VLAN Configuration and Native VLAN Handling 5.2 Spanning Tree Protocols: STP, RSTP, and MSTP 5.3 Spanning Tree Protections and Loop Prevention 5.4 MAC Address Table Learning, Aging, and Forwarding
7 Chapter 6: Wireless Fundamentals, Standards, and RF
6.1 IEEE 802.11 Standards and Wi-Fi Generations 6.2 RF Fundamentals, Signal Propagation, and Channel Design 6.3 Aruba Access Point Hardware Portfolio and Suffix Conventions 6.4 WLAN Topologies, BSSID/ESSID, and Roaming Standards
8 Chapter 7: Aruba Wireless Architecture and Management
7.1 AOS 10 Architecture and Aruba Central Integration 7.2 Wireless Forwarding Modes: Bridge vs Tunnel Mode 7.3 Automated RF and Client Optimization: AirMatch and ClientMatch 7.4 Secure Wireless Access: WPA3, SAE, and MPSK Implementation
9 Chapter 8: IP Routing Fundamentals and OSPF
8.1 IP Routing Principles and Packet Forwarding 8.2 OSPFv2 Protocol Mechanics and Adjacency Formation 8.3 OSPF Designated Routers and Multi-Area Deployments 8.4 ECMP, Static Routing, and VRF Isolation
10 Chapter 9: Campus Network Security and Segmentation
9.1 DHCP Snooping and Dynamic ARP Inspection 9.2 Port Security and MAC Address Limiting 9.3 ClearPass Policy Management and RADIUS Change of Authorization 9.4 Dynamic Segmentation, User-Based Tunneling, and Policy Enforcement
11 Chapter 10: Authentication, Authorization, and Accounting
10.1 The AAA Framework and Architecture 10.2 802.1X Authentication and EAP Methods 10.3 MAC Authentication and Captive Portal Onboarding 10.4 Administrative Access Control: RADIUS vs TACACS+
12 Chapter 11: Network Management and Telemetry
11.1 Aruba Central Cloud Architecture and Group Configuration 11.2 Zero-Touch Provisioning (ZTP) and Aruba Activate 11.3 AI Insights and Aruba User Experience Insight (UXI) 11.4 Network Telemetry, Streaming APIs, and SNMP/Syslog
13 Chapter 12: Troubleshooting the Solution
12.1 Structured Troubleshooting Methodologies and Scope Isolation 12.2 AOS-CX Layer 2 and Interface Diagnostic Commands 12.3 Layer 3, IP Services, and End-to-End Diagnostics 12.4 Physical-Layer Troubleshooting 12.5 Troubleshooting Wireless Clients and Network Access
14 Chapter 13: Optimizing Performance: QoS, Baselines, and Comparisons
13.1 Quality of Service (QoS) Classification and Marking 13.2 Queuing Algorithms and Congestion Management 13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting 13.4 Establishing a Performance Baseline 13.5 Comparing Results to the Baseline
15 Chapter 14: Plan the Solution
14.1 Analyzing the Current Environment 14.2 Interpreting an Architect's High-Level Design 14.3 Creating a Low-Level Design 14.4 Preparing for Implementation
16 Chapter 15: Validate and Operate the Solution
15.1 Validating the Solution 15.2 Performing Firmware Updates 15.3 Making Basic Ongoing Configuration Changes 15.4 Maintaining Network Documentation
10.4 Administrative Access Control: RADIUS vs TACACS+
Key Takeaways Explain This Topic AI
RADIUS combines authentication and authorization in one Access-Accept, whereas TACACS+ (RFC 8907) separates authentication, authorization, and accounting into independent transactions.
TACACS+ provides full payload encryption (encrypting all fields after the 12-byte header), whereas RADIUS encrypts only the user password attribute within an otherwise cleartext UDP datagram.
TACACS+ operates over connection-oriented TCP port 49, ensuring immediate detection of server outages, whereas RADIUS relies on connectionless UDP ports 1812 and 1813.
The defining operational capability of TACACS+ is per-command authorization, enabling policy servers like ClearPass to inspect, permit, or deny individual CLI commands entered during an active administrative session.
When configuring AOS-CX administrative AAA, administrators must configure 'local' fallback following remote server groups to prevent total management lockout in the event of an authentication infrastructure outage.
Last updated: October 2026
Administrative Access Control: RADIUS vs TACACS+
Quick Summary: Campus network security extends beyond user access control to encompass management plane administration —securing CLI, SSH, Web UI, and REST API access to network switches. While RADIUS is widely deployed for network access control (802.1X), TACACS+ is the industry standard for device administration. TACACS+ decouples Authentication, Authorization, and Accounting into separate transactions, operates over reliable TCP port 49 , encrypts the entire packet body , and uniquely supports granular per-command authorization . Configuring administrative AAA on AOS-CX requires defining server groups, enabling command authorization policies, and enforcing local fallback to prevent administrative lockouts during server outages.
Securing the Campus Management Plane
Enterprise network switches operate across three conceptual planes:
Data Plane: Forwards user frames and packets in hardware ASICs.
Control Plane: Maintains routing tables and spanning tree topologies (OSPF, BGP, MSTP).
Management Plane: Encompasses administrative management access methods, including SSH, switch console ports, the Web GUI, SNMP, and REST APIs.
The Vulnerability of Local Shared Credentials
In unmanaged environments, administrators frequently share a single static admin password. This practice introduces severe organizational and security risks:
Zero Accountability: Audit logs show actions executed by admin , making it impossible to determine which specific engineer executed a configuration change or caused an outage.
Revocation Bottlenecks: When an engineer departs an organization, the shared password must be manually updated across hundreds of switches.
Compliance Non-Compliance: Regulations (PCI-DSS, HIPAA, SOX, ISO 27001) mandate individual accountability and multi-factor or centralized administrative access control.
Centralized management access solves this by authenticating administrators against enterprise directories (such as Active Directory) through centralized AAA protocols.
Architectural Comparison: RADIUS vs. TACACS+
Two protocols dominate centralized AAA: RADIUS (Remote Authentication Dial-In User Service, RFC 2865/2866) and TACACS+ (Terminal Access Controller Access-Control System Plus, RFC 8907): +---------------------------------------------------------------------------------------------------------+
- | RADIUS VS. TACACS+ ARCHITECTURE |
- | |
- | [ RADIUS PROTOCOL ] |
- | - Purpose: Network Access Control (802.1X, VPNs, Wireless) |
- | - AAA Structure: COMBINES Authentication & Authorization into one Access-Accept frame. |
- | - Transport: Connectionless UDP (Ports 1812 Auth/AuthZ, 1813 Acct) |
- | - Encryption: PARTIAL (Only the password attribute is encrypted; username and payload are visible) |
- | - Authorization: Coarse-grained (Assigns a single privilege level upon initial login) |
- | |
- | [ TACACS+ PROTOCOL ] |
- | - Purpose: Network Device Administration (Routers, Switches, Firewalls) |
- | - AAA Structure: DECOUPLES Authentication, Authorization, and Accounting into separate phases. |
- | - Transport: Connection-Oriented TCP (Port 49) |
- | - Encryption: FULL PAYLOAD (Entire packet encrypted after 12-byte header) |
- | - Authorization: FINE-GRAINED (Per-command authorization evaluated in real-time) |
- +---------------------------------------------------------------------------------------------------------+
- 1. AAA Decoupling
RADIUS: Tightly couples Authentication and Authorization. When a user submits credentials, the server returns either an Access-Reject or an Access-Accept . All authorization metadata (such as privilege level or user role) must be bundled directly inside the Access-Accept packet. Once authenticated, no further authorization queries occur during that session.
TACACS+: Strictly separates all three services into independent protocol transactions:
An administrator can authenticate via one mechanism (e.g., Active Directory / Kerberos).
Authorization requests occur continuously throughout the active session.
Accounting runs as an entirely separate stream of TCP transactions.
2. Transport Protocol and Reliability
RADIUS: Runs over UDP (standard ports 1812 for authentication/authorization and 1813 for accounting; legacy ports 1645 and 1646 ). Because UDP is connectionless, the switch must implement application-layer timers and retransmission logic. Detecting a dead RADIUS server requires waiting for multiple request timeouts.
TACACS+: Runs over TCP port 49 . The switch establishes a connection-oriented three-way handshake with the server. If the server crashes or the link drops, the switch receives an immediate TCP RST or detects connection termination within milliseconds, rapidly failing over to a secondary AAA server.
3. Packet Encryption Scope
RADIUS: Provides partial encryption . RADIUS encrypts only the User-Password attribute using a shared secret and an MD5 hash. The packet header, username, IP addresses, vendor-specific attributes, and all accounting information traverse the network in plaintext. An attacker capturing packets on intermediate links can harvest administrative usernames and monitor network activity.
TACACS+: Enforces full payload encryption . Only the standard 12-byte TACACS+ header remains in the clear (identifying sequence number, flags, and session ID). The entire body of the packet—including usernames, challenge prompts, authorized command strings, and configuration payloads—is cryptographically encrypted using an MD5-based stream cipher seeded by the shared secret.
Per-Command Authorization in TACACS+
The single most critical functional differentiator between RADIUS and TACACS+ in campus switch management is per-command authorization .
Why RADIUS Cannot Authorize Commands
Under RADIUS, authorization occurs once at login. ClearPass returns a privilege or role attribute (for example, an administrator or read-only role). Once the administrator enters the CLI, the switch evaluates permissions locally based on that static privilege level. The switch cannot query ClearPass dynamically to determine whether the user is permitted to run specific commands.
How TACACS+ Command Authorization Operates
TACACS+ enables real-time, interactive command filtering. Every time the administrator types a command and presses <Enter> , the switch suspends execution and queries ClearPass: +---------------------------------------------------------------------------------------------------------+
- | TACACS+ PER-COMMAND AUTHORIZATION FLOW |
- | |
- | [ Network Administrator ] [ AOS-CX Switch ] [ ClearPass Policy Mgr ] |
- | | | | |
- | | --- Types: "show vlan" --------> | | |
- | | | --- TACACS+ AuthZ Request --------> | |
- | | | User: j_doe, Cmd: "show vlan" | |
- | | | +-- Matches |
- | | | <--- TACACS+ AuthZ PASS ------------+ Permit Set |
- | | <=== Outputs VLAN Table ======== | | |
- | | | | |
- | | --- Types: "erase startup" ----> | | |
- | | | --- TACACS+ AuthZ Request --------> | |
- | | | User: j_doe, Cmd: "erase ..." | |
- | | | +-- Matches |
- | | | <--- TACACS+ AuthZ FAIL ------------+ Deny Rule |
- | | <=== "% Command Denied!" ======= | | |
- +---------------------------------------------------------------------------------------------------------+
Command Interception: The administrator enters interface 1/1/1 and presses Enter. The switch CLI engine intercepts the command string.
Authorization Request: The switch generates a TACACS+ AUTHOR_REQUEST packet containing:
- user: j_doe
- cmd: interface
- cmd-arg: 1/1/1
Policy Evaluation on ClearPass: ClearPass checks the user's role against configured TACACS+ Command Sets :
Tier-1 Helpdesk: Permitted commands: show * , ping * , traceroute * . Denied: configure * , erase * .
Senior Network Engineers: Permitted commands: * (unrestricted).
Execution Decision: ClearPass responds with TACACS_AUTHOR_STATUS_PASS_ADD or STATUS_FAIL . If permitted, the switch executes the command; if denied, the switch displays % Command authorization failed and logs an accounting alert.
Technical Comparison: RADIUS vs. TACACS+
- Technical Dimension RADIUS (RFC 2865 / 2866) TACACS+ (RFC 8907)
- Primary Use Case Network Access Control (802.1X, VPNs, Wi-Fi) Device Administration (CLI, SSH, Switch Web UI)
- AAA Architecture Combined Authentication and Authorization Strictly Decoupled (Independent AuthN, AuthZ, Acct)
- Transport Protocol UDP (Connectionless) TCP (Connection-Oriented)
- Network Ports Port 1812 (Auth/AuthZ), Port 1813 (Acct) Port 49 (AuthN, AuthZ, Acct)
- Encryption Scope Partial (User-Password attribute only) Full Payload (Entire body encrypted)
- Command Authorization No (Coarse privilege level at login only) Yes (Real-time per-command authorization)
- Accounting Reliability Best-effort UDP retransmissions Reliable TCP delivery with acknowledgements
- Challenge-Response Supported (EAP) Supported (Interactive ASCII challenges)
- AOS-CX Configuration for Administrative AAA
The following configuration illustrates defining TACACS+ servers, creating server groups, configuring authentication and command authorization, and enforcing local fallback on an AOS-CX switch: switch# configure terminal
- ! Step 1: Define Primary and Secondary TACACS+ Servers
- switch(config)# tacacs-server host 10.10.100.50 key plaintext SecretTacacsKey123
- switch(config)# tacacs-server host 10.10.100.51 key plaintext SecretTacacsKey123
- ! Step 2: Create a TACACS+ Server Group
- switch(config)# aaa group server tacacs CPPM-TACACS-GROUP
- switch(config-sg)# server 10.10.100.50
- switch(config-sg)# server 10.10.100.51
- switch(config-sg)# exit
- ! Step 3: Configure Administrative Login Authentication with Local Fallback
- switch(config)# aaa authentication login default group CPPM-TACACS-GROUP local
- switch(config)# aaa authentication login console group CPPM-TACACS-GROUP local
- ! Step 4: Configure Per-Command Authorization
- switch(config)# aaa authorization commands default group CPPM-TACACS-GROUP local
- ! Step 5: Configure Administrative Command Accounting
- switch(config)# aaa accounting all-mgmt default start-stop group CPPM-TACACS-GROUP
- The Critical Role of Local Fallback and Lockout Prevention
Notice the authentication syntax: aaa authentication login default group CPPM-TACACS-GROUP local .
Order of Evaluation: The switch evaluates authentication methods from left to right. When an administrator initiates an SSH session, the switch queries the servers in CPPM-TACACS-GROUP first. If reachable, ClearPass handles the authentication.
The Fallback Trigger: The switch falls back to the local user database only if all remote TACACS+ servers are completely unreachable (connection timed out or TCP connection reset).
The Rejection Rule: If ClearPass is online and returns an Authentication Failure (e.g., the engineer entered the wrong password), the switch does not fall back to local by default. It rejects the login immediately. Fallback exists to survive infrastructure outages, not to provide an alternative path for bad passwords. (AOS-CX can be changed to fail through to the next method after a reject with aaa authentication allow-fail-through , which is not the default.)
Disastrous Misconfiguration: If an administrator omits local from the command ( aaa authentication login default group CPPM-TACACS-GROUP ) and an upstream firewall cuts off access to ClearPass, all administrators are completely locked out of the switch , requiring a physical console password-recovery reboot.
Common Exam Traps
TACACS+ Encryption Myth: A common exam question tests packet visibility. Candidates incorrectly assume RADIUS encrypts the packet body. RADIUS encrypts only the password. TACACS+ encrypts the entire payload.
Transport Port Confusion: Remembering that TACACS+ uses TCP port 49 , whereas modern RADIUS uses UDP ports 1812 and 1813 (or legacy 1645/1646).
Local Fallback Behavior: Believing that entering an invalid password triggers local authentication fallback. By default, local fallback triggers only when the remote servers are unreachable or time out , not on an explicit authentication failure (unless aaa authentication allow-fail-through is configured).