Chesapeake NetCraftsmen

 AAA AuthenticationBasics

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.

• Cisco Secure Access Control Server for Windows 4.0
• The TACACS+ System
• TACACS+, Part II

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


Check the box to log Passed Authentications. You can review or alter the attributes recorded using the rest of the screen form. Click on Submit when done.



We're now ready to view Passed Authentications. Click on Reports and Activity, tghen on Passed Authentications.


From the following, you can see that user "test1" successfully logged into 10.20.1.1.



In conclusion, we now know how to check both ends of the router -- ACS connection, to detect success or failure to log in. By the way, if no messages whatsoever show up in the either log, then the router is probably sending packets to the wrong address.

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.

If you then click on the name LabRouter, you can see who is logged into it.

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) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, 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/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .