|AAA Authentication Basics|
|Thursday, 08 June 2006 19:36|
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 AAAThe first link below is for the last article I wrote about this. It was a pictorial overview of CiscoSecure ACS 4.0. It contains many links to documents about ACS and 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?Why use AAA? Well, recall that any discussion of AAA explains that AAA stands for Authentication, Authorization, and Accounting. So if you need to Authenticate users, Authorize what they are allowed to do (by user or user group), or do Accounting, AAA is the tool of choice.
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 IOSThis is the easy part. Turn on TACACS+ with the "aaa new-model" command. Then specify the address of the TACACS+ server. It is a good idea to use an authentication key, especially if you are going to wild-card the client router's address in ACS (as we are).
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!
router2600#show run | inc aaa|tacacs
aaa authentication login default group tacacs+ line enable
tacacs-server host 10.20.1.20 key pleasetrustme
Setting up AAA Authentication in CiscoSecure ACSThere are two steps needed to get going with ACS. The first is to put in the address(es) of the NAS clients, the devices that will be authenticating users. The second is to add the user and specify the various items applying to their login.
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".
You then fill in the form. Note that address wildcarding can be used.
There is a gotcha here. You can wildcard the address of the AAA client. Unfortunately, the TACACS+ packets are sourced from the router interface the packets are sent from. That means using loopback addresses (as I did in the above picture) will not work. There is a sample screen showing the unfortunate results below, in the Troubleshooting section.
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".
You then need to fill in the form for the user. The internal database is what we're using at this point, so we need to tell ACS what password goes with that username.
Scrolling down, we see more of the user setup form. We don't need to alter any of the settings, so we just click on Submit.
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.
Jun 6 08:04:56.079 EDT: AAA: parse name=tty67 idb type=-1 tty=-1
Jun 6 08:04:56.079 EDT: AAA: name=tty67 flags=0x11 type=5 shelf=0 slot=0 adapter=0 p
Jun 6 08:04:56.079 EDT: AAA/MEMORY: create_user (0x8268B78C) user='NULL' ruser='NULL
0.1.1' authen_type=ASCII service=LOGIN priv=15 initial_task_id='0'
Jun 6 08:04:56.079 EDT: AAA/AUTHEN/START (1150011776): port='tty67' list='' action=L
Jun 6 08:04:56.079 EDT: AAA/AUTHEN/START (1150011776): using "default" list
Jun 6 08:04:56.083 EDT: AAA/AUTHEN/START (1150011776): Method=LINE
Jun 6 08:04:56.083 EDT: AAA/AUTHEN (1150011776): status = GETPASS
Jun 6 08:05:03.027 EDT: AAA/AUTHEN/CONT (1150011776): continue_login (user='(undef)'
Jun 6 08:05:03.027 EDT: AAA/AUTHEN (1150011776): status = GETPASS
Jun 6 08:05:03.027 EDT: AAA/AUTHEN/CONT (1150011776): Method=LINE
Jun 6 08:05:03.027 EDT: AAA/AUTHEN (1150011776): status = PASS
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:
User Access Verification
Jun 3 12:13:01.422 EDT: AAA: parse name=tty72 idb type=-1 tty=-1
Jun 3 12:13:01.422 EDT: AAA: name=tty72 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=7
Jun 3 12:13:01.422 EDT: AAA/MEMORY: create_user (0x82A1CA18) user='NULL' ruser='NULL' ds0
=0 port='tty72' rem_addr='10.20.1.1' authen_type=ASCII service=LOGIN priv=15 initial_task_
Jun 3 12:13:01.422 EDT: AAA/AUTHEN/START (4245677897): port='tty72' list='' action=LOGIN
Jun 3 12:13:01.422 EDT: AAA/AUTHEN/START (4245677897): using "default" list
Jun 3 12:13:01.426 EDT: AAA/AUTHEN/START (4245677897): Method=tacacs+ (tacacs+)te
Jun 3 12:13:01.426 EDT: TAC+: send AUTHEN/START packet ver=192 id=4245677897
Jun 3 12:13:01.638 EDT: TAC+: ver=192 id=4245677897 received AUTHEN status = GETUSER
Jun 3 12:13:01.638 EDT: AAA/AUTHEN (4245677897): status = GETUSERst1
Jun 3 12:13:03.746 EDT: AAA/AUTHEN/CONT (4245677897): continue_login (user='(undef)')
Jun 3 12:13:03.746 EDT: AAA/AUTHEN (4245677897): status = GETUSER
Jun 3 12:13:03.746 EDT: AAA/AUTHEN (4245677897): Method=tacacs+ (tacacs+)
Jun 3 12:13:03.746 EDT: TAC+: send AUTHEN/CONT packet id=4245677897
Jun 3 12:13:03.950 EDT: TAC+: ver=192 id=4245677897 received AUTHEN status = GETPASS
Jun 3 12:13:03.950 EDT: AAA/AUTHEN (4245677897): status = GETPASS
Jun 3 12:13:06.318 EDT: AAA/AUTHEN/CONT (4245677897): continue_login (user='test1')
Jun 3 12:13:06.318 EDT: AAA/AUTHEN (4245677897): status = GETPASS
Jun 3 12:13:06.322 EDT: AAA/AUTHEN (4245677897): Method=tacacs+ (tacacs+)
Jun 3 12:13:06.322 EDT: TAC+: send AUTHEN/CONT packet id=4245677897
Jun 3 12:13:06.523 EDT: TAC+: ver=192 id=4245677897 received AUTHEN status = PASS
Jun 3 12:13:06.523 EDT: AAA/AUTHEN (4245677897): status = PASS
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:
User Access Verification
Jun 6 08:17:03.278 EDT: TAC+: Using default tacacs server-group "tacacs+" list.
Jun 6 08:17:03.278 EDT: TAC+: Opening TCP/IP to 10.20.1.20/49 timeout=5
Jun 6 08:17:03.286 EDT: TAC+: Opened TCP/IP handle 0x823BA040 to 10.20.1.20/49
Jun 6 08:17:03.290 EDT: TAC+: 10.20.1.20 (1075879894) ACCT/REQUEST/START queued
Jun 6 08:17:03.390 EDT: TAC+: (1075879894) ACCT/REQUEST/START processed
Jun 6 08:17:03.390 EDT: TAC+: received bad ACCT packet: type = 0, expected 3
Jun 6 08:17:03.390 EDT: TAC+: Invalid ACCT/REQUEST/START packet (check keys).
Jun 6 08:17:03.394 EDT: TAC+: Closing TCP/IP 0x823BA040 connection to 10.20.1.20/49
Jun 6 08:17:03.394 EDT: TAC+: Using default tacacs server-group "tacacs+" list.
The following shows a successful login exchange with ACS.
User Access Verification
Jun 3 12:13:27.410 EDT: TAC+: send AUTHEN/START packet ver=192 id=142619106
Jun 3 12:13:27.410 EDT: TAC+: Using default tacacs server-group "tacacs+" list.
Jun 3 12:13:27.410 EDT: TAC+: Opening TCP/IP to 10.20.1.20/49 timeout=5
Jun 3 12:13:27.422 EDT: TAC+: Opened TCP/IP handle 0x82A3D22C to 10.20.1.20/49
Jun 3 12:13:27.426 EDT: TAC+: 10.20.1.20 (142619106) AUTHEN/START/LOGIN/ASCII queued
Jun 3 12:13:27.626 EDT: TAC+: (142619106) AUTHEN/START/LOGIN/ASCII processed
Jun 3 12:13:27.626 EDT: TAC+: ver=192 id=142619106 received AUTHEN status = GETUSER1
Jun 3 12:13:29.558 EDT: TAC+: send AUTHEN/CONT packet id=142619106
Jun 3 12:13:29.558 EDT: TAC+: 10.20.1.20 (142619106) AUTHEN/CONT queued
Jun 3 12:13:29.758 EDT: TAC+: (142619106) AUTHEN/CONT processed
Jun 3 12:13:29.758 EDT: TAC+: ver=192 id=142619106 received AUTHEN status = GETPASS
Jun 3 12:13:31.946 EDT: TAC+: send AUTHEN/CONT packet id=142619106
Jun 3 12:13:31.946 EDT: TAC+: 10.20.1.20 (142619106) AUTHEN/CONT queued
Jun 3 12:13:32.146 EDT: TAC+: (142619106) AUTHEN/CONT processed
Jun 3 12:13:32.146 EDT: TAC+: ver=192 id=142619106 received AUTHEN status = PASS
Jun 3 12:13:32.146 EDT: TAC+: Closing TCP/IP 0x82A3D22C connection to 10.20.1.20/49xit
[Connection to 10.20.1.1 closed by foreign host]
Troubleshooting AAA via ACS
It is useful to know how to verify correct operation from the CiscoSecure ACS end of things.Click on Reports and Activity, then on Failed Attempts. Then click on "Failed Attempts active.csv", which is the most recent information. (I'm skipping a couple of not-very-interesting screen shots here, to keep this article from getting overly long.
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.
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.
aaa accounting exec default start-stop group tacacs+
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.
That's a nice feature!
SummaryI hope you enjoyed this article. It was perhaps a little more basic than the usual, but it addresses something that I occasionally see people struggling with.
Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher Pete's email address.
Copyright (C) 2006 Peter J. Welcher