5.1Device access control (lines, local authentication, AAA)

Securing a network device starts not with protecting the traffic that passes through it but with protecting access to the device itself. If everyone shares one privileged password and types the same enable, you cannot trace who did what, and you cannot revoke a departing employee's account. ENCOR tests this area as operational design: which authentication method you bind to each line (console/VTY), which AAA server you choose and how the device behaves when it fails, and where you draw the line on privilege levels and command authorization. The essence is not the username command but the judgment to foresee whether the very act of applying the configuration locks you out.

5.1.1Lines and local user authentication

• Management access is controlled per line: line console 0 for the physical connection, line vty 0 15 for remote access, and line aux 0 for the auxiliary port—each with its own authentication configuration. Configuring login local under line vty 0 15 authenticates against the local user database defined with username ADMIN privilege 15 secret <pass>, using a username plus password. Plain login (with password) instead yields a shared password with no username, leaving no audit trail.
• Store passwords with secret (an irreversible hash) and avoid password (weak, reversible Type 7 obfuscation). Protect privileged EXEC with enable secret, and note that service password-encryption is only Type 7 obfuscation and provides no real strength. On VTY lines, set transport input ssh to forbid cleartext Telnet, and provision ip ssh version 2 with an RSA key (crypto key generate rsa modulus 2048).
• To restrict who can even reach the VTY lines, apply an ACL permitting only the management segment with access-class <ACL> in under the line (the key is that it goes under the line, not on an interface). Add exec-timeout 5 0 to drop idle sessions and login block-for options to throttle brute-force attempts.

5.1.2The three AAA functions and how they are applied

• AAA consists of three independent functions. Authentication verifies "who you are" via username/password or certificates. Authorization decides "what you, once authenticated, are allowed to do" (EXEC shell privilege level, the set of executable commands). Accounting records "who did what and when," providing the trail for audit and incident investigation.
• On IOS you enable aaa new-model and define a method list such as aaa authentication login default group tacacs+ local. Methods are evaluated left to right, and the device falls through to the next method only when the previous one does not respond. If the server responds with a rejection, it does not fall back to local—that distinction determines behavior during failures.
• Authorize the shell with aaa authorization exec default group tacacs+ local and privileged commands with aaa authorization commands 15 default group tacacs+ local. Enabling authorization but forgetting the local fallback causes a partial lockout when the server is unreachable: authentication succeeds but no EXEC shell opens. The standard safeguard is a separate method list, aaa authentication login CONSOLE local, bound with login authentication CONSOLE under line console 0.

5.1.3Choosing between TACACS+ and RADIUS

• TACACS+ uses TCP 49 and separates authentication, authorization, and accounting. Because it can query the server for authorization on a per-command basis, it suits fine-grained command authorization such as "this operator gets only show commands; that one may change configuration." It also encrypts the entire packet body, protecting usernames and executed commands from eavesdropping. It is Cisco-proprietary but is the de facto standard for device administration.
• RADIUS uses UDP 1812 (authentication/authorization) and 1813 (accounting) and combines authentication and authorization into a single exchange. Only the password attribute is encrypted; the username and other attributes travel in cleartext. Being an IETF standard with rich extended attributes, it is widely used for 802.1X network access control of end users and devices (integrating with ISE, dynamically assigning VLANs or SGTs).
• The selection principle is to split by purpose: TACACS+ for device administration (who may run which commands) and RADIUS for network access control (which endpoint lands in which VLAN). The decision axes are whether per-command authorization is required and how much of the packet is encrypted—not blanket claims that "RADIUS is safer" or "TACACS+ is old."

Suppose you roll out centralized TACACS+ management on your core switches with aaa new-model, aaa authentication login default group tacacs+, aaa authorization exec default group tacacs+, and tacacs server ISE. SSH logins work fine right after the change, but during next-day maintenance a routing failure between the management segment and the server leaves you unable to log in to any switch, via SSH or console. Suspecting a changed password would be a misdiagnosis. The cause is simply that the method list has no local fallback: with group tacacs+ alone, an unresponsive server leaves no next method, so authentication fails—and because the default method list applies to every line that has no other list explicitly bound (including the console), your last resort was blocked at the same time. The correct design is doubly protective. First, always place local at the end, as in aaa authentication login default group tacacs+ local and aaa authorization exec default group tacacs+ local, and provision the matching local user (username ADMIN privilege 15 secret ...) on every device. Second, create a separate list, aaa authentication login CONSOLE local, and bind it under line console 0 with login authentication CONSOLE so that the console alone does not depend on the AAA server. Deciding to "avoid adding local because it weakens security" is wrong: the fallback is used only when the server does not respond (it is not taken when a reachable server returns a rejection), so it is not a hole that bypasses legitimate denials. Adding aaa accounting commands 15 default start-stop group tacacs+ also preserves a record of who ran which command during recovery. As for change procedure, the field rule is to create the local user and enable secret before enabling AAA, and to verify from a second session left open.

5.1.4Section summary

• Bind authentication per line: login local plus transport input ssh under line vty, restrict reachability with access-class under the line, and store passwords with secret (hashed)
• AAA comprises authentication, authorization, and accounting. Method lists are evaluated left to right and fall through only on no response, so place local last and keep a separate console list to prevent lockout
• TACACS+ = TCP 49, separated AAA, whole-packet encryption, suited to per-command authorization for device administration; RADIUS = UDP 1812/1813, combined authentication/authorization, password-only encryption, suited to 802.1X access control