A real-life situation
The company now has 40 switches and routers and eight network engineers. With local usernames, every new engineer means logging in to 40 devices to add an account, and when someone leaves, 40 more changes. Last month one device was missed and a former contractor could still log in. The fix is to keep the user list in one central server and have every device ask it. That is what AAA does.
- 1. Alice connects to SW1. She types her own username and password, the same ones she uses on every device.
- 2. SW1 asks the AAA server. SW1 doesn't hold Alice's account. It sends the credentials to 192.168.20.50 over RADIUS or TACACS+, protected with a shared key.
- 3. The server answers. The server checks its user list and replies accept or reject, and can also say what she is allowed to do.
- 4. SW1 reports what happened. Accounting records go to the server: when Alice logged in, and later the commands she ran and when she left.
What AAA is
AAA is a framework with three separate jobs:
| Part | Question it answers | Example |
|---|---|---|
| Authentication | Who are you? | Alice logs in with her username and password. |
| Authorization | What are you allowed to do? | Alice gets privilege level 15; a help-desk user may only run show commands. |
| Accounting | What did you do? | A record says Alice logged in at 09:02, ran shutdown on Gi1/0/5 and logged out at 09:15. |
The device asking the questions (SW1 here) is often called the network access device or AAA client. The server that answers is the AAA server; Cisco's product for this is Cisco ISE (Identity Services Engine). The two talk with one of two protocols: RADIUS or TACACS+.
RADIUS vs. TACACS+
| RADIUS | TACACS+ | |
|---|---|---|
| Standard | Open standard (IETF) | Created by Cisco, now published as an informational RFC |
| Transport | UDP 1812 (authentication), 1813 (accounting); older 1645/1646 | TCP 49 |
| Encryption | Only the password field | The whole message body |
| AAA functions | Authentication and authorization combined in one reply | All three separate |
| Command authorization | No per-command checks | Yes, each command can be approved and logged |
| Typical use | Network access: 802.1X, Wi-Fi, VPN users | Device administration: engineers logging in to routers and switches |
A simple way to remember it: RADIUS lets users onto the network, TACACS+ controls admins on the devices.
Why it works that way
- One list, many devices. Adding or removing a person happens once, on the server, and takes effect everywhere.
- Separate jobs give finer control. Because TACACS+ asks separately for each command, the server can allow
showcommands for the help desk and everything for senior engineers, and log each command in accounting. - A shared key protects the conversation. The device and the server share a secret key. It is used to hide the password (RADIUS) or the whole body (TACACS+) and to prove that replies really come from the server.
- Method lists avoid lock-out. If the server is down, nobody could log in to fix the network. A method list is an ordered list of ways to authenticate, such as "try the server group, then the local users".
How it works step by step
A method list with local fallback
A TACACS+ login
With RADIUS the pattern is shorter: one Access-Request (UDP 1812) and one Access-Accept or Access-Reject that carries both the authentication result and the authorization attributes.
RADIUS and 802.1X: users onto the network
RADIUS is also what makes 802.1X work. 802.1X is port-based access control: a switch port (or Wi-Fi network) lets no traffic through until the device connected to it has logged in. It is a much stronger check than Port security, because it verifies a username or certificate rather than a MAC address that can be copied. There are three roles:
The same three roles appear in WPA2/WPA3-Enterprise Wi-Fi, where the wireless controller is the authenticator. See Wireless security.
How to configure it on Cisco IOS
⚠️ Based on Cisco IOS XE documentation, not run on a lab device. Create a local fallback user before typing aaa new-model: from that moment the lines use AAA instead of their line passwords, and the open session is the only safe way back in.
username admin privilege 15 algorithm-type scrypt secret Adm1n-S3cret!
aaa new-modelStep 1: a local emergency account, then enable AAA. aaa new-model on its own makes VTY logins check local usernames.
TACACS+ for device administration
tacacs server TAC1
address ipv4 192.168.20.50
key T4cacs-Key!
aaa group server tacacs+ TAC-SERVERS
server name TAC1Define the server with its shared key (must match the server exactly), then put it in a named group. A group can hold several servers, tried in order.
aaa authentication login default group TAC-SERVERS local
aaa authorization exec default group TAC-SERVERS local
aaa authorization commands 15 default group TAC-SERVERS local
aaa accounting exec default start-stop group TAC-SERVERS
aaa accounting commands 15 default start-stop group TAC-SERVERSAuthenticate logins, authorize the shell and every level-15 command, and record sessions and commands. local after the group is the fallback when no server answers.
RADIUS instead
radius server ISE1
address ipv4 192.168.20.50 auth-port 1812 acct-port 1813
key R4dius-Key!
aaa group server radius ISE-SERVERS
server name ISE1
aaa authentication login VTY-LOGIN group ISE-SERVERS local
line vty 0 15
login authentication VTY-LOGINA named method list (VTY-LOGIN) applied only to the VTY lines. The console keeps the default behaviour. Older IOS uses the single-line form radius-server host 192.168.20.50 key R4dius-Key!.
Full example for SW1
username admin privilege 15 algorithm-type scrypt secret Adm1n-S3cret!
aaa new-model
!
tacacs server TAC1
address ipv4 192.168.20.50
key T4cacs-Key!
aaa group server tacacs+ TAC-SERVERS
server name TAC1
ip tacacs source-interface Vlan10
!
aaa authentication login default group TAC-SERVERS local
aaa authorization exec default group TAC-SERVERS local
aaa accounting exec default start-stop group TAC-SERVERS
!
line console 0
exec-timeout 10 0
line vty 0 15
transport input ssh
exec-timeout 10 0
!
end
copy running-config startup-configThe default list applies to every line, console included, without a login command on the lines. ip tacacs source-interface makes SW1 always use 192.168.10.2, the address the server has on file for it.
How to verify it
SW1#test aaa group TAC-SERVERS alice Al1ce-Pass! legacy Attempting authentication test to server-group TAC-SERVERS using tacacs+ User was successfully authenticated.
SW1#show tacacs Tacacs+ Server - public : Server name: TAC1 Server address: 192.168.20.50 Server port: 49 Socket opens: 14 Socket closes: 14 Socket aborts: 0 Socket errors: 0 Socket Timeouts: 0 Failed Connect Attempts: 0 Total Packets Sent: 42 Total Packets Recv: 42 ...
SW1#show running-config | include aaa aaa new-model aaa group server tacacs+ TAC-SERVERS aaa authentication login default group TAC-SERVERS local aaa authorization exec default group TAC-SERVERS local aaa accounting exec default start-stop group TAC-SERVERS ...
local last.debug aaa authentication shows each step of a login, including which method was tried and its result. Use it carefully on a busy device.
What goes wrong and how to troubleshoot it
| Symptom | Likely cause | Fix |
|---|---|---|
| Every login rejected, test aaa fails | Shared key differs between SW1 and the server | Re-enter the key on both sides |
| Server log shows the request from an unknown client | SW1 sends from a different source IP than the server expects | ip tacacs source-interface or ip radius source-interface |
Locked out after aaa new-model | No local user and no reachable server | Console password recovery; next time create the local user first |
| Server down and the local user can't log in | local missing from the method list | Add local after the group |
| Correct local password refused while the server is up | Expected: the server rejected the user, so local is not tried | Fix the account on the server |
Login works but lands at > | No exec authorization, so no privilege level from the server | aaa authorization exec default group ... local |
Common mistakes
- Typing
aaa new-modelbefore any local user exists. - Putting
localfirst in the list, so the server is only used if the local database has no users at all. - Expecting a server reject to fall back to local. Fallback is only for no answer.
- Mixing up the protocols: RADIUS is UDP and hides only the password; TACACS+ is TCP 49 and encrypts everything.
- Creating a named method list and forgetting
login authentication <name>on the lines, so the default list is used instead.
💡 Exam tip: the CCNA asks you to tell the three As apart from a description ("records the commands a user ran" is accounting) and to compare RADIUS and TACACS+: UDP vs. TCP 49, password-only vs. full-body encryption, combined vs. separate AAA, network access vs. device administration. Know the 802.1X roles: supplicant, authenticator, authentication server. And remember that local fallback happens only when the server does not respond.
Key takeaways
- Authentication = who you are; authorization = what you may do; accounting = what you did.
- A central AAA server means one user list for every device.
- RADIUS: UDP, open standard, password-only encryption, used for network access and 802.1X.
- TACACS+: TCP 49, full encryption, separate AAA and per-command control, used for device admin.
- Method lists such as
group TAC-SERVERS localfall back to local only when no server answers.
Check yourself
A log shows that user bob ran 'reload' on R1 at 14:10. Which part of AAA produced this record?
Which protocol uses TCP port 49, encrypts the whole message body and separates authentication from authorization?
The method list is: aaa authentication login default group TAC-SERVERS local. The TACACS+ server is up and rejects alice's password. What happens?
In 802.1X, which role does the access switch play?
You want each command typed by help-desk staff on routers to be approved or denied by the server. Which protocol fits best?