Device management access: local users, and AAA with TACACS+ and RADIUS

Why this matters

Every router and switch has a management door: the console port, and the VTY lines that SSH sessions arrive on. Who can open that door, what they can do once inside, and whether anyone can later see what they did are basic security questions. On a small network a junior engineer answers them with local accounts on each device. On a network of hundreds of devices, that does not scale: when someone leaves, nobody can be sure their account was removed from every box. So larger networks send every login to a central AAA server, and the device becomes a client of it.

When this is set up badly, two things happen. Either the door is too open, with one shared line password that everyone knows and nobody can trace, or it locks the engineers out, because AAA was switched on without a working fallback and the server was unreachable. Both are common, and both are fixed with a handful of commands that a network technician should be able to read and type without guessing.

The lesson

Local accounts and AAA client settings for management logins

There are three levels of control, and it helps to keep them apart:

1. A line password: one shared password on the console or VTY lines. Anyone who knows it gets in, and logs cannot say who it was.
2. Local usernames: named accounts stored on the device itself.
3. AAA with a server: the device asks a central TACACS+ or RADIUS server who the user is, what they may do, and records what they did.

AAA stands for authentication (who are you?), authorisation (what may you do?) and accounting (what did you do?).

Local usernames and privilege levels

IOS has privilege levels from 0 to 15. Level 1 is user EXEC, the R1> prompt, where you can look but hardly touch. Level 15 is privileged EXEC, the R1# prompt, with full control. A local account is created like this:

R1(config)#username netops privilege 15 secret N3tOps!
R1(config)#username helpdesk secret H3lpD3sk!

The secret keyword stores the password as a one-way hash. It cannot be read back from the configuration. The older password keyword stores it as reversible text. The command service password-encryption hides such passwords with type 7 encoding, which only stops someone reading over your shoulder; free tools reverse it in seconds. Always use secret, for usernames and for the enable password (enable secret).

The privilege level on the username matters at login. With the configuration above, netops lands straight at R1# without typing enable. The helpdesk account has the default level 1 and starts at R1>.

A username on its own changes nothing. The lines must be told to use the local database:

R1(config)#line vty 0 15
R1(config-line)#login local
R1(config-line)#transport input ssh
R1(config-line)#exec-timeout 10 0
R1(config-line)#exit
R1(config)#line con 0
R1(config-line)#login local

Without AAA, login local makes the line prompt for a username and check it against the local accounts. If the lines still have password and login, they keep asking only for the shared line password, whatever usernames exist. transport input ssh refuses Telnet, and exec-timeout 10 0 logs out an idle session after ten minutes. SSH itself needs a hostname, a domain name and an RSA key pair, which lesson 18 sets up.

Turning on AAA

AAA is switched on with one global command:

R1(config)#aaa new-model

This changes how every line authenticates, at once. Two consequences catch people out:

• With aaa new-model and no login method list defined, the VTY lines authenticate against the local username database.
• Line passwords are ignored from that moment.

So create a local user before you type aaa new-model. If you enable AAA over SSH with no local account, your next login fails, and the only way back in may be the console.

Method lists

A method list says which sources to ask, in order. The list called default applies to every line that has no other list. A named list applies only where you attach it.

R1(config)#aaa authentication login default group tacacs+ local
R1(config)#aaa authentication login CON local
R1(config)#line con 0
R1(config-line)#login authentication CON

The default list here sends every login to the TACACS+ servers first, then to the local accounts. The CON list uses local accounts only, and attaching it to the console with login authentication CON overrides the default list there. So the VTY lines use TACACS+ with local fallback, and the console uses local users only. Engineers often do this so a console login still works when the network is down.

The single most tested detail is when the router moves to the next method. It moves on only when a method returns an error, for example when no TACACS+ server answers. A reject is final. Two cases with the same default list:

• Every TACACS+ server is offline. That is an error, so R1 tries the next method, local, and an admin with a local account logs in.
• The TACACS+ server is reachable and says the password is wrong. That is a reject, so R1 denies the login. It does not then try the local password.

Without local at the end, a list that only contains group tacacs+ would lock everyone out whenever the servers are unreachable.

To put SSH logins on TACACS+ with local fallback through a list named ADMIN, two steps are needed after aaa new-model and the server definition: define the list, and apply it to the lines.

R1(config)#aaa authentication login ADMIN group tacacs+ local
R1(config)#line vty 0 15
R1(config-line)#login authentication ADMIN

login local under the lines does not belong in an AAA configuration; once aaa new-model is on, lines take their method from a list.

Defining the servers

Modern IOS and IOS XE use named server definitions:

R1(config)#tacacs server TAC1
R1(config-server-tacacs)#address ipv4 10.1.1.50
R1(config-server-tacacs)#key T@cKey9
R1(config-server-tacacs)#exit
R1(config)#radius server RAD1
R1(config-radius-server)#address ipv4 10.1.1.60 auth-port 1812 acct-port 1813
R1(config-radius-server)#key R@dKey7
R1(config-radius-server)#exit
R1(config)#ip tacacs source-interface Loopback0

The key subcommand sets the shared secret the router and the server use to protect their traffic. It must match the value entered for this router on the server. (secret is the keyword for hashed user and enable passwords, not for servers.)

The RADIUS ports deserve care. The IETF assigned UDP 1812 for authentication and UDP 1813 for accounting. Older RADIUS servers used 1645 and 1646, and some IOS releases still default to those, so set the ports explicitly to match the server.

A AAA server usually only accepts requests from addresses it knows. If the server knows R1 as 10.255.0.1, its Loopback0, but R1's requests leave from the physical interface 10.1.12.1, the server ignores them. ip tacacs source-interface Loopback0 fixes this for TACACS+. The RADIUS equivalent, ip radius source-interface, affects only RADIUS traffic.

Authorisation and accounting

Authentication proves identity. It does not set a privilege level. If admins log in through TACACS+ but always land at R1>, the router is not asking the server for their shell settings. Exec authorisation does that:

R1(config)#aaa authorization exec default group tacacs+ local
R1(config)#aaa authorization commands 15 default group tacacs+ local
R1(config)#aaa accounting exec default start-stop group tacacs+
R1(config)#aaa accounting commands 15 default start-stop group tacacs+

The first line fetches the privilege level the server assigns. The second asks the server about each level-15 command before it runs, which is how a security team limits junior staff to show commands. The accounting lines send a record when a session starts and stops, and for every level-15 command typed, so there is a trail of who changed what.

A login that uses all of this looks ordinary from the user's side:

login as: netops
Password:
R1#show privilege
Current privilege level is 15

Two more commands help when a login does not behave. show users lists who is connected and on which line, so you can confirm that a session arrived on a VTY line and not the console. test aaa group tacacs+ netops N3tOps! legacy sends a real authentication request from the router to the server and reports whether it was accepted, rejected or never answered. That last distinction is the one that matters: a reject means the server is reachable and the credentials or the server's policy are wrong, while no answer points at the network path, the source address or a mismatched key.

R1#test aaa group tacacs+ netops N3tOps! legacy
Attempting authentication test to server-group tacacs+ using tacacs+
User was successfully authenticated.

TACACS+ compared with RADIUS

RADIUS returns the user's authorisation details inside the same Access-Accept that authenticates them, so authentication and authorisation cannot be separated. TACACS+ handles each function in its own exchange, which is why a router can ask "may this user run this command?" one command at a time. For device administration, TACACS+ is usually the better fit. For network access, such as remote-access VPN users in lesson 21, RADIUS is the usual choice. Lesson 22 shows how an ACL on the VTY lines limits which addresses can reach the login prompt at all.

What the exam is really asking

• secret versus password. secret is a one-way hash. password is reversible, and type 7 is only a disguise.
• A username needs login local. Without AAA, the lines ignore usernames until told to use them.
• aaa new-model changes everything at once. With no list defined, VTY lines fall back to local users (the console asks for no login at all) and line passwords stop working. Create a local user first.
• Error versus reject. The router moves to the next method only when a server does not answer. A wrong password from a reachable server is final.
• Named beats default. A named list applied to a line replaces the default list on that line only.
• Authentication does not set privilege. Missing exec authorisation leaves server users at level 1.
• Server details. key sets the shared secret. RADIUS uses UDP 1812/1813, TACACS+ uses TCP 49. A source-interface command is protocol-specific.
• Protocol choice. Per-command control and full-body encryption point to TACACS+. Combined authentication and authorisation, and password-only hiding, point to RADIUS.