Introduction

Have you been thinking for a while about using AAA / TACACS+ to authenticate router administrators? Perhaps you've been putting it off? I've been noticing that it takes familiarity with both the Cisco IOS and with CiscoSecure ACS to make authentication work. There's not a lot required, but it is lost in the manuals, mixed in with all sorts of other information that's not relevant. I set out to produce a simpler task-oriented write-up, since CiscoSecure ACS is a good tool to be able to use, if you have more than say 20-30 routers or more than yourself administering the network.

This month's article is a pictorial guide to the basics of working with CiscoSecure ACS 4.0, complete with screen captures. After my next chance for a little quality time with my lab, I may write a follow-on article to show how to set up TACACS+ for enable access, also audit trail.

Prior Articles About AAA

The other links are papers I wrote quite a while back about TACACS+. A lot of that is still relevant, if somewhat more focused on the Cisco IOS commands than on the CiscoSecure ACS side of things.

Why Use AAA?

In this article we'll focus on authenticating router administrators. Much the same approach can be used to authenticate VPN users.

ACS can be used as a local database of users. However, I've called ACS a "glue" product before -- the point being it glues router or VPN or other authentication to your directory server of choice. Cisco network devices generally know how to talk TACACS+ or RADIUS to ACS, and then ACS talks to your Active Directory, LDAP, or other authentication database.  As mentioned in my last ACS article, the profiles now provide for different behavior based on user group and device type.

Thus ACS opens the door to very flexible authentication of users for various networking purposes. It also provides a login trail, and as we may see in another article, an audit trail as well.

Setting Up AAA Authentication in Cisco IOS

The "aaa authentication" line below says the default way for users to log in is by checking with the group of tacacs+ servers (any TACACS+ servers defined with the "tacacs-server" command). If that fails to respond, the line or enable password can then be used as fallbacks. You want to think about having some sort of fallback here, so you can get into your router if the ACS server is not responding or is not reachable. Otherwise you may not be able to fix the connectivity problem!

Setting up AAA Authentication in CiscoSecure ACS

The next two screens show adding one or more NAS clients to ACS.  Click on Network Configuration (on the left), then on "Add Entry" under "AAA Clients".

The magic command you want at this point is "ip tacacs source-interface Loopback0". Otherwise you will have to list the IP addresses of each router that packets are likely to be sourced from, which is not fun. It is much simpler to wildcard and use loopbacks, assuming your loopbacks come from one or a few IP prefixes. This command is not easily found with the router CLI help system because of the unexpected leading keyword "ip".

The next step is to add one or more users. The following screens show how this is done in detail. Click on User Setup to the left. Type in the name of the new user and click "Add/Edit".

It is less work to define user groups and do settings (permissions) on a per-group rather than per-user basis. In the above figure, you can see the drop-down menu where you can select which user group the user belongs to. User groups can also be picked up from an external user directory, for example Microsoft Active Directory. If users can belong to more than one group, the AD to ACS group mapping rules can take a bit of work to set up. Generally, you specify combinations of many ("if the user is in Groups A, B, and C in AD then put them in ACS group W"), followed by fewer. The rules are processed top-down, so the later rules become simpler, because you can assume the earlier rules were not matched if a later rule is being processed. That saves you from doing all boolean combinations ("not A and not B but is in C"). You still may need a Venn diagram to keep it all sorted out. (I'm only half joking here).

Troubleshooting AAA from the Router CLI

I deliberately set up so the AAA client (NAS) address was not known to CiscoSecure ACS. The following is the "debug aaa authentication" output from the router.

If you look closely, you can see that there's nothing about tacacs+, and the user is "NULL". Also, the router never asks for a username, just the password.  The Method=LINE part confirms that ACS is not responding, so the method is rolling to the next alternative, the line password.

By way of contrast, the following shows logins when ACS has the right address and is responding:

If you happen to realize you might be having a AAA problem, not an authentication problem, you can use "debug tacacs".  You would then see something like the following while logging in:

The following shows a successful login exchange with ACS.

Troubleshooting AAA via ACS

It is useful to know how to verify correct operation from the CiscoSecure ACS end  of things.

You should see something like the following screen.

The bottom entries clearly show the problem with the IP address of the AAA client router.

The top line shows what happens when AAA is working but somebody (me!) enters an incorrect password.

I personally think it useful to be able to see successful logins as well. In ACS 4.0, this is off by default, so you have to turn it on. The Help screens were helpful on this.

The next two screen captures show turning on logging of successful logins. Start by clicking on System Configuration (on the left). Then click on CSV Passed Authentications.

Tracking Logins Across Systems

While we're looking at logs in ACS, there's another benefit to using ACS, one I don't recall from before. If you put the following accounting command into your router, you can see who ACS thinks is currently logged in to a router.

After entering this command in the router, I then telnetted back into the same router to verify ACS operation. The following screen captures show the additional information ACS can then provide.

To get there, click on Reports and Activity. Then click on Logged-in Users.

Summary

Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher Pete's email address.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner with multiple specializations, dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and bridging,  network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw <at> netcraftsmen <dot> net (formatted this way to fool email harvesting software).