More AAA: Simple Authentication, Authorization, and Accounting



	More AAA: Simple Authentication, Authorization, and Accounting

	Peter J. Welcher

Introduction

I'm writing this coming off of Networkers and then some vacation time at the beach. A word about Networkers: it was great meeting or seeing again all of those who came up and said hi this year! And thanks for reminding me of names -- faces and names don't seem to stay together in my brain. Or that's my excuse for not being in sales, anyway.

This month's article continues some fairly basic AAA / TACACS+ tips and tricks. There are some things that most people want, things that are fairly easy to get working, but how to do them isn't exactly clear from the Cisco documentation. The problem: you have to piece together the ACS GUI documentation and the Cisco IOS command line (CLI) configuration commands to make this work. They weren't pulled together in any one reference.

Well, now they are documented together: here! So no more excuses -- get out there and start using some of the real potential of CiscoSecure ACS!

Another reason I wanted to write this: every few months, I seem to find myself trying to remember how the CLI AAA configuration and ACS GUI configuration activities fit together for this sort of thing. It never takes long to get it working as desired. The precise details to get exactly what combination of features you want aren't obvious from the documentation, and never quite stick with me between uses. I hope this helps you "remember how to do it" too!

Topics in the previous article:

Why use AAA?
Setting up (basic) AAA authentication in Cisco IOS

Setting up (basic) AAA authentication in ACS

Troubleshooting AAA from the router CLI

Troubleshooting AAA via ACS

Tracking logins across systems

Specific topics in this article, below:

How to control who gets enable or other privilege levels

Controlling enable access: allow selected users to use their TACACS+ login password, or a per-user enable password

Authorization: how to set up some basic controls on who can issue which exec mode commands

Accounting: how to get an audit trail of who issued what commands to your Cisco devices

Prior Articles about AAA or TACACS+

Document	URL
Last month's article: AAA Authentication Basics	http://www.netcraftsmen.net/welcher/papers/aaabasics01.html
Cisco Secure Access Control Server for Windows 4.0	http://www.netcraftsmen.net/welcher/papers/acs-4.0.html
TACACS+	http://www.netcraftsmen.net/welcher/papers/tacacs.htm
TACACS+, Part 2	http://www.netcraftsmen.net/welcher/papers/tacacs2.htm

Starting Point

Here is the configuration we worked through in the previous article. It is our starting point for the configuration commands discussed in this article. See the previous article for the ACS setup we did via its Graphical User Interface (GUI).

aaa new-model
aaa authentication login default group tacacs+ line enable
tacacs-server host 10.20.1.20 key pleasetrustme
ip tacacs source-interface Loopback0
aaa accounting exec default start-stop group tacacs+

Controlling User Privilege Levels

The first thing I'd like to show you is how to use ACS to control which privilege levels users get. You can do this by Group, and over-ride it per-user. Assuming you like to make things really confusing, that is. (I'd just do things by group).

I recommend starting by going into Interface Configuration, TACACS+ (Cisco IOS), to enable the Advanced Configuration Options. (Which, a bit confusingly, is NOT under Advanced Options in the screen capture below). This is shown in the next screen capture.

Then scroll down and click the checkbox next to Advanced TACACS+ Features, under the heading Advanced Configuration Options. Click on Submit. This is shown in the next screen capture.

This will enable the privilege level and enable controls for groups. I suggest that is the right level of granularity to be doing this sort of thing at. (Some groups get one privilege level or enable access, others do not).

Then pick a group to edit, under Group Setup. Click on Edit Settings, as shown in the next screen capture.

You can then jump to Enable Options, as shown in the capture below.

Click on the dot for "Max Privilege for any AAA Client", which is the highest enable privilege level that group can have on any device. For our example, we try Level 1, which is user level (what you normally have when you telnet into a router). See the next screen capture.

Click on Submit + Restart.

Now configure the router or Cisco IOS device with the following command:

aaa authentication enable default group tacacs+ enable line

This says to do TACACS+ verification of enable authentication.

It's now time to test it out. The following screen shows what happens when user "test1" (in group 0: Default) tries to become enabled (which by default is level 15). The ACS response won't allow the user to be authenticated at that level. I also tested this by allowing "test1" to go to privilege level 2. The command "enable 2" and enable password then worked to go to privilege level 2. "Enable 3" failed as before.

I then changed the group back to privilege 15 and submitted that. Things didn't work until I went back and also changed the per-user setting in the same way.

Two Ways to Control Enable via AAA

We have just seen how we can use the privilege level control to deny selected NOC operators, contractors, and other restricted users the ability to configure the router, but still get in and do (some or most) show commands.

For those we allow to become enabled, it is handy to have ACS track the password(s), rather than having the enable password coded into the router. If you go to the other part of the per-user Enable Control, you can specify enable password behavior. The three choices are:

CiscoSecure PAP password (the PAP telnet login password for that user in ACS)
External database (for example, Microsoft Active Directory)
A separate password (per-user enable password, configured into ACS)

Check the one you want. Be sure to supply the separate password if that option is checked. The right side of the screen below shows what happens if you do not.

The way to check success or failure is via the Successful login or Failed Login reports in ACS, shown in the previous article. There is no obvious way to tell telnet login apart from enable, other than perhaps paying attention to the time you try it at, and looking at the time stamp. If you see two attempts in close temporal proximity, that's probably your telnet login followed by your enable.

As an example of using groups "wisely", I set up a group I called "Enablers". Of course, I put myself ("pjw") into it as a user. And tested it both ways. With the first radio button in the above screen capture selected, the same password that got me telnet access also got me enable access. With the last button selected, the special password I put in worked (and the telnet one did not).

Authorization: Controlling Exec Commands

On to Authorization, the second A in AAA. As a quick demonstration of the sort of powerful things you can do with ACS, I decided to allow most show commands but deny "show version". Not that you'd ever do that in the real world, but just as a test.

To start with, you have to tell Cisco IOS to do AAA authorization of EXEC commands. There is a separate IOS command for authorization of configuration commands. So I entered the following at the router CLI:

aaa authorization commands 1 default group tacacs+ if-authenticated none

You would then go to the Group or User setup, to specify the allowed commands. Once again, I think you want to try to do what you need to do with groups, to keep the management burden as light as possible. So Edit Settings for the group, and scroll down to the part about Group Command Authorization. You can also create Shell Command Authorization sets and then select which one is allowed -- but let's do it the basic way here.

The logic of this dialog box confused me at first. You need to check Permit or Deny to tell ACS what you want for unmatched Cisco IOS commands.

You can then check the box and put in the beginning of an EXEC mode command to allow or deny. You put in the first keyword. Then below it, you put "permit" or "deny" followed by a keyword, as many times as needed. You also click on whether to permit or deny keywords (arguments) that you did NOT specify. Click on Submit or Submit + Restart.

See the screen capture below.

The next screen capture shows what comes up next. You get another blank command block below what you just entered, and you can add more permitted or forbidden commands. Repeat as needed. Caution: tedium may set in. Which is why you probably don't want to do this very often, or do very complex policies with it.

Allow me the chance to demonstrate that this actually works. See the next screen capture. "Show version" is disallowed, but other show commands work for the test1 user.

Accounting: How to Get an Audit Trail

That leaves one more AAA stunt: creating an Audit Trail. Enter the following configuration on the Cisco router or Cisco IOS device:

aaa accounting commands 15 default start-stop group tacacs+

You can then go to the Reports part of ACS. Pull up the TACACS+ Administration report. (TACACS+ Accounting tracks changes you made to ACS itself). The results are shown below. Note that you can clearly see who issued each command, when they did it, and what the command was.

Final Cisco IOS Configuration

Here is our final set of configuration commands. There's not much to type really, the trickier part is how it all fits together with the right ACS GUI configuration steps. And looking for reporting in all the right places.

aaa new-model
aaa authentication login default group tacacs+ line enable
aaa authentication enable default group tacacs+ enable line
aaa authorization exec default if-authenticated
aaa authorization commands 1 default group tacacs+ if-authenticated none
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
ip tacacs source-interface Loopback0
!
tacacs-server host 10.20.1.20 key pleasetrustme
tacacs-server directed-request

Summary

I hope you enjoyed this article. It's feeling like we've done enough AAA and ACS for a while. My list of article ideas is getting longer. It includes things like High Availability, working with wireless controllers, NAC, defensive IP multicast configuration, and many other topics.

Concerning High Availability and quality time at the beach, let me just say that if heavy rain is predicted, the words "backup sump pump" might be good ones to consider.

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