10/28/2024 | News release | Distributed by Public on 10/28/2024 15:23
I'll admit to not having done a thorough verification. However, I'd still bet money that AAA/RBAC services are more frequently mentioned on Cisco certification blueprints than any other networking topic. From the CCNA to the Expert level, you'll find AAA, TACACS+, RADIUS, and RBAC listed on the exam topics.
Here is a handful of examples if you'd like to check it out yourself:
OMG. That's 10 different certifications from Associate to Professional where these topics show up. You'll also find them on Expert-level exams, such as the Enterprise Infrastructure, Enterprise Wireless, Security, Service Provider, and Data Center labs. (If anyone out there can find another topic with as broad a coverage, please let me know in the comments. I'd love to know what I've overlooked so far.)
AAA is an important topic, but it's one that even long-time network engineers may not fully understand. So before we see it in action, how about a quick overview of what the "triple A's" mean?
Carl sees how Authentication, Authorization, and Accounting are separate and important steps for device administration.In the "AAA in Action!" comic, Carl experiences the entire AAA process:
TACACS comes into the picture to support the centralized management of users, roles, and logs (authentication, authorization, and accounting). While each network device could be locally configured to handle AAA, this doesn't scale well for enterprises. A better solution is for each network device to communicate with a central "server" for these actions. TACACS is a protocol that network devices and servers use to communicate and handle each of the "A's." A "TACACS Server" is a software application that supports the TACACS protocol.
Now that we understand the critical role that AAA plays in a network (and that it is an essential topic across many certifications), I'd like to show you how to study and prepare for it using my favorite network simulation/virtualization tool: Cisco Modeling Labs (CML). Because I'm all about sharing my exploration activities, I posted a couple of CML topology files on GitHub in the CML-community repository under Cisco DevNet.
You'll see that one CML topology includes just an IOL router, while another adds a Nexus 9000v switch to cover data center platforms as well. So, after you've read this blog post, definitely download the topologies and explore them yourself.
Before you can configure TACACS on a switch or router, you must have a TACACS server available in the network. A common TACACS server for a production network is Cisco ISE, a full "identity services engine" for device administration, network access, wireless security, VPN access, and more.
Cisco ISE is an important product and topic for network engineers. In fact, we have a certification exam dedicated to it. And while you can add Cisco ISE to a CML node library using the node definition available at the CML-Community, running a full ISE server in the topology can feel overkill when the focus is just on configuring TACACS for device administration.
Thankfully, there are lightweight alternatives. My go-to option is the open-source "tac_plus" application that has been available for many years. Tac_plus is a basic Linux application that can be downloaded and installed on most Linux distributions. While active development of the project seems to have stalled, it works great and continues to be an excellent option for cases such as this.
If you look at the image of the CML topology, you'll see "aaa-server" on the left-hand side of the diagram. This is a standard Ubuntu node from the CML reference platforms, with a starting configuration setup to install tac_plus and configure it as a basic TACACS server. Feel free to go and check out the configuration in the topology file for full details, but here are the basics of what I did to build my TACACS server:
With the installation and configuration of the aaa-server part of the base CML topology file, tac_plus will be running and ready to take requests as soon as the lab is started.
cisco@aaa-server:~$ systemctl status tac_plus ● tac_plus.service - tac_plus Service Loaded: loaded (/etc/systemd/system/tac_plus.service; enabled; vendor pres> Active: active (running) since Mon 2024-10-14 19:16:37 UTC; 2s ago Main PID: 5982 (tac_plus) Tasks: 1 (limit: 2310) Memory: 416.0K CPU: 2ms CGroup: /system.slice/tac_plus.service └─5982 /tacacs/sbin/tac_plus -G -C /etc/tacacs/tac_plus.conf -d 8 > Oct 14 19:16:37 aaa-server systemd[1]: Started tac_plus Service. Oct 14 19:16:37 aaa-server tac_plus[5982]: Reading config Oct 14 19:16:37 aaa-server tac_plus[5982]: Version F4.0.4.28 Initialized 1 Oct 14 19:16:37 aaa-server tac_plus[5982]: tac_plus server F4.0.4.28 starting Oct 14 19:16:37 aaa-server tac_plus[5982]: socket FD 4 AF 2 Oct 14 19:16:37 aaa-server tac_plus[5982]: socket FD 5 AF 10 Oct 14 19:16:37 aaa-server tac_plus[5982]: uid=0 euid=0 gid=0 egid=0 s=11063704>
With our TACACS server up and operational, we can now configure our IOS router to use it. Before configuring the TACACS server on IOS, we need to ensure some basic "pre-work" is done on our router. IOS has been around for years and has experienced many changes in how authentication and authorization are handled.
So, the first thing we want to do is ensure the "new model" of AAA is enabled on our device:
aaa new-model
Next, we want to create a local user account that can access and administer the device if the TACACS server becomes unreachable. You might also want to use a local account for serial/console connections.
username cisco privilege 15 secret cisco
In this command, the username and password are both set to "cisco." (Not the most secure choice, but this is just a lab.) The "privilege 15" part of the command indicates that this user will be assigned an "administrator" role. Privilege 15 is the highest level on an IOS device and allows the user to execute any and all commands.
We're ready to configure and test TACACS now. But first, I jump onto the console for the server and start monitoring the logs. This way, I can check and verify results on the server side as well as on the client.
# On aaa-server journalctl -fu tac_plus # Output Oct 14 19:16:37 aaa-server systemd[1]: Started tac_plus Service. Oct 14 19:16:37 aaa-server tac_plus[5982]: Reading config Oct 14 19:16:37 aaa-server tac_plus[5982]: Version F4.0.4.28 Initialized 1 Oct 14 19:16:37 aaa-server tac_plus[5982]: tac_plus server F4.0.4.28 starting Oct 14 19:16:37 aaa-server tac_plus[5982]: socket FD 4 AF 2 Oct 14 19:16:37 aaa-server tac_plus[5982]: socket FD 5 AF 10 Oct 14 19:16:37 aaa-server tac_plus[5982]: uid=0 euid=0 gid=0 egid=0 s=1106370448
In the above command, the "-f" argument "follows" the log messages as they come in. And the "-u tac_plus" option limits the output to only message from the tac_plus service.
Excellent. Now, back to the router to configure the tacacs server and add it to a group of servers that the router can use for AAA service.
tacacs server aaa-server address ipv4 192.168.0.10 key tacacs123 aaa group server tacacs+ AAA-TACACS server name aaa-server
I'm always a fan of testing that something will (or likely will) work before proceeding. Conveniently, IOS supports a "test aaa" command that we can use.
test aaa group AAA-TACACS iosadmin admin123 legacy # Output Attempting authentication test to server-group AAA-TACACS using tacacs+ User was successfully authenticated.
That looks great! And I can see the logs on "aaa-server" as well.
Oct 14 19:55:16 aaa-server tac_plus[6473]: connect from 192.168.0.1 [192.168.0.1] Oct 14 19:55:17 aaa-server tac_plus[6473]: login query for 'iosadmin' port unknown-port from 192.168.0.1 accepted
With a strong sense of confidence, let's complete the AAA configuration for all three "A's."
! Authentication aaa authentication login default group AAA-TACACS local ! Authorization aaa authorization exec default group AAA-TACACS local aaa authorization console ! Accounting aaa accounting exec default start-stop group AAA-TACACS aaa accounting commands 1 default start-stop group AAA-TACACS aaa accounting commands 15 default start-stop group AAA-TACACS
Maintaining that strong sense of confidence, let's see if it works. End/exit on the router until you need to log back in.
ios01 con0 is now available Press RETURN to get started. User Access Verification Username:
Try to log into the router using the TACACS credentials for the IOS device.
User Access Verification Username: iosadmin Password: ios01#
Success! Check the logs on the server, and you should see something like this:
Oct 14 20:05:03 aaa-server tac_plus[6492]: login query for 'iosadmin' port tty0 from 192.168.0.1 accepted Oct 14 20:05:03 aaa-server tac_plus[6493]: connect from 192.168.0.1 [192.168.0.1]Oct 14 20:05:03 aaa-server tac_plus[6493]: Start authorization request Oct 14 20:05:03 aaa-server tac_plus[6493]: do_author: user='iosadmin' Oct 14 20:05:03 aaa-server tac_plus[6493]: user 'iosadmin' found Oct 14 20:05:03 aaa-server tac_plus[6493]: exec authorization request for iosadmin Oct 14 20:05:03 aaa-server tac_plus[6493]: exec is explicitly permitted by line 6 Oct 14 20:05:03 aaa-server tac_plus[6493]: nas:service=shell (passed thru) Oct 14 20:05:03 aaa-server tac_plus[6493]: nas:cmd* (passed thru) Oct 14 20:05:03 aaa-server tac_plus[6493]: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) Oct 14 20:05:03 aaa-server tac_plus[6493]: added 1 args Oct 14 20:05:03 aaa-server tac_plus[6493]: out_args[0] = service=shell input copy discarded Oct 14 20:05:03 aaa-server tac_plus[6493]: out_args[1] = cmd* input copy discarded Oct 14 20:05:03 aaa-server tac_plus[6493]: out_args[2] = priv-lvl=15 compacted to out_args[0] Oct 14 20:05:03 aaa-server tac_plus[6493]: 1 output args Oct 14 20:05:03 aaa-server tac_plus[6493]: authorization query for 'iosadmin' tty0 from 192.168.0.1 accepted Oct 14 20:05:03 aaa-server tac_plus[6494]: connect from 192.168.0.1 [192.168.0.1]
I've colored the server output to highlight the authentication and authorization logs separately, showing that they truly are two different phases.
But what about the final "A" for accounting? Press Cntr-C to stop following the service log and open up the "accounting log."
tail -f /var/log/tac_plus.acct # Output Oct 14 20:05:03 192.168.0.1 iosadmin tty0 async start task_id=12 timezone=UTC service=shell
You should see a message like the above showing the "start" of the session on the router. Go back to the router and run "write mem" to save the configuration changes to memory. A new log message should show up in the accounting log:
Oct 14 20:10:11 192.168.0.1 iosadmin tty0 async stop task_id=13 timezone=UTC service=shell priv-lvl=15 cmd=write memory
And now, exit the router to log out. A new message should appear as well:
Oct 14 20:11:02 192.168.0.1 iosadmin tty0 async stop task_id=13 timezone=UTC service=shell disc-cause=1 disc-cause-ext=9 pre-session-time=6 elapsed_time=89 stop_time=1728936662
And BAM. All three "A's" have been validated. Excellent work!
Hopefully, this blog has gotten you excited to complete your own exploration of AAA and TACACS. And, you are in luck-the CML topology files that I mentioned above (and will again below) are there for you to grab and use right away. Within them are lab guides that walk through some other important AAA topics, such as using local accounts on the console/serial line for IOS and configuring TACACS on Nexus devices. However, I encourage you to do some independent exploration and experiment with things that are not in the guide:
What happens if you type the wrong username/password? What happens if the configured "tacacs key" is wrong? What happens if the TACACS server is unreachable?
Understanding the impact of problems and failures is critical to a network engineer's ability to be comfortable when something goes wrong in "real life." It is much better to break things in the lab than wait for production to have issues. And there is no better tool than Cisco Modeling Labs for that exploration.
My own AAA exploration will continue. In this blog and lab, I only scratched the surface of the topic and knowledge needed for different certifications. RADIUS servers can be used instead of TACACS, and what about AAA for things like VPN authentication, network access with 802.1x, or other platforms like ASA firewalls?
There are so many more possibilities for me to explore in later blog posts. Would you like to see more on AAA from me? Let me know in the comments.
Until next time!
Sign up for Cisco U. | Join the Cisco Learning Network.
Use #CiscoU and #CiscoCert to join the conversation.