Exploring AAA and TACACS Configuration with Cisco Modeling Labs

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:

• 200-301 CCNA
  • 2.8 Describe AP and WLC management access connections (Telnet, SSH, HTTP, HTTPS, console, and TACACS+/RADIUS)
  • 5.8 Differentiate authentication, authorization, and accounting concepts
• 350-401 ENCOR
  • 5.1 Configure and verify device access control
• 300-410 ENARSI
  • 3.1 Troubleshoot device security using IOS AAA (TACACS+, RADIUS, local database)
• 300-430 ENWLSI
  • 8.1 Implement device access controls (including RADIUS and TACACS+)
• 350-701 SCOR
  • 2.7 Configure AAA for device and network access such as TACACS+ and RADIUS
• 300-715 SISE
  • 7.0 Network Access Device Administration
• 350-601 DCCOR
  • 5.xa Apply network|compute|storage security – AAA and RBAC
• 300-615 DCIT
  • 5.xb Troubleshooting network|compute|storage security – AAA and RBAC
• 350-501 SPCOR
  • 1.6b Describe management plane security – AAA and TACACS
• 300-540 SPCNI
  • 4.1e Implement infrastructure security – TACACS

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.)

Visit the Cisco Learning Network to view the exam topics for all Cisco certification exams. View exam topics

Okay… it’s definitely important… but what is AAA?

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?

In the “AAA in Action!” comic, Carl experiences the entire AAA process:

• The first “A” stands for Authentication. We see this represented when Carl is prompted to verify his identity before he is allowed to make a change to the network.
• The second “A” stands for Authorization. Even after the network verifies Carl’s identity, he has to check whether he has the right(s) to make this change, based on which rights he has been granted on the network.
• And the third and final “A” stands for Accounting, which Carl sees in action when the network logs the change he makes to the network.

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.

Can we get to the Exploration, already?!

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.

How to run a TACACS Server in Cisco Modeling Labs

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:

1. Install the requirements to download and install the tac_plus application from source code.
2. Create the “tac_plus.conf” configuration file to specify the TACACS secret key, users, and roles/privilege levels for both IOS and NX-OS platforms.
3. Create a “tac_plus.service” file to setup tac_plus as a service.
4. Download, extract, install, and start the tac_plus 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>

How to enable AAA and TACACS on a Cisco IOS Router

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!

Resources

 

Sign up for Cisco U. | Join the Cisco Learning Network.

Follow Cisco Learning & Certifications

X | Threads | Facebook | LinkedIn | Instagram | YouTube

Use #CiscoU and #CiscoCert to join the conversation.

 

Share: