AAA for device logins (RADIUS and TACACS+)

Authentication, authorization and accounting moved off each device to a server, so one account works everywhere and one change applies everywhere. IOS lists the methods in order: aaa authentication login default group radius local asks the servers first, and uses the local accounts only when no server answers (an error), never after a reject (a failure); a break-glass local account exists for outages. Authorization grants a privilege level, 1 (user EXEC) to 15 (privileged EXEC). Accounting sends Start and Stop records for each session. RADIUS (UDP 1812/1813, open standard) answers authentication and authorization in one Access-Accept and hides only the password. TACACS+ (TCP 49, Cisco) separates the three, encrypts the whole body, and can authorize and log every command: the usual choice for device administration, RADIUS for network access.

How AAA with RADIUS works, step by step

In the AAA with RADIUS lab edgeRouter (10.0.1.2) is the NAS, radiusServer (10.0.1.10) runs FreeRADIUS, and admins log in from the laptop (10.0.1.11). The router and server share the secret router-secret. RADIUS is RFC 2865 (authentication, UDP 1812) and RFC 2866 (accounting, UDP 1813).

1. Access-Request. alice opens SSH to the router. sshd hands the login to PAM, which sends code 1 with User-Name, User-Password, NAS-IP-Address = 10.0.1.2, NAS-Port-Type = Virtual and Service-Type = Login-User. The password attribute is XORed with an MD5 stream of the secret and the request's 16-byte Authenticator; every other attribute travels in clear. A Message-Authenticator (an HMAC-MD5 over the packet, RFC 3579) signs it.
2. Access-Accept (code 2) or Access-Reject (code 3). The accept carries the authorization: Service-Type = Administrative-User and the vendor attribute Cisco-AVPair = "shell:priv-lvl=15". bob gets NAS-Prompt-User and level 1. The router enforces the level for the whole session.
3. Accounting-Request Start (code 4). When the session opens, the router reports it to port 1813 with an Acct-Session-Id; the server answers Accounting-Response (code 5), or the router resends.
4. Accounting-Request Stop. When it closes, the same session ID with Acct-Session-Time.

The method list decides what happens when the server is silent. On a router CLI it reads like aaa authentication login default group radius local; on this Linux router the PAM file plays that part. Local accounts are tried only after no answer (an error), never after an Access-Reject (a failure).

What it looks like on a Linux machine

The router's PAM file is the method list:

$ grep -v '^#' /etc/pam.d/sshd
auth     [success=done default=ignore]  pam_exec.so expose_authtok quiet /usr/local/sbin/radius-auth
auth     requisite                      pam_exec.so quiet /usr/local/sbin/radius-unreachable
auth     required                       pam_unix.so try_first_pass
account  include                        base-account
session  optional                       pam_exec.so quiet /usr/local/sbin/radius-acct
session  include                        base-session

tcpdump -v on radiusServer decodes bob's login. The name is readable, the password is not, and the accept carries the level:

10.0.1.2.47912 > 10.0.1.10.1812: RADIUS, length: 79
	Access-Request (1), id: 0xfb, Authenticator: 583247f3aa23a06e4737bd12cb9a0689
	  User-Name Attribute (1), length: 5, Value: bob
	  User-Password Attribute (2), length: 18, Value:
10.0.1.10.1812 > 10.0.1.2.47912: RADIUS, length: 68
	Access-Accept (2), id: 0xfb, Authenticator: ffc1783f4f7699620edda9248778b329
	  Service-Type Attribute (6), length: 6, Value: NAS Prompt
	  Vendor-Specific Attribute (26), length: 24, Value: Vendor: Cisco (9)
	    Vendor Attribute: 1, Length: 16, Value: shell:priv-lvl=1

A wrong password leaves a line in FreeRADIUS's log (auth = yes):

Auth: (1) Login incorrect (pap: Cleartext password does not match "known good" password): [bob] (from client edgeRouter port 0)

The Stop record lands in a detail file per client:

$ tail -12 /var/log/radius/radacct/10.0.1.2/detail-*
	User-Name = "alice"
	Acct-Status-Type = Stop
	Acct-Session-Id = "alice-4242"
	NAS-IP-Address = 10.0.1.2
	Acct-Session-Time = 6

What goes wrong, and how you see it

Shared secret mismatch. The server drops the request without a reply, so it looks like an outage, and the local account suddenly works. FreeRADIUS logs Received packet from 10.0.1.2 with invalid Message-Authenticator! (Shared secret is incorrect.). Make clients.conf and the router agree.

Unknown client. A request from an address not in clients.conf is ignored too, with Ignoring request ... from unknown client in the log. Add the device by address.

Everyone gets full rights. A help-desk user can change things. Capture the Access-Accept: the attribute says priv-lvl=15. Fix the user's entry on the server, not the device.

Local fallback that never fires. A method list that ends the login on any RADIUS failure locks everyone out during an outage. The log shows no answer with no local attempt. Fall through only on silence.

Local fallback that always fires. The opposite mistake: trying local accounts after a reject makes the break-glass account a permanent back door outside the server's logs.

Questions people ask

RADIUS vs TACACS+? RADIUS (UDP 1812/1813, open standard) hides only the password and authorizes once at login. TACACS+ (TCP 49, RFC 8907) encrypts the whole body, separates the three A's and can authorize and log each command, so it is the usual choice for device administration; RADIUS for network access such as 802.1X.

What is the difference between authentication and authorization? Who you are, and what you may do. See authentication vs authorization; RADIUS carries both in one Access-Accept.

Why keep a local account? For when the server is unreachable. Keep it rare, long, sealed, and changed after use.

See it on real machines