AAA, TACACS+, and SSH: Which to Use and When

Quick Definition: TACACS+ (Terminal Access Controller Access-Control System Plus) is a security protocol developed by Cisco to provide centralized authentication, authorization, and accounting (AAA) for users accessing network devices

Say you've got a network environment that's all bottled up and secure with AAA running. But now you've got a new router with no security on it — and you need to add it to the network. If you had to configure SSH, get TACACS+ working on it, and lock it down, how long would it take you? 

Follow along with us, and we'll show you how to get a router at Security Level 0 connected to a AAA server in about five minutes.

What is TACACS+ (Terminal Access Controller Access-Control System Plus)?

TACACS+ (Terminal Access Controller Access-Control System Plus) is a security protocol developed by Cisco to provide centralized authentication, authorization, and accounting (AAA) for users accessing network devices. TACACS+ stands for Terminal Access Controller Access-Control System Plus, but it shouldn't be mistaken for TACACS. 

TACACS was the predecessor to TACACS+, but they're not compatible, and TACACS+ has replaced TACACS.TACACS+ is an enhanced version of the original TACACS protocol, which was created in the 1980s to manage remote access over ARPANET. The protocol evolved into TACACS+, which offers a number of benefits, including: 

• Enhanced Security: TACACS+ encrypts the entire packet, ensuring sensitive information like user credentials and session data are protected.

• Granular Authorization Control: It allows administrators to define specific commands users can execute, offering fine-grained control over user actions.

• Separation of AAA Functions: TACACS+ separates Authentication, Authorization, and Accounting, providing more flexibility in managing user access.

• Scalability: Suitable for large networks with multiple devices and users, allowing centralized management of access control.

• Detailed Logging: Provides extensive logging capabilities for tracking user activities, which aids in auditing and troubleshooting.

• Centralized Management: Allows for easier and centralized management of user access to multiple network devices from a single point.

TACACS+ uses Transmission Control Protocol (TCP) to encrypt the full content of each packet, which is frequently run on AAA servers on Cisco networks and uses SSH. 

How Does TACACS+ Work? 

TACACS+ operates on a client-server architecture, where network devices act as clients and a central TACACS+ server handles authentication, authorization, and accounting (AAA). The client devices send user credentials and requests to the TACACS+ server, which authenticates the user by checking their credentials against a central database. 

Once authentication is successful, the server moves to the authorization phase, where it determines what the user is allowed to do based on predefined policies. This granular authorization control allows for command-level restrictions, ensuring users can only take approved actions. Finally, the accounting process logs all user actions, creating an audit trail for network activities. 

Throughout this process, TACACS+ encrypts all communication between the client and server, securing sensitive information. By separating the AAA functions, TACACS+ provides better flexibility and control, making it ideal for managing access to complex network infrastructure.

What are AAA and AAA Servers?

Quick Definition: In the networking world, AAA stands for Authentication, Authorization, and Accounting. An AAA server is used for access control and security. Usually pronounced "triple-A," a AAA server is a network server that helps keep the wrong people out of your network while getting the right people to the network resources.

AAA's first "A", Authentication, identifies each user. The second, Authorization, is in charge of policies that decide which resources and services each user can have access to. The third "A," Accounting, helps track and monitor the time and data resources used for billing and analysis.

What is SSH?

Quick Definition: SSH, which stands for Secure Shell, is a protocol for encrypting network interactions over unsecured networks. Realistically, any network service can be secured via SSH, but the most common applications of SSH are accessing the command line, logging in, and executing commands remotely.

How to Use TACACS+, AAA, and SSH [VIDEO]

In this video, Keith Barker covers how to set up a router to authenticate users and restrict access to the secure shell (SSH). He begins with a router with no security in place and uses TACACS+ to pair it with an AAA server.

Connecting a New Router to AAA Environment Using TACACS+ [Checklist]

Our mission is to prepare a router with no security at all to work with a AAA server using TACACS+. If you're already familiar with the process, this checklist should orient you for the task at hand. If you're not familiar, these are the steps we'll be following below, and you can follow along with:

• Configuration Checklist

• Enable secret

• Local user (for backup)

• Domain name

• RSA keys

• Enable AAA New-model

• AAA IP and key

• AAA method list

• Permit-only SSH

How to Connect a New Router to AAA Environment with TACACS+ via SSH

We'll be working in a simulated environment to demonstrate the process of connecting our brand new router to our existing network environment. We recommend that you follow along with your own network simulation.

Remember, our plan is to take a router, which we'll call R1, with no security in place whatsoever and authorize it for a AAA server. We'll use TACACS+ to authenticate users, and we'll restrict all the access to SSH. In our hypothetical network, we want traffic to pass through only one place: inbound on the Fa 2/0 interface.

The first step is to enter the command line interface for R1 and start it up:

enable

Then start the process with:

configure terminal

The first step is to create a secret key. The command for that looks like this, but the secret you use should be specific to you and your environment. This is an example:

enable secret KraZyD1fFiculT!

Next, you want to create a local user with full rights. Make sure you read that sentence carefully, though. You're creating a local user. But, you might ask, if we're working toward a AAA environment, why would we want to create a local user? Because if there's ever an outage during which we can't reach the AAA server, we want a fallback method that uses the local database and local configurations:

username admin privilege 15 secret T0ugh0n3asWha13

After that, we need to set a domain name. This will allow us to create the RSA key-pair for the SSH access. After this, we'll be generating the public/private key pair:

ip domain-name CBTNuggets.com

It's not until we have the public/private key pair in place that SSH is willing to get down to work. But now we can get it initiated:

crypto key generate rsa modulus 1024

Note: This should result in a return that tells you what the name for your keys will be. In our case, "The name for the keys will be: R1.CBTNuggets.com". Additionally, you should see information about the key like, "The key modulus size is 1024 bits" and "Generating 1024 bit RSA keys, keys will be non-exportable".

Enabling AAA On a New Router

Once the key and SSH access is in place, we'll move on to enabling AAA. Once we do that, we'll specify which AAA server to use. At that point, we'll need to instruct it where to find the server using TACACS+ and the key that should be used with that server.

Your next step is to enable AAA. The command for that is simple enough:

aaa

Note: This should return something like, "%SSH-5-ENABLED: SSH 1.99 has been enabled"

Next, type:

aaa new-model

Then tell the router about the IP address to use with the AAA server:

tacacs-server host 192.168.1.252

The last part of getting AAA in place is to tell it what key to use with the AAA server:

tacacs-server key cisco123

If you've followed along, you now have AAA in place. We've identified a AAA server. Next, we'll specify a default method list. A method list is the list of instructions we give for how we want the device to go about authenticating users. In this case, it's us instructing it, "When it comes to log-in authentication, I want you to use a AAA server. If a AAA server can't be reached for whatever reason, fallback to the local database." Remember, this is why we created that local user.

The nice thing is that this is mostly a default method list. This one will tell the router to use the AAA server first, and then if the server can't be reached, then the local database should be used:

aaa authentication login default group tacacs+ local

Now, the next thing we're going to do is lockdown SSH, so that SSH is only allowed. We do not want TELNET to be allowed through this interface. Additionally, we're going to lock all traffic down to the fast ethernet 2/0 interface. The easiest way to do that is through control plane functionality:

control-plane host

Now that we're working with the control plane host, we'll instruct it that the management interface is Fa 2/0, and only SSH should be allowed. That means TELNET, HTTP, and other management protocols will not be allowed.

management-interface FastEthernet 2/0 allow ssh

We can verify we did that right by typing:

Test bas

Note: That should return "%Management-Interface feature enabled on Control plane."

Testing a New Connection to a AAA Environment

Any time you're dealing with new connections and encryption methods, it's usually a good idea to test it and verify that it's working. The test command will let us do a basic test for AAA access. If you've been following along, you should already be in configuration mode, and so the "do" precedes our test command.

In order to do the test, we're going to put in a username that exists on the AAA server, with the password and the keyword legacy:

do test aaa group tacacs+ testadmin cisco legacy

Note: This should return: "Attempting authentication test to server-group tacacs+ using…"

Hopefully you, like we did, got a successful response. Now, the next thing we'll want to do is actually go to a live client at the PC at R1 itself. But before you do that, if you turn on debugging, you'll be able to watch the play-by-play action — and that's a good way to understand exactly what's happening behind the scenes.

How to Debug AAA Authentication, TACACS+, and Users

In addition to doing a debug of AAA authentication, we'll also want to debug TACACS+. On top of that, it's always a good idea at a point like this to verify that on the local running config there are no users other than the one user we created earlier: Admin.

To debug AAA authentication, type:

do debug aaa authentication

Note: If successful, this should return "AAA Authentication debugging is on"

To debug TACACS+, type:

do debug tacacs

Note: If successful, this should return "TACACS access control debugging is on"

Last, to check what users are running on the local config, type:

do show run | inc user

Note: If successful, this should return "username admin privilege 15 secret 5" followed by a hash

If, like ours, your set-up has gone well, it's time to head out to the client. For us, what that means is going to the admin PC in our network simulation and bringing up its Command Prompt.

First, we want to confirm its IP address:

ipconfig

This will give you a recognizable output. In our sim, this admin PC is 10.20.0.11 which is on the 10.2.0.0 network and the default gateway is 10.2.0.1,  all of which is what we want. Make sure yours is ready to run the AAA test.

To verify connectivity, you can ping the gateway:

ping 10.2.0.1

If you're in a simulated network environment and you have the space available on your monitor, you should try to have the debug window open alongside the admin PC's Command Prompt. That'll make the next steps easier. So, let's authenticate. On the Windows PC, launch PuTTY.

From the PuTTY window, go to R1. The first time you connect, you'll be asked if you want to validate the fingerprint. Because we're sure this is a valid connection and everything is above board, we can say yes.

Our test will involve us logging in as the user that we created. In our case, "testadmin" with the password "cisco".

While you log in, look at what's happening in the background. The debug should have caught important information about that transaction. It should read that a user "testadmin" has had "Authentication start packet created".

As that handshake happens, you can look through the debug and see that a TACACS debug is running. It should have gotten the password via "Received authen response status GET_PASSWORD". And the result of that: "Received authen response status PASS" means that it was passed.

Congratulations: in a simulated live environment, you can probably follow these steps in five minutes and have your router ready to go.

TACACS+ vs. RADIUS: Choosing the Right Authentication Protocol

TACACS+ and RADIUS are both widely used AAA protocols, but they have several differences to be aware of. TACACS+ encrypts the entire packet, offering superior security, while RADIUS only encrypts the password. 

TACACS+ also separates Authentication, Authorization, and Accounting, providing more flexibility in access control, while RADIUS combines authentication and authorization, making it more straightforward but less granular. 

When choosing between TACACS+ and RADIUS, consider your network size, security requirements, and device compatibility. TACACS+ is often preferred in Cisco-dominated environments needing detailed command authorization, while RADIUS is more versatile and commonly used in multi-vendor settings, particularly for wireless or VPN access. 

The decision depends on the level of control needed and the complexity of the network.

Wrapping Up

Admittedly, there are better ways to follow along with a AAA initialization and debug than a blog post. Hopefully, seeing all the commands and expected results will give you a sense of what to look for when you do your own setup. 

If you were able to follow along, you've got the start-to-finish process for getting a brand new router with Zero Security connected to a AAA server using TACACS+. We saw how to lock down all the interfaces except for one and all management protocols except SSH. We also got rid of TELNET and tested it.

If you want to learn more about remote access technologies, consider the CBT Nuggets course Understand Remote Access Technologies and Tools with Knox Hutchingson.