Exam Objective 4.1: Configure network devices with local usernames and as an AAA client (TACACS+ and RADIUS) for management.
Controlling who can log into a router or switch, and what they're allowed to do once logged in, is a foundational security responsibility. This objective covers two layers of that control: basic local username/password authentication configured directly on the device, and the far more scalable AAA (Authentication, Authorization, Accounting) framework, where the device acts as a client sending authentication requests to a centralized server using either TACACS+ or RADIUS. Understanding both the simple local method and how a device participates in centralized AAA is core to managing device access in any real network.
The simplest form of device access control is a locally configured username and password database stored directly in the device's running configuration — no external server required.
Configuration:
username admin privilege 15 secret Str0ngP@ss!
Key components of this command:
username [name] — creates a local user account
privilege 15 — assigns the account the highest privilege level (15), granting full administrative access; privilege levels range from 0 to 15, with 1 being the default level for a standard login and 15 being full enable-equivalent access
secret — stores the password using a strong, salted hash (specifically, Cisco's Type 6 or Type 9 secret depending on platform/configuration, generally the preferred option over the older, weaker password keyword)
Applying local authentication to login lines:
line vty 0 4
login local
transport input ssh
login local — tells the line to authenticate incoming connections against the locally configured username database (rather than a simple line password or an external AAA server). Without this, line vty 0 4 login (with just a line password keyword, password) uses a single shared password for anyone connecting, with no individual username-level accountability.
Why local authentication alone doesn't scale: Local usernames must be configured and maintained individually on every single device — adding, removing, or changing a user's access means logging into and editing every router and switch in the network separately. This is manageable for a handful of devices but becomes operationally unworkable at any real scale, which is exactly the problem centralized AAA is designed to solve.
Exam Alert: Know that login local specifically directs authentication to the locally configured username database, as distinct from a plain password-only line login or from AAA-based authentication pointing to an external server — these are three genuinely different authentication methods, and the exam expects you to distinguish them.
AAA is a framework — not a single protocol — describing three distinct, related functions for controlling and tracking access to a device or network:
Authentication — verifying a user's identity, typically via a username and password (or other credential), answering the question "who are you?"
Authorization — determining what an already-authenticated user is actually permitted to do, answering the question "what are you allowed to access or execute?" (for example, restricting a specific user to only certain show commands, while another user has full configuration access)
Accounting — logging what an authenticated and authorized user actually did during their session, answering the question "what did you actually do?" (commonly used for audit trails, tracking exactly which commands were executed and when, by whom)
Why AAA matters at scale: Rather than configuring local usernames individually on every device, AAA allows a network device to forward authentication (and authorization/accounting) requests to a centralized external server, so that user accounts, passwords, and access policies are managed in one place and automatically apply consistently across every device configured as an AAA client.
Basic AAA enablement:
aaa new-model
This global command must be entered before any further AAA configuration (method lists, server definitions, and so on) becomes available or takes effect — it fundamentally switches the device's authentication behavior away from simple line-based login toward the AAA framework.
Exam Alert: aaa new-model is the mandatory first step for any AAA configuration — a very commonly tested "must-configure-this-first" fact, similar in spirit to ip routing being required before SVIs route traffic, or ipv6 unicast-routing being required before IPv6 forwards.
In an AAA deployment, the network device itself (the router or switch that a user is trying to log into) is referred to as the AAA client (sometimes also called the Network Access Server, or NAS, in this specific context). The AAA client does not make the actual authentication decision itself — instead, it forwards the user's submitted credentials to a separate, centralized AAA server (running TACACS+ or RADIUS), and then either permits or denies access based on that server's response.
This client role requires the device to be configured with:
The IP address of the AAA server(s) it should contact
A shared secret key, used to encrypt/authenticate communication between the AAA client and the AAA server, which must match exactly on both the client and the server
A method list, defining the order in which authentication methods should be attempted (for example, try the AAA server first, and fall back to the local username database if the server is unreachable)
Method lists — a critical AAA concept: A method list is a named, ordered sequence of authentication (or authorization/accounting) methods that AAA will attempt in sequence. If the first method in the list is unavailable (not simply "authentication failed," but genuinely unreachable/not responding), AAA moves on to try the next method in the list; if the first method is reachable and actively rejects the credentials, however, AAA does not fall through to the next method — the user is denied.
Example method list configuration:
aaa authentication login VTY-AUTH group tacacs+ local
This defines a method list named VTY-AUTH that first attempts authentication against a TACACS+ server group, and falls back to the local username database only if the TACACS+ server(s) are unreachable.
Applying the method list to login lines:
line vty 0 4
login authentication VTY-AUTH
Exam Alert: Understand the critical distinction: a AAA server being unreachable triggers fallback to the next method in the list, but a AAA server actively responding with "access denied" does not trigger fallback — this prevents a compromised or misused account from simply being handed a second chance against a weaker local password database.
TACACS+ is a Cisco-developed (though now an open, documented) AAA protocol, historically favored for device administration/management access specifically — controlling who can log into and configure network infrastructure devices themselves.
Key TACACS+ characteristics:
Uses TCP port 49
Encrypts the entire body of each packet, not just the password field — providing stronger confidentiality for the full AAA exchange compared to RADIUS
Separates authentication, authorization, and accounting into three genuinely distinct processes/exchanges, allowing much more granular control — for example, allowing very fine-grained authorization down to the level of specific individual commands a user is permitted to execute (command authorization), a capability RADIUS does not natively provide
Cisco-proprietary in its original design, though the protocol specification has since been published and other vendors have implemented compatible TACACS+ support
TACACS+ server configuration on the device:
tacacs server TAC-SERVER1
address ipv4 10.1.1.100
key MySharedSecretKey123
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local
Exam Alert: TACACS+'s ability to authorize down to the individual command level (command authorization) is its single most distinguishing, frequently tested feature compared to RADIUS — remember TACACS+ for device/administrative access control with granular command-level authorization.
RADIUS is an open IETF standard AAA protocol, historically favored for network access control — authenticating end users/devices connecting to the network itself (dial-up originally, and today most commonly 802.1X wired/wireless network access and VPN authentication), rather than device management access specifically.
Key RADIUS characteristics:
Uses UDP ports 1812 (authentication) and 1813 (accounting) under current standards (older implementations historically used ports 1645/1646, still occasionally seen)
Encrypts only the password field within each packet, not the entire packet body — a comparatively weaker confidentiality model than TACACS+'s full-packet encryption
Combines authentication and authorization into a single, combined process/exchange, rather than separating them into fully distinct steps the way TACACS+ does — meaning RADIUS provides less granular authorization control overall, and does not natively support TACACS+-style per-command authorization
Open, vendor-neutral standard, widely supported across virtually all networking and identity-management vendors, making it the natural choice in mixed-vendor or heavily standards-based environments
RADIUS server configuration on the device:
radius server RAD-SERVER1
address ipv4 10.1.1.101 auth-port 1812 acct-port 1813
key MyOtherSharedSecretKey456
aaa authentication login default group radius local
Exam Alert: Know that RADIUS combines authentication and authorization together (while TACACS+ separates them), and that RADIUS only encrypts the password field rather than the full packet body — both of these are frequently tested, direct contrasts against TACACS+'s behavior.
TACACS+:
Cisco-developed, now openly documented
TCP port 49
Encrypts the entire packet body
Separates authentication, authorization, and accounting into distinct processes
Supports granular per-command authorization
Traditionally used for device/administrative management access
RADIUS:
Open IETF standard
UDP ports 1812/1813 (or legacy 1645/1646)
Encrypts only the password field
Combines authentication and authorization together
Does not natively support per-command authorization
Traditionally used for network access control (802.1X, VPN, dial-up)
Exam Alert: A simple memory anchor: TACACS+ = TCP, Total packet encryption, Triple-separated AAA functions, and Terminal/device access. RADIUS = UDP, only password encrypted, combined AuthN/AuthZ, and Remote/network access (802.1X, VPN). The exam very frequently tests these contrasts directly, sometimes as straightforward recall and sometimes embedded in a scenario describing a specific use case and asking which protocol fits better.
show running-config | section aaa — displays the full AAA configuration, including method lists, server group definitions, and applied line configuration
show tacacs — displays TACACS+ server status and statistics, including whether the configured server(s) are currently reachable
show radius statistics — displays RADIUS-related statistics, including packet counts and any failures
test aaa group [group-name] [username] [password] legacy — allows an administrator to directly test whether a specific AAA server group correctly authenticates a given set of credentials, without needing to actually log out and attempt a real login
debug aaa authentication — shows real-time AAA authentication processing (use cautiously in production due to CPU load, consistent with general debug command guidance covered in objective 2.4)
Common AAA configuration problems:
aaa new-model not enabled, so none of the subsequent AAA configuration takes effect at all
Shared secret key mismatch between the device and the AAA server, causing all authentication attempts to fail even with correct user credentials
AAA server unreachable due to a network/firewall issue, with no local fallback configured in the method list — meaning administrators can be completely locked out of a device if the AAA server becomes unreachable and there's no local username as a fallback
Method list not actually applied to the relevant line (vty, console, aux) — the method list can be perfectly configured but simply never referenced by the login authentication command on the actual line being used
Confusing TACACS+ port (TCP 49) with RADIUS ports (UDP 1812/1813) when troubleshooting firewall/ACL rules blocking AAA traffic between the client and server
Exam Alert: Always configure a local fallback method (group tacacs+ local, for example) in any production AAA method list — losing all administrative access to a device because its only AAA server became unreachable, with no local fallback, is a classic and severe real-world (and exam scenario) mistake.
Confirm aaa new-model has been enabled globally — nothing else in AAA configuration takes effect without it.
Define the AAA server (TACACS+ and/or RADIUS) with its correct IP address, port, and shared secret key, confirming the key matches exactly what's configured on the actual server side.
Create a method list specifying the desired order of authentication methods, always including a local fallback method for resilience against server unavailability.
Apply the method list to the appropriate line(s) — vty, console, aux — using login authentication [list-name]; remember that login local alone only references the local database, not any AAA method list.
If authorization is required (particularly TACACS+ command-level authorization), configure the corresponding aaa authorization statements separately from authentication.
Test the configuration using test aaa group before relying on it for a live login session, to avoid accidentally locking yourself out.
If authentication fails unexpectedly, check for a shared secret key mismatch, confirm server reachability (show tacacs / show radius statistics, plus basic ping/ACL checks), and confirm the method list is actually applied to the line in use.
Q1. Which command must be entered before any further AAA configuration will take effect on a Cisco device?
A. login local
B. aaa new-model
C. username admin privilege 15 secret
D. ip routing
Answer: B. aaa new-model is the global command that enables the AAA framework on the device. Without it, none of the subsequent AAA configuration — method lists, server definitions, authorization statements — actually takes effect, and the device continues using traditional line-based login behavior instead.
Q2. Which AAA protocol encrypts the entire body of each packet and separates authentication, authorization, and accounting into fully distinct processes, including support for granular per-command authorization?
A. RADIUS
B. TACACS+
C. LLDP
D. SNMP
Answer: B. TACACS+ encrypts the full packet body (not just the password field) and treats authentication, authorization, and accounting as separate, distinct processes, which is specifically what enables its granular per-command authorization capability — a feature RADIUS does not natively support, since RADIUS combines authentication and authorization together.
Q3. Which ports does RADIUS use by default under current standards for authentication and accounting?
A. TCP 49
B. UDP 1812 and UDP 1813
C. TCP 1812 and TCP 1813
D. UDP 49
Answer: B. RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting under current standards (legacy implementations historically used ports 1645 and 1646). TACACS+, by contrast, uses TCP port 49.
Q4. A method list is configured as "aaa authentication login VTY-AUTH group tacacs+ local," and the configured TACACS+ server becomes completely unreachable due to a network outage. What happens when a user attempts to log in?
A. The login attempt fails immediately with no fallback
B. AAA falls back to the local username database, since the first method is unreachable rather than actively rejecting the credentials
C. The device automatically switches to RADIUS instead
D. The user is granted access without any authentication
Answer: B. Because the method list includes "local" as a fallback method after "group tacacs+," and the TACACS+ server is genuinely unreachable (not merely rejecting the credentials), AAA proceeds to the next method in the list and authenticates against the local username database instead. If the TACACS+ server had been reachable and had actively denied the credentials, no fallback would occur.
Q5. Which statement correctly distinguishes the traditional use cases of TACACS+ and RADIUS?
A. TACACS+ is traditionally used for network access control like 802.1X, while RADIUS is used for device management
B. TACACS+ is traditionally used for device/administrative management access, while RADIUS is traditionally used for network access control such as 802.1X and VPN authentication
C. Both protocols are used exclusively for device management with no distinction
D. Neither protocol has a traditional use-case distinction
Answer: B. TACACS+ has traditionally been the protocol of choice for controlling administrative access to network devices themselves (logging into and configuring routers/switches), largely due to its granular command-authorization capability. RADIUS has traditionally been favored for broader network access control scenarios such as 802.1X port-based authentication, VPN access, and wireless authentication.
Q6. An administrator configures a local username with the command "username admin privilege 15 secret Str0ngP@ss!" and applies "login local" to the VTY lines. What does this configuration accomplish?
A. It configures the device as a full AAA client using RADIUS
B. It authenticates VTY logins against the locally stored username database, independent of any external AAA server
C. It enables command-level authorization for the admin account
D. It requires aaa new-model to be configured first, or the command will fail
Answer: B. This configuration creates a local user account with full administrative privilege and directs VTY line authentication to use that locally stored username/password database via login local, entirely independent of any external TACACS+ or RADIUS server. This is a simpler, non-AAA authentication method, and does not require aaa new-model to be enabled, unlike centralized AAA-based authentication.